Rybags Posted April 1, 2009 Share Posted April 1, 2009 A quick BASIC program can produce a dump of your ROM 10 OPEN #1,8,0,"D:OSDUMP.ROM" 20 FOR A=216*256 TO 65535:PUT #1,PEEK(A):NEXT A 30 CLOSE #1 Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted April 3, 2009 Share Posted April 3, 2009 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. The good thing is that it's always surprising how good this old hardware works after all these years. Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted September 8, 2010 Share Posted September 8, 2010 (edited) 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 September 8, 2010 by Kr0tki Quote Link to comment Share on other sites More sharing options...
spookt Posted September 8, 2010 Share Posted September 8, 2010 Hmm, does anyone have a scan of this not in the Scribd archives. I have to sign up and pay money to be able to download a PDF Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted September 9, 2010 Share Posted September 9, 2010 (edited) The PDF is available here. Edited September 9, 2010 by Kr0tki Quote Link to comment Share on other sites More sharing options...
spookt Posted September 9, 2010 Share Posted September 9, 2010 The PDF is available here. Thank you! Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted September 9, 2010 Author Share Posted September 9, 2010 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 Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted September 10, 2010 Share Posted September 10, 2010 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. Quote Link to comment Share on other sites More sharing options...
Defender II Posted September 10, 2010 Share Posted September 10, 2010 I'd sugest you to post it here and also remove all ROMs from the earlier posts above. 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 Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted September 11, 2010 Share Posted September 11, 2010 (edited) 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 September 11, 2010 by Kr0tki Quote Link to comment Share on other sites More sharing options...
Defender II Posted September 13, 2010 Share Posted September 13, 2010 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? Quote Link to comment Share on other sites More sharing options...
+Mitch Posted September 14, 2010 Share Posted September 14, 2010 Where are all of the dumps from the Atari Cartridge Dumping Project? They were never released as far as I know. Mitch Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted September 14, 2010 Author Share Posted September 14, 2010 (edited) 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 September 14, 2010 by sup8pdct Quote Link to comment Share on other sites More sharing options...
Defender II Posted September 15, 2010 Share Posted September 15, 2010 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? Quote Link to comment Share on other sites More sharing options...
+Mitch Posted September 15, 2010 Share Posted September 15, 2010 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 Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted September 17, 2010 Share Posted September 17, 2010 (edited) 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 September 17, 2010 by Kr0tki 3 Quote Link to comment Share on other sites More sharing options...
Defender II Posted September 18, 2010 Share Posted September 18, 2010 Thanks for all of the info you have uncovered about the PAL OS & SALT checks. It is very interesting. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted August 8, 2018 Share Posted August 8, 2018 (edited) 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 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 August 8, 2018 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted August 9, 2018 Share Posted August 9, 2018 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. 5 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted August 9, 2018 Share Posted August 9, 2018 (edited) 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 August 9, 2018 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted August 10, 2018 Share Posted August 10, 2018 (edited) 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 August 10, 2018 by Kr0tki 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.