Jump to content
Sign in to follow this  
Larry

PAL 130XE?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

there were such machines, but eprom would be socketed

arabic machines have "star" symbol on nameplate

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites
there were such machines, but eprom would be socketed

arabic machines have "star" symbol on nameplate

 

We are talking about a 130XE here.. not a 65xe..

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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 by carmel_andrews

Share this post


Link to post
Share on other sites
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 by MEtalGuy66

Share this post


Link to post
Share on other sites
\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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by drac030

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...