800 XL BASIC Crashes Constantly--help/advice needed!

[lord_mike]

Hello again! In a recent post, I mentioned that I just acquired a used 800XL from a rummage sale. Everything seemed to be working fine at first--games loaded and ran from cartridge and from disk without issue. Then I started loading in some old BASIC programs, but they would start crashing violently for no reason (with spectacular video displays at times) while running or even LIST-ing them.I thought that the disk files might be corrupt at first, but then I started typing in short programs directly, and the same crashes would occur after listing them repeatedly or running them for a short time--even after a power off reset. The problem seems worse after the computer's heated up a bit, but it doesn't take long to get in this sick state. It seems like a memory leak of some sort eventually hitting a bad memory location, but the memory test shows up fine and games seem to work just fine!

 

The weird thing is that this only seems to happen in BASIC. As I mentioned before, games and other cartridges seem to work fine. It's not exclusive to the built-in Rev B BASIC, either. I inserted the Rev A cartridge, checked the version with PEEK, and was having the same problem even in cartridge BASIC. I ran the built-in memory checker, everything came up green. I restored the original power supply (I replaced the original ingot power adapter with one described here: http://atariage.com/forums/topic/241176-800xl-replacement-power-adapter/ ) thinking that may be the issue, but that didn't make a difference, either. I tested both power supplies directly and under a 6 ohm load--both supplies kept voltage around 5.15 volts.

 

I am at a loss as to what to do or where to begin. My BASIC is sick, but every test shows the computer to be in perfect health. What could be the problem? Where do I start to look? Any advice or input would be greatly appreciated!! I'd like to be able to run my old programs again!

 

Thank you, Atari doctors, for looking at my patient! If you'd like, I can show you pictures of my crashes. They are quite spectacular, if they weren't so disturbing...

 

Edit: New interesting symptom... I would enter PRINT FRE(0) to see how much memory was left, and I would either get the expected number around 38,000, a number like 0.374626 , or a syntax error--a completely different result each time I ran the command. Very, very weird... My poor Atari is so sick... Can anyone help?

Edited August 4, 2015 by lord_mike

[Paul Westphal]

Bad O.S., and Bad Basic. Replace.... OR.. The first ram chip might be bad....basic calls the first 16k. Best electronics has both.

[thorfdbg]

Edit: New interesting symptom... I would enter PRINT FRE(0) to see how much memory was left, and I would either get the expected number around 38,000, a number like 0.374626 , or a syntax error--a completely different result each time I ran the command. Very, very weird... My poor Atari is so sick... Can anyone help?

 

I would possibly understand this if it would only happen with the build-in BASIC, but otherwise the basic cartridge is in no way different from any other cart. Thus, if the problem does not appear with other carts, then just by pure chance. It would guess it is either a problem with the RAM or the MMU.

 

What does the self test say?

[lord_mike]

 

I would possibly understand this if it would only happen with the build-in BASIC, but otherwise the basic cartridge is in no way different from any other cart. Thus, if the problem does not appear with other carts, then just by pure chance. It would guess it is either a problem with the RAM or the MMU.

 

What does the self test say?

 

Thank you thor and Paul for your responses. They are greatly appreciated! I used peek(43234) to verify the cartridge was in and running. The system self test says everything is just fine and dandy--all green, and I seem to have no problem playing games from cartridge or disk, so it's really bizarre. I will play a full game of Star Raiders and another long running game from disk tonight to see if anything weird happens after playing for a long time. It's really baffling! I was hoping that the cartridge basic would fix my problems, but apparently not, unless I somehow blew the basic cartridge, too... maybe one of the socketed chips is loose or something. I'll see if I can go under the hood later tonight and see in any of the chips are loose or running hot/cold.

[lord_mike]

I talked to the folks at Best Electronics... prognosis is not good. It could be ANY of the chips, and who knows which one. They advised me to start swapping chips with a good working 800XL to see what's the matter, but I don't really have that option, unfortunately. I'll open it up and see if I can find any hot or cold chips, but other than that, not sure what else I can do... I'm open to any and all ideas out there...

[Joey Z]

I talked to the folks at Best Electronics... prognosis is not good. It could be ANY of the chips, and who knows which one. They advised me to start swapping chips with a good working 800XL to see what's the matter, but I don't really have that option, unfortunately. I'll open it up and see if I can find any hot or cold chips, but other than that, not sure what else I can do... I'm open to any and all ideas out there...

