morelenmir Posted June 2, 2015 Share Posted June 2, 2015 I asked this question as an aside during a different thread. I think it is important enough to have its own thread and maybe get some attention it would otherwise have missed. I also think it may well be interesting to others than just me. In the past I have asked several of the 'old hands' here what the difference is between the XL and XE OS Kernels. Basically I have been told they are practically identical and not to worry about it. However, I have since then come across four different ROM files for the different machines that I believe are ripped untouched from legitimate chips. There are labelled: Atari XL-XE OS REV. 01 (600XL) - CRC=643BCC98 Atari XL-XE OS REV. 02 (800XL) - CRC=1F9CD270 Atari XL-XE OS REV. 03 (130XE - PAL) - CRC=CBED0B4C Atari XL-XE OS REV. 03 (800XE-130XE) - CRC=29F133F7 The first two seem fairly unambiguous as the Kernels for the 600XL and 800XL respectively. However, #3 and #4 are clearly different OS versions, yet both claim to come from the 130XE. What are the differences? I have only recently learned what the 800XE machine was, but while it has its own entry I notice there is no kernel for the "65XE". Was it identical to the "130XE"? Also, why is the PAL version marked as distinct while none of the others are recorded as either PAL or NTSC? Finally, which of these can be considered the 'Stock 130XE' OS? Presumably #4? In terms of emulation, neither "Altirra" nor "Atar800" and its variants make any distinction between the XL and XE Kernel, despite the former programme being able to explicitly run a simulation of the seperate XL's and the XE's. Surely this is a contradiction as in reality they clearly had very distinct OS Kernels? I have also heard that the difference between the XL and XE ROMs might be as simple as the latter possessing a marginally different 'Self-Test' routine to accommodate the extra RAM it offered. Is this the only difference? I would really like to be able to hammer these details out in my mind once and for all. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 2, 2015 Share Posted June 2, 2015 One in Altirra is marked 'Patched for NTSC'... I wonder what exactly that means (and I think its the AtariXL.rom that has been around for ages), its it ok to run under PAL? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 2, 2015 Author Share Posted June 2, 2015 One in Altirra is marked 'Patched for NTSC'... I wonder what exactly that means (and I think its the AtariXL.rom that has been around for ages), its it ok to run under PAL? I would upload the ROM's for you to have a look at, but I imagine the people who run the board might not like that given how touchy copyright can be. Afterall, its only 25 years since you could buy any of this in Boots! The "Ultimate1MB" comes with a 'Stock XE' kernel, but I am not sure which it was now as I flashed over it. Update: The "Atari ROM Checker" sounds like it might be handy for this problem: http://www.wudsn.com/productions/atari800/atariromchecker/help/AtariROMChecker.html Although it is implemented as a Java script... Not my favourite personally. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 2, 2015 Share Posted June 2, 2015 The XL Rom is supposedly compatible with both. The keyboard delays are set by software and tape AUDF tables cover both machines. Early XL Rom differences - one of the most prominent is one will restart as soon as a cartridge state change is detected, the other does and endless wait for user to press Reset which generates a coldstart. Later XE - adjusted to test 128K Ram if installed. This Rom only executes wait if cart state changes (?) XEGS - Select key and keyboard attached state affect startup behaviour. Is this OS ever present on other machines? (probably no) Really it's a mystery to me why a specific Pal or NTSC OS would exist at or after release of the 800XL. Also, I have an 800XE but no idea if the OS in that is different to most other XL/XEs. Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted June 3, 2015 Share Posted June 3, 2015 (edited) However, I have since then come across four different ROM files for the different machines that I believe are ripped untouched from legitimate chips.They aren't. The one you call "Atari XL-XE OS REV. 03 (130XE - PAL)" is not an original OS ROM. It's a hack of the original Rev. 3, modified so that it uses PAL timings for cassette loading/saving even on NTSC machines. Probably useful for NTSC systems with an ANTIC swapped with a PAL one. For details on all OS revisions, download the file from that post (also read the first post in that topic) and read the README file included in the archive. Edited June 3, 2015 by Kr0tki 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 3, 2015 Author Share Posted June 3, 2015 They aren't. The one you call "Atari XL-XE OS REV. 03 (130XE - PAL)" is not an original OS ROM. It's a hack of the original Rev. 3, modified so that it uses PAL timings for cassette loading/saving even on NTSC machines. Probably useful for NTSC systems with an ANTIC swapped with a PAL one. For details on all OS revisions, download the file from that post (also read the first post in that topic) and read the README file included in the archive. Fascinating work Krotki!!! Although I will say, they are not what I call them. Those labels were given in the accompanying *.NFO file for the public FTP directory from which I downloaded an entire archive of various hardware ROM's. It included vapour-ware like the XLD and also curiosities like uncommon floppy disk drives, printers and even the XEP-80 if memory serves. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 3, 2015 Share Posted June 3, 2015 In terms of emulation, neither "Altirra" nor "Atar800" and its variants make any distinction between the XL and XE Kernel, despite the former programme being able to explicitly run a simulation of the seperate XL's and the XE's. Surely this is a contradiction as in reality they clearly had very distinct OS Kernels? I have also heard that the difference between the XL and XE ROMs might be as simple as the latter possessing a marginally different 'Self-Test' routine to accommodate the extra RAM it offered. Is this the only difference? The OSes for the XL/XE/XEGS are interchangeable, for the most part. The most prominent feature of the 130XE is the extended RAM, which doesn't require (or have) OS support to use, and no one cares much about the self test. The XEGS version (v4) does have additional support for detecting the keyboard and activating the game ROM, but you can use it on an XL/XE without problems, and using the XL/XE version on the XEGS just means the game ROM doesn't activate. The main thing that Altirra is concerned about is just whether the OS is 10K (400/800) or 16K (XL/XE/XEGS). It has a separate XEGS category, but that's just so it can prefer an XEGS-compatible ROM when that hardware more is in use. One in Altirra is marked 'Patched for NTSC'... I wonder what exactly that means (and I think its the AtariXL.rom that has been around for ages), its it ok to run under PAL? It's not patched for NTSC, but a patched version of the NTSC one. The ATARIOSB.ROM that's commonly used has been hacked in two ways. First, it has a memory test stop at $D000 so that it can work with 52K of memory. Second, it has a write to PORTB NOP'd out. This is presumably either so that it can be soft-loaded into RAM on an XL/XE or so that it can work in XL/XE mode on an older emulator that doesn't emulate the overlaid ORB/DDRB registers of the PIA properly. I'm not really an OS ROM expert, though, so others can probably chime in more about the history here. The unmodified versions of the XL/XE OS are fine to run in NTSC or PAL as long as you have a real NTSC/PAL machine. They're designed to automatically switch timings depending on the type of machine you have. However, if you have a mixed-mode computer with a PAL ANTIC and NTSC GTIA, this will not work as the timings need to be based on ANTIC and the detection checks the GTIA. For the most part only the cassette timings matter, so even this is not necessarily a serious problem -- the keyboard repeat rate is not critical. One difference that is often overlooked and not that well known is that the v4 XL/XE OS has a fix for a bug in SIO that can occasionally cause transfers to time out and retry. This is due to misordered writes to SEROUT and CHKSUM with IRQs enabled and can result in disk transfers occasionally pausing. For printers it is even worse due to the long timeout and was apparently known as the "nine minute hang." The commonly used v2 (ATARIXL.ROM) doesn't have this fix. It's not a dealbreaker since many people happily used v2 on their real hardware, but it'd be a reason to prefer v4. 4 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 3, 2015 Author Share Posted June 3, 2015 MANY thanks Phaeron!!! That is exactly the kind of thing I was hoping to learn. Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted June 3, 2015 Share Posted June 3, 2015 (edited) The most prominent feature of the 130XE is the extended RAM, which doesn't require (or have) OS support to use, and no one cares much about the self test.What's funny is that apparently Atari themselves didn't care about it. Due to improper setting of PORTB bits, that new Rev. 3 Self-Test only tests two extended RAM banks instead of four. Either it's a simple bug, or an artifact of the bits in PORTB being mapped differently during development of the 130XE. Whatever the cause, they never bothered to fix it. The ATARIOSB.ROM that's commonly used has been hacked in two ways. First, it has a memory test stop at $D000 so that it can work with 52K of memory. Second, it has a write to PORTB NOP'd out. This is presumably either so that it can be soft-loaded into RAM on an XL/XE or so that it can work in XL/XE mode on an older emulator that doesn't emulate the overlaid ORB/DDRB registers of the PIA properly. I'm not really an OS ROM expert, though, so others can probably chime in more about the history here.Yeah, that ATARIOSB.ROM was bundled with PC Xformer, and was hacked specifically to work with that emulator. And, for years, it has been mislabelled in Atari800Win as "OS rev. B PAL", therefore it still resides with this name in some ROM collections. One difference that is often overlooked and not that well known is that the v4 XL/XE OS has a fix for a bug in SIO that can occasionally cause transfers to time out and retry.This bugfix is already in rev. 3. Edited June 3, 2015 by Kr0tki 3 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 3, 2015 Share Posted June 3, 2015 I would upload the ROM's for you to have a look at, but I imagine the people who run the board might not like that given how touchy copyright can be. Afterall, its only 25 years since you could buy any of this in Boots! The "Ultimate1MB" comes with a 'Stock XE' kernel, but I am not sure which it was now as I flashed over it. Update: The "Atari ROM Checker" sounds like it might be handy for this problem: http://www.wudsn.com/productions/atari800/atariromchecker/help/AtariROMChecker.html Although it is implemented as a Java script... Not my favourite personally. Regarding owning copyright over 30+ year old items, if you own it and are doing nothing with it then don't get annoyed about it being cared for by others, if you ARE doing something with it then you will get the full respect of the community. Anyway, thanks to all for the checkers, I have so many versions of the OS roms it would be great to divide the hacks from the proper core dumps, I presume the core dumps actually work fine with Altirra (just that I saw Krotki say that one rom was hacked to work with PC Xformer). 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 3, 2015 Share Posted June 3, 2015 A decent emulator (like Altirra) should work with any OS Rom that works on the real machine. That of course is sometimes provisional on disabling things like patches, hacks, speedups, optimisations that "break the rules" to improve functionality. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 3, 2015 Share Posted June 3, 2015 (edited) Thanks Rybags and all, somehow in my sleepy state I missed most of the actual answers to my original post before I replied, so thank you all for the answers and ignore that previous reply Really should listen to my body and sleep at the right times.. When I was younger I could sit up all night playing and then go off to a full days work and repeat it with only a couple of hours sleep, now I feel like I need a sleep mid way through the afternoon let alone late nights....Mind young, body ancient Bit like an XL Edited June 3, 2015 by Mclaneinc 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 3, 2015 Share Posted June 3, 2015 I really appreciate the great work from Kr0tki. In the beginning of the SIO2BT project I was totally confused about various OS ROM versions. Until I found his post (and attachment). @Kr0tki Many Thanks for that! Does anybody know what is the legal status of the ROMs at the moment? For the SIO2BT project I prepared a tool for patching "well known" ROMs, but it would be more convenient to provide the ROMs themselves. Quote Link to comment Share on other sites More sharing options...
Mathy Posted June 3, 2015 Share Posted June 3, 2015 Hello guys Due to improper setting of PORTB bits, that new Rev. 3 Self-Test only tests two extended RAM banks instead of four. .... Whatever the cause, they never bothered to fix it. Could somebody please fix this? Sincerely Mathy PS how hard would it be to test more than four banks? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 4, 2015 Author Share Posted June 4, 2015 Hello guys Could somebody please fix this? Sincerely Mathy PS how hard would it be to test more than four banks? Yep, this suggestion gets my vote as well! I don't have anything against hacked ROM's per-se - so long as I know how and why they were hacked and also have access to the real deal if necessary. A modded self-test that supported and tested the RAM in modern expansions all the way up 1088 Rambo and beyond would be very cool. I know there is 'XRAM.COM', but I don't find that especially user-friendly while a built-in and improved memory self-test would be awesome. Maybe also do something with the audio/video one as well to support the VBXE. Now that would be amazingly cool - like a built-in demo that was specifically made to showcase and test the VBXE/RAM situation in many modern XL's/XE's. 1 Quote Link to comment Share on other sites More sharing options...
Mathy Posted June 4, 2015 Share Posted June 4, 2015 Hello morelenmir, folks It shouldn't be to hard to fix the bug in the routine (testing only 2 instead of 4 banks). Let's focus on that first. If testing more than 4 banks is possible/easy, why not. But if somebody does that, let's test all the bit combinations and even check how bits 4 and 5 are used. Adding more stuff would be nice, but let's focus on fixing the bug. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 5, 2015 Share Posted June 5, 2015 What's funny is that apparently Atari themselves didn't care about it. Due to improper setting of PORTB bits, that new Rev. 3 Self-Test only tests two extended RAM banks instead of four. Either it's a simple bug, or an artifact of the bits in PORTB being mapped differently during development of the 130XE. Whatever the cause, they never bothered to fix it. I looked at BB000001 Rev. 3 (1985-03-01) and in your README document I found: "Compared to rev. 2, this OS version contains a bugfix in CHKSUM initialisation (previously fixed in the prototype BB000002 Rev. 3 (1984-03-23)), and the following changes in Self Test: - Memory Test: support for the additional 130XE memory, and shortening of the delay loops so that the test performs faster." Do you mean that this is buggy? Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted June 5, 2015 Share Posted June 5, 2015 Yes. And it is indeed very easy to fix. Grab the sources and look for comments around the table called TXEB. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 5, 2015 Share Posted June 5, 2015 (edited) Thanks. Now I understand Bits 2-3 control memory banks (and not bits 1-2 as it is wrongly coded in the OS). PORTB Bit 2,3 Bank 0 0 0 0 1 1 1 0 2 1 1 3 STM13 LDA PORTB AND #%11100011 LDX STXEB ORA TXEB,X STA PORTB It is: TXEB DB $0,$2,$4,$6 $0 = 0000 $2 = 0010 $4 = 0100 $6 = 0110 It should be: TXEB DB $0,$4,$8,$C $0 = 0000 $4 = 0100 $8 = 1000 $C = 1100 Edited June 5, 2015 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
Mathy Posted June 5, 2015 Share Posted June 5, 2015 Hello guys Why "#%11100011"? I don't know a lot about this stuff, but it looks like bit 4 is zero'd out, but bit 5 isn't. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 5, 2015 Share Posted June 5, 2015 Bit 5 is the ANTIC bank enable bit, and presumably it's don't care in the case of the RAM test. As long as bit 4=0, the CPU will see the extended bank. Quote Link to comment Share on other sites More sharing options...
xzerix Posted June 8, 2015 Share Posted June 8, 2015 (edited) I tried creating a patched Rev 3 and Rev 4 ROM using the information above. All works ok (under emulation - Altirra) but crashes when it gets to the extended memory test part if you have Either 320k Compy, 576k Compy or 1088k configurations, so perhaps it's just as well it wasn't "fixed". (Altirra's 320k Rambo and 576k options don't cause a problem, so I'm guessing it's to do with how the Compy versions bank in the extra memory?) Edited June 8, 2015 by xzerix Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 9, 2015 Share Posted June 9, 2015 In Altirra, the Compy and 1088K modes use the self-test bit (bit 7) for banking, so whenever the extended memory window is enabled, the self-test ROM goes away. This causes a crash when the self-test tries to bank in the extended memory window at $4000-7FFF, on top of itself at $5000-57FF. In a 130XE configuration, this is fine because the self-test ROM has priority over the extended memory window. Now, you might ask, why is the self-test trying to enable the extended memory window under itself? The answer is that the self-test doesn't test $5000-57FF. It skips it and runs a delay routine that makes it look like it's taking time testing that memory. I guess running a fake delay routine was easier than copying down a piece of code to actually test memory. Per the sources, it also looks like there are a couple of regions in main memory that are not tested either, specifically pages 0-3 and $30-3F. Honestly, I'm not sure it's worth trying to fix the XL/XE OS self-test -- better just to get a real memory testing program, one that tests all memory and also writes more than one pattern. 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted June 9, 2015 Share Posted June 9, 2015 Why not replace the XL/XE Self-Test completely with a good program that will fit in ROM? 1 Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted June 9, 2015 Share Posted June 9, 2015 (edited) Per the sources, it also looks like there are a couple of regions in main memory that are not tested either, specifically pages 0-3 and $30-3F.Actually 0-3 and 30-33. Let's all remember: according to Self Test's design document, it's purpose was to "give the user a sense of confidence about their Atari computer, as well as being an important sales tool. Form is more important than function, in all cases of conflict between form and function." Even after fixing the XE banks issue, the memory test is still a worthless piece of shit IMHO. Edited June 9, 2015 by Kr0tki 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.