Jump to content

Photo

Atari Rev B PAL Rom file


45 replies to this topic

#26 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,754 posts
  • Location:Australia

Posted Wed Apr 1, 2009 3:50 PM

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


#27 DjayBee OFFLINE  

DjayBee

    Moonsweeper

  • 299 posts
  • Location:Stuttgart, Germany

Posted Fri Apr 3, 2009 2:45 PM

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.

#28 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Wed Sep 8, 2010 2:10 PM

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, Wed Sep 8, 2010 2:11 PM.


#29 spookt OFFLINE  

spookt

    Stargunner

  • 1,787 posts
  • This is SPARTA(DOS)
  • Location:Sunderland, UK

Posted Wed Sep 8, 2010 2:16 PM

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 :(

#30 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Thu Sep 9, 2010 2:11 AM

The PDF is available here.

Edited by Kr0tki, Thu Sep 9, 2010 2:12 AM.


#31 spookt OFFLINE  

spookt

    Stargunner

  • 1,787 posts
  • This is SPARTA(DOS)
  • Location:Sunderland, UK

Posted Thu Sep 9, 2010 2:25 AM

The PDF is available here.


Thank you!

#32 sup8pdct OFFLINE  

sup8pdct

    Dragonstomper

  • Topic Starter
  • 882 posts
  • Location:australia

Posted Thu Sep 9, 2010 4:53 AM

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

#33 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Fri Sep 10, 2010 5:11 AM

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.

#34 Defender II OFFLINE  

Defender II

    Stargunner

  • 1,166 posts
  • Location:Traveling through space & time

Posted Fri Sep 10, 2010 3:11 PM

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

#35 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Fri Sep 10, 2010 8:28 PM

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?

Attached Files


Edited by Kr0tki, Fri Sep 10, 2010 8:33 PM.


#36 Defender II OFFLINE  

Defender II

    Stargunner

  • 1,166 posts
  • Location:Traveling through space & time

Posted Mon Sep 13, 2010 2:27 PM

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?

#37 Mitch OFFLINE  

Mitch

    Quadrunner

  • 6,550 posts
  • 7800 Guy
  • Location:Southern California, USA

Posted Mon Sep 13, 2010 9:01 PM

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


They were never released as far as I know.

Mitch

#38 sup8pdct OFFLINE  

sup8pdct

    Dragonstomper

  • Topic Starter
  • 882 posts
  • Location:australia

Posted Mon Sep 13, 2010 11:33 PM

[quote name='Mitch' date='Tue Sep 14, 2010 1:01 PM' timestamp='1284433301' post='2093987']
[/quote]

They were never released as far as I know.

Mitch
[/quote]

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

Attached Files


Edited by sup8pdct, Mon Sep 13, 2010 11:37 PM.


#39 Defender II OFFLINE  

Defender II

    Stargunner

  • 1,166 posts
  • Location:Traveling through space & time

Posted Wed Sep 15, 2010 3:05 PM

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?

#40 Mitch OFFLINE  

Mitch

    Quadrunner

  • 6,550 posts
  • 7800 Guy
  • Location:Southern California, USA

Posted Wed Sep 15, 2010 5:59 PM

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

#41 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Fri Sep 17, 2010 2:32 AM

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.

Attached Files


Edited by Kr0tki, Fri Sep 17, 2010 2:33 AM.

  • FULS , tf_hh and TheMontezuma like this

#42 Defender II OFFLINE  

Defender II

    Stargunner

  • 1,166 posts
  • Location:Traveling through space & time

Posted Sat Sep 18, 2010 12:14 AM

Thanks for all of the info you have uncovered about the PAL OS & SALT checks. It is very interesting.

#43 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 626 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Aug 8, 2018 2:20 AM

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, Wed Aug 8, 2018 2:38 AM.


#44 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Wed Aug 8, 2018 7:39 PM

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.
  • Stephen , FULS , tf_hh and 2 others like this

#45 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 626 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Aug 9, 2018 2:37 AM

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, Thu Aug 9, 2018 2:38 AM.


#46 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,129 posts
  • Location:Warszawa, Poland

Posted Fri Aug 10, 2018 12:23 PM

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, Fri Aug 10, 2018 12:25 PM.

  • Stephen likes this




1 user(s) are browsing this forum

1 members, 0 guests, 0 anonymous users


    luckybuck