I'm trying to understand the structure of programs that can be executed from a ROM, and as far I know the header structure have to be something like this:
Byte 0 : ROM Type.
Byte 1 : ROM Mark Number.
Byte 2 : ROM Version Number.
Byte 3 : ROM Modification Level.
Byte 4,5 : External Command Table.
If you examine the name table, in theory you have the following structure:
Bytes 0..1 : Address of command name table
Bytes 2..4 : Jumpblock entry 0
Bytes 5..7 : Jumpblock entry 1
But instead of it, In real ROMs, I found directly the name table.
Where are the jumpblock entries?
By other hand, I would like how can I convert a standard program into a ROM program.
I red there are an utility called RGen to do that.
Where can I found it and how can I use it?.
thanks very much in advance for your help.
Yes. In ROMs people usually put the ROM name down there, and the corresponding routine is the initialisation of the ROM, which usually adds a couple of RSX commands to the system.
Please see my files in the other message about ROMs.
EDIT: What I did miss out in this example is a checksum routine.
There was a nice guide to writing ROM software somewhere here, but I can't remember who did it or where it is. Was it from you Arnoldemu?
Bryce.
Quote from: Bryce on 09:04, 13 September 13
There was a nice guide to writing ROM software somewhere here, but I can't remember who did it or where it is. Was it from you Arnoldemu?
Bryce.
don't remember. I did host some files about rom stuff for a while. I'll dig it out again.
I couldn't find it in the Wiki, so add it there if possible :)
Bryce.
Yes, please!. It could be perfect. ;)
About the checksum... You just add up all bytes from address &C000 to &FFFE and then store the 8 bit result at address &FFFF.
This is usually done using the ADD A,(HL) instruction. Personally (in FutureOS and it's apps) I use a routine based on POP, which makes it way more quick. However for you humans out there it will not matter (but it does for some AI who get's bored quick). ;) :laugh: ;D
I will include checksum code in my next example.
I found the file:
http://www.cpctech.org.uk/download/romguide.zip (http://www.cpctech.org.uk/download/romguide.zip)
It is by Ian Neill. I thought this was already available on genesis8bit, but I am not sure.
It may be also worth to take a look at the examples from the 16 KB ROM compo.
mmmmmm, very interesting. There are a lot of useful information.
Quote from: arnoldemu on 08:56, 13 September 13
EDIT: What I did miss out in this example is a checksum routine.
There's no requirement to add a checksum to the ROM. The CPC OS doesn't care about it and I know personally I've never included it in any ROMs I've made. I don't even recall it being mentioned in the Firmware Manual either.
Bollogs!
Every commercial ROM uses a checksum routine - for good reasons - further, they all take the same algorithm. And also software which programms EPROMs, the ROM-RAM-Box, the SF2 or the new MegaFlash does support a checksum. Other apps do too.
I think what Ralf is trying to say is that it may be supported by several burn programs, but it's not actually needed for the software to run. The software on the ROM never checks its own checksum.
Bryce.
Lots of ROM software *does* check it's own checksum. This includes protext and maxam.
They will display an error.
Oh, yeah, now that you mention it, I remember getting errors while I was testing the MegaFlash before the write routines had been perfected (Maxam was my test ROM).
Bryce.
Quote from: Bryce on 09:36, 19 September 13
I think what Ralf is trying to say is that it may be supported by several burn programs, but it's not actually needed for the software to run. The software on the ROM never checks its own checksum.
I thought I needed one for Subtera Puzlo but found it wasn't a necessity.
Time was tight at the end so I didn't get round to implementing it. So any bugs you find in the game must be a checksum error ;)
@Ralf & Bryce: Are you trolling?
No ::)
Bryce.
Of course one could say that a checksum for a ROM is this days is a kind of reminiscence. Only few people will use EPROMs any longer, and for them a checksum is important - not for the MegaFlash.
On the other hand in these days ROMs really get around: Header removed, Header added, PC to CPC and back. They 'walk for miles'. So yes, I think there is still good reason for having a checksum. And it just cost you one single byte... so honestly: That's what I call a good deal ;)
Quote from: Bryce on 09:36, 19 September 13
I think what Ralf is trying to say is that it may be supported by several burn programs, but it's not actually needed for the software to run. The software on the ROM never checks its own checksum.
I've checked chapter 10 of soft 968 and there is no mention at all of a checksum byte.
Quote from: TFM on 15:41, 18 September 13
Every commercial ROM uses a checksum routine - for good reasons - further, they all take the same algorithm. And also software which programms EPROMs, the ROM-RAM-Box, the SF2 or the new MegaFlash does support a checksum. Other apps do too.
If it's in common use, it's fine for a tool to display a warning but if a program generates an error if this byte isn't present, then it's that program's fault, not that of the ROM. There is no firmware requirement, nor was there ever an official suggestion to generate a CRC byte.
Plenty of ROMs don't include a checksum byte, including Amstrad's own ROMs.
Quote from: arnoldemu on 09:42, 19 September 13
Lots of ROM software *does* check it's own checksum. This includes protext and maxam.
They will display an error.
That's fine, they're just being paranoid. I could internally checksum my own ROM with CRC16 if I wanted, but it's still not a requirement for the firmware to run the ROM.
Quote from: ralferoo on 08:47, 23 September 13
That's fine, they're just being paranoid. I could internally checksum my own ROM with CRC16 if I wanted, but it's still not a requirement for the firmware to run the ROM.
It probably makes sense if you're mass-producing them, as it reduces the amount of manpower needed to check they are OK before shipping them (and gives some confidence they're correct depending on the error a customer reports).
Quote from: ralferoo on 08:47, 23 September 13
If it's in common use, it's fine for a tool to display a warning but if a program generates an error if this byte isn't present, then it's that program's fault, not that of the ROM.
You don't get it. 99% of all ROMs contain a short routine which check their own integrity (16 KB ROM content) when they get initialized. And they are able to display an error message if a bit got corrupted. So this is very useful and common practice.
Quote from: ralferoo on 08:47, 23 September 13
Plenty of ROMs don't include a checksum byte
Just tell me a couple...
Quote from: ralferoo on 08:47, 23 September 13Plenty of ROMs don't include a checksum byte, including Amstrad's own ROMs.
Of course do BASIC and AMSDOS contain NO checksum, because they are REAL ROMs and not EPROMs. We talk about EXPANSION EPROMS here, which of course need a checksum.
Quote from: TFM on 14:58, 23 September 13
You don't get it.
I think it might be you that doesn't get it.
Quote99% of all ROMs contain a short routine which check their own integrity (16 KB ROM content) when they get initialized. And they are able to display an error message if a bit got corrupted. So this is very useful and common practice.
That's fine. That's got nothing to do with putting a checksum byte so that programs that write the ROM can verify its content.
Quote
Just tell me a couple...
Of course do BASIC and AMSDOS contain NO checksum, because they are REAL ROMs and not EPROMs. We talk about EXPANSION EPROMS here, which of course need a checksum.
So, not only did you answer your own question, but here are some more: The PACE RS232 ROM, the Comstar RS232 ROM, AMSDOS. I can't think of any other Amstrad ROMs off-hand, but I'd not expect them to have a checksum byte either. The simple reason is that none of the Amstrad documentation EVER suggested putting a checksum byte into the ROM.
And no, expansion EPROMS don't "of course" need a checksum. The way that most people verify an EPROM is by writing and then reading the contents back to verify its written correctly. In fact, that approach is essential to most of the fast burners.
That's getting ridiculous. Amsdos (as I already mentioned) is not on EPROM! All other 99% have checksum, and also my COMSTAR ROMs have one ;) So you lie! (or have an old outdated version) >:(
If the Amstrad documentation will not suggest to take a shit you would rather die, right?
I won"t waste my time any longer with your ignorance and stubbornness.
Tsk, tsk, guys, tsk tsk.
If this checksum algorithm is such a standard on the CPC, can you point to a single place online that describes it?