Jump to content
IGNORED

Atari Rev B PAL Rom file


sup8pdct

Recommended Posts

A quick BASIC program can produce a dump of your ROM

Typed it in, ran it ... and found out that my 400 is so old, it contains OS Rev. A. :roll:

 

The good thing is that it's always surprising how good this old hardware works after all these years.

Link to comment
Share on other sites

  • 1 year later...

Hey sup8pdct,

 

Recently I've come across a document, the XL Addendum for the Atari 400/800 OS Manual. It contains instructions on determining a revision of system OS, and it suggests that the PAL rev. B has indeed existed.

 

On page 28, it says that to determine the PAL rev. B, one should read locations $FCD8, $FFF8 and $FFF9, which should contain $A2, $22 and $58, respectively. However sup8pdct's artificial ROM does not meet these requirements. Was that another missed conditional, or what?

Edited by Kr0tki
Link to comment
Share on other sites

Hey sup8pdct,

 

Recently I've come across a document, the XL Addendum for the Atari 400/800 OS Manual. It contains instructions on determining a revision of system OS, and it suggests that the PAL rev. B has indeed existed.

 

On page 28, it says that to determine the PAL rev. B, one should read locations $FCD8, $FFF8 and $FFF9, which should contain $A2, $22 and $58, respectively. However sup8pdct's artificial ROM does not meet these requirements. Was that another missed conditional, or what?

 

I have checked $FCD8 and it does contain $A2.

The other 2 locations however, I cannot find any referance to them in the OS Source listing (yet) so they are either chksum bytes used by Salt or id bytes.

Have updated the rom file, if anyone wants a copy of it, please let me know

 

James

Link to comment
Share on other sites

I'd sugest you to post it here and also remove all ROMs from the earlier posts above.

 

Does anyone have a dump of a 400/800 diagnostic cartridge? I'd like to verify if those 2 bytes are a checksum. For sure, the value in FFF8/FFF9 is not a simple modulo 65536 sum of all bytes, unlike the XL checksum.

Link to comment
Share on other sites

I'd sugest you to post it here and also remove all ROMs from the earlier posts above.

:ponder: What he said. There are enough bogus files out there without adding more. Just leave the most accurate and add your handle to it with a date in the name so it won't be confused with a dumped one. example 20100910sup8pdctRevBPalOS

Link to comment
Share on other sites

I've found a few ROMs of SALT diagnostic cartridges here. (They are disk images, actually; I had to extract the ROMs from the ATRs first. See the attachment.)

Anyway, I've examined the SALT 2.05 image and found out that it DOES NOT contain code to detect the Rev. B PAL OS! It detects the other three variations correctly.

 

At offset $16CA the ROM contains ASCII strings that are used to display the OS version on-screen. Among the strings are NTSA, PALA and NTSB, but there's no PALB.

 

The 2.05 SALT is from 1982. It seems that Rev. B PAL was not in production at that time. Maybe it wasn't produced at all, I don't know. There exist later versions of SALT, maybe detection of Rev. B PAL was added later?

Atari 8-bit SALT cartridges.zip

Edited by Kr0tki
Link to comment
Share on other sites

I've found a few ROMs of SALT diagnostic cartridges here. (They are disk images, actually; I had to extract the ROMs from the ATRs first. See the attachment.)

Anyway, I've examined the SALT 2.05 image and found out that it DOES NOT contain code to detect the Rev. B PAL OS! It detects the other three variations correctly.

 

At offset $16CA the ROM contains ASCII strings that are used to display the OS version on-screen. Among the strings are NTSA, PALA and NTSB, but there's no PALB.

 

The 2.05 SALT is from 1982. It seems that Rev. B PAL was not in production at that time. Maybe it wasn't produced at all, I don't know. There exist later versions of SALT, maybe detection of Rev. B PAL was added later?

 

Where are all of the dumps from the Atari Cartridge Dumping Project?

Link to comment
Share on other sites

 

They were never released as far as I know.

 

Mitch

 

Very interesting information about the Salt cart.

Also confirms the fact That I have yet to find a PAL 400/800 with rev B roms.

Here is the fixced (and hopefully final version) of the rev B rom.

 

James

ATARIOSBpal.zip

Edited by sup8pdct
Link to comment
Share on other sites

Where are all of the dumps from the Atari Cartridge Dumping Project?

 

They were never released as far as I know.

 

Mitch

 

Does anyone know if Atarimax has the dumps since he has the web pages for the project?

 

The person responsible for the project has left the scene. I believe Atarimax is only mirroring the old website for informational purposes and does not have any of the ROMs.

Is there a particular ROM you are looking for? Most of them are floating around the Internet somewhere.

 

Mitch

Link to comment
Share on other sites

If they are, then they are surprisingly difficult to find.

 

I've found another SALT cartridge however, through this post - the CPS SuperSALT from 1983. I had to extract the ROM image from an ATR again; I'm attaching the extracted ROM below. Note that it's not a 100% original dump - the title screen has got hacked.

 

Having a SALT from 1983, I'm assuming that it should recoginse a OS B PAL if it existed. This SALT, however, doesn't recognise it.

 

Having the cartridge allowed me to find out the algorithms used to verify correctness of the OS ROM:

- There are three areas, Math ROM ($d800-$dfff), Low ROM ($e000-$efff) and High ROM ($f000-$ffff). For each of these, a checksum is calculated independently.

- For the Math ROM, the checksum is at $dffe (low byte) and $dfff (high byte).