seeing as how the BASIC cart works, the problem might be the OS. Does the 'self test' check the 'FP ROM'? I had BASIC that was crashing due to a bad FP ROM in my 400. This is not a separate chip in the 800XL, but it could be that the issue lies in this portion of the ROM. If you can dump the ROM, and post it here, we can check it, run it in an emulator and see if the symptoms persist, etc.

 

Otherwise, it could be pretty much any of the other chips, but OS ROM is possible to check.

 

You can save your ROM by booting, say, DOS 2.5 and doing a 'binary save' on the range C000 to CFFF and another on range D800 to FFFF.

Edited August 5, 2015 by Joey Z

[Keatah]

Bad O.S., and Bad Basic. Replace.... OR.. The first ram chip might be bad....basic calls the first 16k. Best electronics has both.

 

??

First bank. Each of the chip holds a 1 bit out of a byte. The entire memory map is spread across the 8 chips.

 

Each chip does not hold complete 8k blocks.

[Joey Z]

 

??

First bank. Each of the chip holds a 1 bit out of a byte. The entire memory map is spread across the 8 chips.

 

Each chip does not hold complete 8k blocks.

oh, yes, I meant to mention that mistake in my other post, before a misunderstanding occurred. Good thing you caught it though.

[lord_mike]

seeing as how the BASIC cart works, the problem might be the OS. Does the 'self test' check the 'FP ROM'? I had BASIC that was crashing due to a bad FP ROM in my 400. This is not a separate chip in the 800XL, but it could be that the issue lies in this portion of the ROM. If you can dump the ROM, and post it here, we can check it, run it in an emulator and see if the symptoms persist, etc.

 

Otherwise, it could be pretty much any of the other chips, but OS ROM is possible to check.

 

You can save your ROM by booting, say, DOS 2.5 and doing a 'binary save' on the range C000 to CFFF and another on range D800 to FFFF.

 

That certainly would make sense. I doubt many games would have used the built-in FP functions which would spare them from accessing the error. I remember reading that the Star Raiders author implemented his own functions for performance reasons. The self test has two "blocks" for ROM. I assume one is for BASIC and the other is the OS chip. Best Products told me that the Atari self tests aren't that great, so who knows what the tests really check.

 

I will do a binary save like you recommended and post it here when I can. Thank you so much for offering to analyze it for me! It's greatly appreciated! It might take awhile for me to post, though, since I still need to order a SIO2PC cable (which will be the topic of my next post) to get the files onto the internet. Hopefully, I'll have the files for you by next week!

 

Thanks again!! I'll post the files as soon as I can!

[Paul Westphal]

if it is socketed, re seat all the chips.

[mattlacey]

I had an 800XL that couldn't run:

 

10 PRINT "HELLO"

20 GOTO 10

Without crapping out after a few seconds. I assumed it was BASIC and/or bad ram, but most games seemed pretty solid. Turned out to be the CPU!

[thorfdbg]

 

That certainly would make sense. I doubt many games would have used the built-in FP functions which would spare them from accessing the error. I

Actually, I doubt that this will help much to identify the problem. It sounds like a rather intermittend fault that could be caused from anything like a bad power supply, a bad ROM or a MMU that went back. My 800XL was failing probably a decade ago and it turned out - after swapping chips with a known-good model - that the MMU was damaged and did not re-route accesses to the right components, so the CPU occasionally read trash.

 

Thus, if you have a second model, you could try that: Swapping chips, or swapping the PSU.

[lord_mike]

Ok, everyone thank you for your patience... I got Sloopy's SIO2PC working, and here is the ROM dumps Joey Z requested from C000 to CFFF and D800 to FFFF in an ATR disk file. 800XLRomDump.atr

 

Let me know if you find anything! Thanks for all your help!!

[russg]

Nobody responded for a couple days.

Chip swapping might help finding the problem. I suspect the CPU.

I can't find where you are. You could be next door, or in Europe someplace.

The reason I ask, is if near me, I have a socketed test board to swap chips with.

You can see I'm in Cleveland, Ohio in my message ID.

A good test set of chips would be something that might be useful.

[russg]

