Jump to content
IGNORED

Altirra and OS ROM revisions


morelenmir

Recommended Posts

I am a little confused with the emulation of xl and xe systems.

 

After a bit of reading I understand that 600xl's ran from revision 1 OS ROM's, 800xl's from rev 2 and 130xe's from rev 3. There was also some degree of further complexity with the versions of BASIC the xl's and xe's offered, but they sound more like a standard progression of bug fixes. However when using Atirra there is only one OS ROM firmware slot and option for all three xl/xe machines - the 'atarixl.rom'. Conversely there is the choice of 'osa'/'osb' when running as an atari 800 model and the amazingly cool 'XEGS' ROM/'game' slots and firmware options.

 

Is it simply a case that the three revisions were pretty much identical and it does not effect the quality of emulation if we use the same OS for all XL/XE machines? Alternately would it be better to direct Altirra to the 'revision 3' ROM through the 'other' firmware slot and according use the 'other' option when wishing to run as a 130XE?

 

I must admit to being rather stumped!

Link to comment
Share on other sites

Altirra, for the most part, doesn't care about the specifics of the exact OS used and simply runs the OS code. There are specific cases when it does:

  • The OS-A and OS-B ROMs are only 10K, while the XL/XE and XEGS ROMs are 16K, so you can't mix those. The Other OS slot also corresponds to a 16K ROM.
  • Specific slots are used by the Default option. For instance, if XL/XE hardware is selected, the Default option will use the XL/XE OS if available, and the HLE kernel if not.
  • The various OS patches rely on the standard OS entry points, like SIOV, and won't work or can break OSes that don't have these entry points. Of course, any such OS wouldn't run any regular software either, so this is mostly a moot point.
  • The Fast Boot option accelerates two specific routines in the XL/XE OS, the checksum and memory test routines. The emulator checks for these routines and automatically bypasses the acceleration if they are not present.
  • The R: device requires a known RTS location ($E4C0). This location is in both the OS-B and XL/XE ROMs and is also depended upon by the real 850 firmware.

 

Altirra never patches the OS ROM, even when the "patch" options are enabled. This means that checksum tests pass unmodified. It also means that copying the OS ROM to RAM will disable patch acceleration.

 

Basically, the emulator is designed to work with any OS ROM that targets Atari's public OS entry points and supports the usual set of compatibility ones.

Link to comment
Share on other sites

That is fairly straightforward Avery and makes Altirra more versatile than I thought. I am now using a 16k OS ROM that came from a PAL 130XE as my 'XL/XE' firmware - crc CBEDOB4C.

 

My next question about ROM's is focussed on BASIC. I did not know until yesterday that there was a '130xe' version of Atari BASIC, which contained many missing keywords. It seems to come as an '.oss' file that may be a cartridge image of some kind. Is there anyone who knows how to handle/convert these types of image and if it is indeed possible to run the file as the default BASIC firmware?

Edited by morelenmir
Link to comment
Share on other sites

I did not know until yesterday that there was a '130xe' version of Atari BASIC, which contained many missing keywords.

 

I don't know who threw this misinformation in the forum (I noticed it in another thread) but there is no such thing as a 130XE version of Atari BASIC. Someone probably wanted to mention "BASIC XE"

 

http://en.wikipedia.org/wiki/Optimized_Systems_Software#BASIC_XE

  • Like 1
Link to comment
Share on other sites

MANY Thanks Kr0tki!!!

 

The cartridge image for 'BASIC XE' that is in among the others in this collection does indeed work. The previous example i got hold of was from the "ftppigwa" site and I am quite surprized it was indeed faulty - I understand they have an excellent reputation among the atari community. I guess they cannot vet every piece of software/firmware that comes their way!!! Alternately I am starting to suspect there is a functional difference between the raw image that might be archived for burning to an eeprom - 'xepal.128' say - and a ROM image that Altirra or another emulator can directly utilize.

 

This does touch on a bigger issue, which is how does the end user of abandoneware such as 'BASIC XE' or 'ACTION' say or any other cartridge image that is almost certainly LONG divorced from its original manuals and specification determine what type of mapping it uses? Is there a utility somewhere than can scan the cartridge image and determine its format?

Edited by morelenmir
Link to comment
Share on other sites

The previous example i got hold of was from the "ftppigwa" site and I am quite surprized it was indeed faulty - I understand they have an excellent reputation among the atari community.

It's just an FTP server with bunch of stuff gathered from those old CD collections that once circulated among the Atari scene. No verification involved.

 

Alternately I am starting to suspect there is a functional difference between the raw image that might be archived for burning to an eeprom - 'xepal.128' say - and a ROM image that Altirra or another emulator can directly utilize.

No difference - the BASIC XE image from FULS' collection above is a raw ROM dump. It's just that in the days before the Internet people really didn't know better and sometimes dumped their cartridges incorrectly, for example using wrong mapping or wrong order of banks, and then didn't verify the results. For example, the BASIC XE image hosted here at AtariAge has banks in incorrect order, which renders it unusable for emulators and EPROM burning alike.

 

Is there a utility somewhere than can scan the cartridge image and determine its format?

Not yet. I'm not sure it's possible to write such a tool without having to compare an image against a known list of images at some point.

 

In the thread linked earlier, one of my last posts contains a list of all known Atari cartridges, together with their mappings and CRC32 checksums. You can verify your images against it.

Edited by Kr0tki
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...