- For the Low ROM, the checksum is at $e40f (low byte) and $e41f (high byte).

- For the High ROM, the checksum is at $fff8 (low byte) and $fff9 (high byte).

- A ROM checksum is calculated by summing up all of the ROM area's bytes (modulo 65536), excluding the checksum bytes themseves. If the calculated checksum equals the checksum stored in the ROM, the ROM is OK.

 

Things get complicated however, when a OS B is present. SALT checks the values at $fff8 and $fff9. If they equal $f3 and $e6 (as in OS B NTSC), then it assumes that the checksum equals $5a02 and then calculates a sum of all bytes from $f000-$ffff, including the bytes at $fff8 and $fff9. The code that performs that comparison and sets the hardcoded checksum, is at $8e02.

For the Low ROM it's similar: If SALT finds $00 at both $e40f and $e41f (as in OS B NTSC), then it sets the checksum to $ec9f and then calculates a sum of all bytes from $e000-$efff. The responsible part of code is at $8dc9.

 

So, the presence of OS B NTSC is a special case for SALT, processed in a special way. However there's no code for processing the OS B PAL. Since the CPS SuperSALT is from 1983, it allows me to draw a conclusion that OS B PAL was never released publicly.

CPS SuperSALT (1983)(Atari)h Irata.rom.zip

Edited by Kr0tki
  • Like 3
Link to comment
Share on other sites

  • 7 years later...

Things get complicated however, when a OS B is present.

 

SALT checks the values at $fff8 and $fff9. If they equal $f3 and $e6 (as in OS B NTSC), then it assumes that the checksum equals $5a02 and then calculates a sum of all bytes from $f000-$ffff, including the bytes at $fff8 and $fff9.

For the Low ROM it's similar: If SALT finds $00 at both $e40f and $e41f (as in OS B NTSC), then it sets the checksum to $ec9f and then calculates a sum of all bytes from $e000-$efff.

 

This is interesting :-o

 

What is the reason for the strange checksum values in the original OS B NTSC?

Did Atari produced ROMs with wrongly calculated checksums and they decided to sell the computers equipped with these ROMs?

If I'm not mistaken, the checksums for OS B NTSC (if calculated like for the OS A) should be:

 

Low ROM checksum = $EC9F (and not $0000)

High ROM checksum = $5829 (and not $E6F3)

 

Is there no selftest / selfcheck in the OS B NTSC?

Does a SALT diag cartridge handle that mistake and properly detects the OS B NTSC?

Edited by TheMontezuma
Link to comment
Share on other sites

What is the reason for the strange checksum values in the original OS B NTSC?

For reference, grab the OS sources and examine ca65-src/800b.s - search for strings "X900C", "XE90B", "XE915", "XEDE8".

 

The source listing contains routines at address $9000 and $900C, which are a remnant of their "LINBUG" development system, whatever it was. (Also referred to as "LNBUG" XL/XE OS sources). A so-called "LINBUG" version of the OS was apparently RAM-based, and, as evident by the $900C routine, it used locations $FFF8-$FFF9 as an additional interrupt vector. The $900C routine would fill $FFF8-$FFF9 with the address of the PIRQ routine, which is equal to $E6F3 - ie. the actual value that is in there in the final ROM.

 

It is also worth noting that the rev. B ROM contains random data in unused areas: $E90B-$E911, $E915-$E943 and $EDE8-$EDE9 (well not exactly random - it is a copy of ROM data located exactly $800 bytes lower).

 

My educated guess is that either they forgot to compute the checksums and clean the ROM image before sending it to manufacturing - or maybe they didn't forget but sent the wrong dump by mistake - and ended up with a huge batch of mask ROMs that would be too costly to scrap.

 

That wouldn't be the first nor last time they would do such thing. A similar thing happened with the Atari BASIC rev. A ROM, which was already known to contain bugs in June 1979 - 5 months before the computers' debut - but Atari had already rushed the ROM to production, which resulted in the buggy BASIC being used anyway.

 

Or when they manufactured 100,000 of CTIAs fearing that the GTIA will not be ready for the Nov. 1979 debut, but when it turned out they managed to develop GTIA in time - they used the CTIAs anyway.

 

Low ROM checksum = $EC9F (and not $0000)

High ROM checksum = $5829 (and not $E6F3)

Correct.

 

Is there no selftest / selfcheck in the OS B NTSC?

Yes, no checksum verification within the OS. It was introduced later, in the 1200XL OS.

 

Does a SALT diag cartridge handle that mistake and properly detects the OS B NTSC?

Yes - the very post you quoted above explained it already.
  • Like 5
Link to comment
Share on other sites

Thank you bery much for a comprehensive explanation :)

The reason I asked is I wondered if it is better to leave the checksum bytes as they are when patching the OS B NTSC or to calculate new checksums.

I understand that it does not matter that much. Having valid checksums may even have negative impact if there is any software relying on the wrong checksum values.

 

Are you aware of any software (other than SALT) checking OS checksums and refusing to work if the OS was not identified (I mean any Atari OS, not particularly B NTSC) ?

Edited by TheMontezuma
Link to comment
Share on other sites

I haven't heard of any such program, although I can imagine a copy protection scheme that would check for presence of a modified OS. For example, some Electronic Arts disks would barf when run on a machine with Omnimon, but I don't know if their routines involved verifying the checksums.

 

In any way, I would suggest checking what was the approach used by authors of other custom ROMs back in the day. One particular revision of the Newell OSN, for example, has the checksums left unchanged.

Edited by Kr0tki
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...