Also. My check of your OS ROM. There are a lot of differences with my stock 600xl and 800xl ROM. I suspect your ROM

is either custom or corrupt. about 1000 differences C000CFFF and 9 differences D800FFFF.

Edited August 16, 2015 by russg

[Joey Z]

Also. My check of your OS ROM. There are a lot of differences with my stock 600xl and 800xl ROM. I suspect your ROM

is either custom or corrupt. about 1000 differences C000CFFF and 9 differences D800FFFF.

keep in mind there are different OS revisions though.

[1050]

This is REV02.ROM with Hias's v1.30 hispeed patch applied just for one source of different bytes from 'normal'.

 

Two BLOCKS for rom test are only comparing two checksums of OS rom data with the stored number for same within the rom, it's not a test for BASIC rom in any event anyway. You assume that the self test is useful and it isn't - it's a toy that just entertains and all too often misleads people into drawing the wrong conclusion. However, if it never glitches during self test, that does indicate the problem might be with BASIC rom enabling system... So it is useful, but not in the manner commonly assumed to be intended and that would be to find and indicate an issue with a component.

 

MMU, CPU and BASIC rom chip are the ones I would be swapping out in that order, but it really could be anything. Spare working machine is needed for parts donation until the problem goes away.

 

 

[lord_mike]

Also. My check of your OS ROM. There are a lot of differences with my stock 600xl and 800xl ROM. I suspect your ROM

is either custom or corrupt. about 1000 differences C000CFFF and 9 differences D800FFFF.

 

Russ, thank you for responding! Check your private messages! I sent you a PM with some more detailed information. I doubt this unit had any customization. It was a donation to a rummage sale, and looks like it was nicely put away in the closet 30 years ago only to be discovered by the estate or something similar. It's possible that it was modded, but I don't think anyone messed with it. The phillips screw heads still look pristine as if no one had ever touched it.

 

How can I find out which OS revision this unit has?

[russg]

1050 says it is REV 2 with Hias's custom parts to it.

There were about five factory OS for the 800xl.

And lots of custom OSes, such as Omnimon.

Your problem could be the custom OS.

I've responded to you PM.

[1050]

Comparing your dumped code to what is out there is how I did it.

 

 

This is your C000CFFFF.bin file as seen with a hex editor, notice the last line clearly says Hias 1.30. This is the hi speed patch from here:

 

http://www.horus.com/~hias/atari/#hipatch

 

 

Here is your D800FFFF.bin file as seen with a hex editor, notice at 27EE we start with the date of code assembly 10th day of 5th month of 1983.

 

 

http://www.ataripreservation.org/websites/freddy.offenga/atari_dev.htm

 

Here is Freddy Offenga's REV02.ROM file with a matching assembly date, I assume then this is REV02 code with the hi-speed patch applied. IIRC, there is a thread that offers this patched ROM, I would guess then someone has burned it into the OS eprom on your machine. I haven't dug any deeper than this far, as I have no need to go further.

[Sanyi]

Hello Mike,

What was the conclusion with your machine?

I have bought recently a 600XL with the same symptoms: machine seems working, tests passes, but the two-liner basic program crashes after a few seconds of running. 

All chips are socketed inside, and it has a 2764 chip on the top right corner. I know PAL machines are different compared to NTSC but not that much, right?

 

[+Larry]

11 hours ago, Sanyi said:

Hello Mike,

What was the conclusion with your machine?

I have bought recently a 600XL with the same symptoms: machine seems working, tests passes, but the two-liner basic program crashes after a few seconds of running. 

All chips are socketed inside, and it has a 2764 chip on the top right corner. I know PAL machines are different compared to NTSC but not that much, right?

 

Yes, it is always nice to have some conclusion to these problems, isn't it.  "Closure."  BTW -- what is your BASIC program that crashes?

-Larry

[Sanyi]

1 hour ago, Larry said:

Yes, it is always nice to have some conclusion to these problems, isn't it.  "Closure."  BTW -- what is your BASIC program that crashes?

-Larry

Almost the same as above:

10 PRINT "SANYI RULEZ"

20 GOTO 10

[tjlazer]

So do you just join the two dumps to make it into a rom to test on emulator or burn to chips?

[Mq.]

I had the same issue. In my case it was bad contact in socket of basic or osrom chip. Remove chips from sockets and put them again.