+Larry Posted March 2, 2009 Share Posted March 2, 2009 I have a "new" 4-ram chip PAL XE MB that has a soldered-in OS in regular eprom. I've never seen an NTSC MB with an eprom OS -- always rom. Perhaps this was common in European-released 130XE's? It has a sticker on it that says: OPER. SYSTEM XE/XL COMPTR. C300717-001A 3/14/89 FBCF Is the FBCF of any significance -- i.e. tells anything of significance about this particular model? Thanks, Larry Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted March 2, 2009 Share Posted March 2, 2009 Where did you get that motherboard? Hook it up, and in BASIC, hit the caps lock key (for lower case mode) and see if it types in arabic.. Also, run the "memory" part of the self-test and see if it does the 4 extra bars for testing the extended banks.. Quote Link to comment Share on other sites More sharing options...
candle Posted March 3, 2009 Share Posted March 3, 2009 there were such machines, but eprom would be socketed arabic machines have "star" symbol on nameplate Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 3, 2009 Author Share Posted March 3, 2009 Where did you get that motherboard? Hook it up, and in BASIC, hit the caps lock key (for lower case mode) and see if it types in arabic.. Also, run the "memory" part of the self-test and see if it does the 4 extra bars for testing the extended banks.. (I think) this is a PAL-B machine that I got from B&C. It displays under PAL-B and PAL-I. No Arabic. Under Ram, it has three rows of 16 blocks, then has one line of 4 longer rectangles under the 3 rows of ram blocks. I checked 2 other 130XE's -- one displays the extra row of 4 long bars, and one does not. The one that doesn't is a very early 130XE -- ordered as soon as they were released. Somewhat like this: X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X XXXX__XXXX__XXXX__XXXX (Ignore the underscores) Unfortunately, my screen capture doesn't work with the display in PAL mode. -Larry Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 3, 2009 Share Posted March 3, 2009 What does the SysInfo say about the ROM? I.e. version number etc. (DL the latest one) Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 4, 2009 Author Share Posted March 4, 2009 What does the SysInfo say about the ROM? I.e. version number etc. (DL the latest one) A most excellent suggestion, drac030! I'll d/l the latest version and give it a try. -Larry Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted March 4, 2009 Share Posted March 4, 2009 Just so you know, theres a TON of NTSC 130XEs out there that dont do the "extended bank self test." In fact, I'd say that more commonly than not, they have the ROM that doesn't have it.. PAL machines may be a different story... And XEGS machines all have that version of the OS.. They just dont have any extended banks to test.. Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted March 4, 2009 Share Posted March 4, 2009 there were such machines, but eprom would be socketedarabic machines have "star" symbol on nameplate We are talking about a 130XE here.. not a 65xe.. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 4, 2009 Share Posted March 4, 2009 Pretty sure my 130XE doesn't test XRAM. Remembering here that the PAL versions were probably a near simultaneous release, unlike some earlier models. Also, the exact same OS code in XL/XE covers PAL/NTSC unlike OS-A/B that was hard-coded for it's particular region. Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 4, 2009 Author Share Posted March 4, 2009 Pretty sure my 130XE doesn't test XRAM. Remembering here that the PAL versions were probably a near simultaneous release, unlike some earlier models. Also, the exact same OS code in XL/XE covers PAL/NTSC unlike OS-A/B that was hard-coded for it's particular region. The info of interest from SI218 is Rom-resident OS XL OS OS serial number BE 01 03 OS revision date 01.Mar.85 -Larry Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 5, 2009 Share Posted March 5, 2009 OS serial number BE 01 03 Are you sure that this is not BB 01.03? Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 5, 2009 Author Share Posted March 5, 2009 OS serial number BE 01 03 Are you sure that this is not BB 01.03? The text is very difficult to read on my display -- it very well could be as you say. -Larry Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted March 6, 2009 Share Posted March 6, 2009 (edited) The initial xe's used the same self test code as per the 6/800xl (i.e only tests the 16k rom and 48k ram) The xegs had a modified self test that apparently allowed you to test for extended memory (i.e upto 128k if mem recalls) There was an article/news reprt in page 6 i think that said that Atari were thinking of releasing xe's with the modified self test (as per the xegs) I dunno if atari got around to releasing them, I think they might have as i have told in the past by some european A8 users on compsys atari8 that they have xe's with the modified self test code (xegs alike) Edited March 6, 2009 by carmel_andrews Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted March 6, 2009 Share Posted March 6, 2009 (edited) The initial xe's used the same self test code as per the 6/800xl (i.e only tests the 16k rom and 48k ram) The xegs had a modified self test that apparently allowed you to test for extended memory (i.e upto 128k if mem recalls) There was an article/news reprt in page 6 i think that said that Atari were thinking of releasing xe's with the modified self test (as per the xegs) I dunno if atari got around to releasing them, I think they might have as i have told in the past by some european A8 users on compsys atari8 that they have xe's with the modified self test code (xegs alike) Yep.. I ripped the upper 16k out of an XEGS rom, burned it into an EPROM and used it in my XE for a long time. If you look at the emulator roms out there, that version of the OS is commonly reffered to as v. 04.. Im not sure what all differences/improvements/enhancements it has over the stock XL/XE OS, but I just liked the fact that the self-test would at least SHOW that it was a 128k machine.. Edited March 6, 2009 by MEtalGuy66 Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 8, 2009 Share Posted March 8, 2009 \If you look at the emulator roms out there, that version of the OS is commonly reffered to as v. 04.. Im not sure what all differences/improvements/enhancements it has over the stock XL/XE OS Outside the SELF-TEST, practically none. SIO-receive routine has two instructions swapped, and it is obscure, why they have swapped them. Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted March 8, 2009 Share Posted March 8, 2009 Can you identify the instructions? The SIO routines have had a bug in them from Day One - in the checksum routines. If you get an interrupt during the checksum, it pulls the checksum value from the next byte in the serial register, giving you an error. Reversing the instructions fixes it. This was written up somewhere, long ago, but I can't find reference to it any more. (I think it was Bill W. in Compute) Bob \If you look at the emulator roms out there, that version of the OS is commonly reffered to as v. 04.. Im not sure what all differences/improvements/enhancements it has over the stock XL/XE OS Outside the SELF-TEST, practically none. SIO-receive routine has two instructions swapped, and it is obscure, why they have swapped them. Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 9, 2009 Share Posted March 9, 2009 (edited) Can you identify the instructions? The SIO routines have had a bug in them from Day One - in the checksum routines. If you get an interrupt during the checksum, it pulls the checksum value from the next byte in the serial register, giving you an error. Reversing the instructions fixes it. This was written up somewhere, long ago, but I can't find reference to it any more. (I think it was Bill W. in Compute) I cannot find my annotated copy of the relevant OS listing, but judging from another (not annotated) copy of the same listing, these instructions are in the SIO-send routine ($EA88 in 800XL OS), not as I have written above, in SIO-receive. Before entering the loop that waits for the I/O interrupts to come, the 800XL OS does this: lda ($32),y;load first byte from the buffer sta $d20d;store it into the SEROUT sta $31;init checksum value with it loop: ... Now the 130XE OS has the last two instructions reversed: lda ($32),y;load first byte from the buffer sta $31;init checksum value with it sta $d20d;store it into the SEROUT loop: ... Now the change doesn't seem to make much sense, as, at least to my knowledge, the serial interrupt cannot come immediately after storing the byte to the SEROUT, as the byte has to be emitted first, and at 19200 it takes ~1000 clock cycles, so there is plenty of time to execute the STA $31 before. Even VBL - if it occurs immediately after STA SEROUT - won't hurt, as the CRITIC flag is set and only the 1st phase of the system VBL code is executed, which is much shorter than 1000 clocks. Edited March 9, 2009 by drac030 Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 9, 2009 Share Posted March 9, 2009 It could cause problems in theory... probably a 1 in 15,000 type situation. Store to SEROUT occurs, VBlank Interrupt occurs. Serial Output Needed IRQ happens during VBlank. VBlank returns, IRQ gets serviced before Checksum is initialised. Doesn't Serial Output Needed occur almost as soon as a byte starts transmitting? As opposed to Serial Output Complete, which should be after the Stop Bit has been sent. Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 9, 2009 Share Posted March 9, 2009 Doesn't Serial Output Needed occur almost as soon as a byte starts transmitting? As opposed to Serial Output Complete, which should be after the Stop Bit has been sent. Right, the data sheet states, that the Output Needed interrupt occurs after the contents of the SEROUT to the output shift register. So, contrary to what I thought, the change isn't entirely cosmetic to make the code elegant. It of course depends, how many cycles it takes to transfer the SEROUT to the shift register and request the IRQ. Quote Link to comment Share on other sites More sharing options...
ijor Posted March 9, 2009 Share Posted March 9, 2009 Doesn't Serial Output Needed occur almost as soon as a byte starts transmitting? As opposed to Serial Output Complete, which should be after the Stop Bit has been sent. Right, the data sheet states, that the Output Needed interrupt occurs after the contents of the SEROUT to the output shift register. This is obvious behaviour. If the interrupt would trigger after the byte was completely sent, then the double buffering (holding and shift registers) would be wasted, and transmission wouldn't be so efficient. What is not so obvious, is when the transmission starts, which doesn't have to be concurrently (or even immediately after) with transferring from SEROUT to the shift register. In the case of Pokey, transmission won't start until the next serial clock pulse, and the serial clock is not reset by the Pokey transmitter. But the interrupt doesn't wait for transmission to start, it is triggered as soon as SEROUT is transferred to the shift register. It of course depends, how many cycles it takes to transfer the SEROUT to the shift register and request the IRQ. If the shift register was empty (as it would be the case here), then it would take about three cycles. Even then, the interrupt could never happen before the next instruction. The race would happen only if an NMI (or other Pokey interrupt) was already being triggered, and then the transmitter ISR would execute as soon as the NMI (or other IRQ) handler returns. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 9, 2009 Share Posted March 9, 2009 I was probably a little off with my "1 in 15,000"... If DLIs are going on, it could be a greater chance. Keyboard activity as well. I suppose if you sat there long enough tapping and doing I/O, you could cause it to foul up reasonably often enough. Command frames for input commands should be liable too. But, I'd guess that thanks to Retry Logic, we've all probably encountered it but never noticed. 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.