XL going straight to memory test, first ROM square is red

[Shawn Jefferson]

Hi, I'm troubleshooting my 1450XL build, see thread here: 

 

And I'm having an issue where the machine goes straight to self test, and the first ROM square is red.  All other ROM and RAM tests are green.  As I'm troubleshooting and trying to track down the issue, I need some help in where to look.  Here's what I know and am assuming:

 

• Holding option will allow the self test to show 48 RAM squares, so banking out BASIC seems to work
• Star Raiders cartridge works and plays, I can fly around and press keys, etc.. No sound though, might be related or not.
• I have swapped many chips: OS, BASIC, CPU, GTIA, PIA, no change.  Continuity checks here and there, no issues that I can tell (but maybe didn't check everywhere)

 

Looking at the OS disassembly and what it's doing during the self test, it looks like it's doing a checksum over C002-D000 and also 5000-5800.  Somehow that is failing, but since self test works, that's being banked in properly anyway (maybe not banked out, as the OS tries to do before the checksum routines, but would that actually cause the OS checksum to fail?), because the OS is partially working, and Star Raiders is working, I think all the data bus lines to the OS ROM are working fine, and probably (?) all the address bus lines.

 

Any ideas where to look next?  The PAL chips that help with banking may be wrong, but it appears that everything is being banked appropriately from what I can tell. I don't have a SALT cartridge, which would probably help a little narrow things down... might be my next project to build one.  I have a logic probe on the way, but no logic analyzer, might be another purchase soon, lol.

 

 

 

 

[Sugarland]

Yes further work to narrow down the issue with more specific tools as you mention seems to be the way to proceed. No idea here.

[Shawn Jefferson]

I found today that Star Raiders II also has the diagnostic bit set, so I can run that as well.  Everything there seems to work properly as well, although I haven't played a game yet to see if it's all working.  

 

I also checked continuity between the CPU address lines and two LS244 chips (buffering the address lines?), and to the OS ROM, and all were fine.

[1050]

Did you modify the ROM code but failed to update the checksum values? It could be failing because the checksum is wrong for a reversed OPTION press mod just for one easily forgotten I did that example.

 

I know all about how humbling it is to do that too.

 

0xC002 - 0xCFFF

0x5000 - 0x57FF

 

just to be accurate.

I can quite easily check your ROM for the proper checksums if you'll post the ROM file.

[Shawn Jefferson]

The ROM is the standard XL OS production ROM chip, I haven't made any alterations to it (tried two different ROMs).

Edited May 19, 2021 by Shawn Jefferson

[+Nezgar]

16 hours ago, Shawn Jefferson said:

The ROM is the standard XL OS production ROM chip, I haven't made any alterations to it (tried two different ROMs).

There are a number standard XL OS production ROM's... which one are you using? The 1200XL had 2, the 600 and 800XL's had a rev 1 and 2, XE's used XL rev 2 and 3, XEGXS had a rev 4. The 1400's probably had their own too.

 

I was going to say I could just mail you a drop-in replacement EPROM but that's odd if you tried a 2 already. Do your ROM's work in another XL or XE?

[Rybags]

2 failed OS Rom chips with the same symptoms seems unlikely... more likely is there's some issue with the MMU or something in the memory selection circuit like 74LS chip or PIA.

[Shawn Jefferson]

4 hours ago, Nezgar said:

There are a number standard XL OS production ROM's... which one are you using? The 1200XL had 2, the 600 and 800XL's had a rev 1 and 2, XE's used XL rev 2 and 3, XEGXS had a rev 4. The 1400's probably had their own too.

 

I was going to say I could just mail you a drop-in replacement EPROM but that's odd if you tried a 2 already. Do your ROM's work in another XL or XE?

 

I'm using CO61598B, which is the single chip OSROM, and I've swapped it out, it doesn't seem to be a problem with the actual OS ROM, and to get the system to even boot into self-test and diagnostic carts it would have to be working somewhat.  I also was able to get SALT2.05 on my Atarimax flashcart and verified that C000 and C0001 have the correct checksum values.  I don't see how it could be the OSROM, or the socket, since data bus lines and address bus lines would have to be working just to get this far?

 

4 hours ago, Rybags said:

2 failed OS Rom chips with the same symptoms seems unlikely... more likely is there's some issue with the MMU or something in the memory selection circuit like 74LS chip or PIA.

 

I haven't swapped the MMU (freddie) out, since I don't have a spare, and likely any chip in my 130XE or 65XEs would be soldered in, and I'm not sure I want to try desoldering it.  I could get another one from Best maybe.  Do you think the symptoms I'm seeing here would indicate a problem with MMU?  I'm not sure what the Freddie MMU does exactly?

 

PIA I've swapped out and that appears to be working in another machine.  I can't test that much in this machine with it only going to self test though.  But it does look like portB is working, since I can enable/disable BASIC it appears (self test showing different number of RAM blocks).

 

[Mathy]

Hello Shawn

 

4 hours ago, Shawn Jefferson said:

I haven't swapped the MMU (freddie) out ....  I'm not sure what the Freddie MMU does exactly?

 

Freddie is not the MMU!  The MMU is about the size of a memory chip, Freddie is about a big as the Atari specific chips.  Freddie replaces stuff like the delay line and the LS158 chips the XL series has.

 

Sincerely

 

Mathy

 

 

 

[Shawn Jefferson]

31 minutes ago, Mathy said:

Hello Shawn

 

 

Freddie is not the MMU!  The MMU is about the size of a memory chip, Freddie is about a big as the Atari specific chips.  Freddie replaces stuff like the delay line and the LS158 chips the XL series has.

 

 

 

Thanks, I found the Atari PDF on Freddie and see it's controlling CAS/RAS generation from address lines.  I guess it may still be the issue for me, perhaps.  The MMU in the 1400XL is the 61919 (PAL A), that certainly could be the issue since I was not able to source that chip, or get a dump of the official chip, and tried to rebuild it from the original equations (see the thread below).  I'm not sure how that could be the issue with the things that are working though?

 

 

The most likely scenario is that I've screwed up the equations of that PAL A chip somehow, but very strange with the way things are working if that is the case.

Edited May 20, 2021 by Shawn Jefferson
typos

[Mathy]

Hello Shawn

 

Not sure if you know this, but there are at least three different MMU's:

 

- 1200XL/1450XL

- XL/XE

- XEGS

 

Sincerely

 

Mathy

 

[Rybags]

Roms don't use Ras/Cas.  But Freddie should make a system a bunch more reliable as the timing is precise based on 14 MHz clock increments and the delay line relies on electrical characteristics to get it's fractional values.

 

But 1450... doesn't that have the voice chip and extra Rom to drive it?  Could it be that some Rom overlay is going on which gives a different checksum?

[Shawn Jefferson]

13 minutes ago, Rybags said:

Roms don't use Ras/Cas.  But Freddie should make a system a bunch more reliable as the timing is precise based on 14 MHz clock increments and the delay line relies on electrical characteristics to get it's fractional values.

 

But 1450... doesn't that have the voice chip and extra Rom to drive it?  Could it be that some Rom overlay is going on which gives a different checksum?

 

The system seems quite stable when playing Star Raiders or Star Raiders 2, and I can let the memory test run for a long time with no change.  There is another ROM chip, but all those devices in the 1400/1450XL are all PBI devices, so I don't think this ROM comes into it (and least not yet).

 

The more I think about it, the more I am thinking its something to do with the PAL A (MMU) chip that I attempted to program from the equations.  It's similar to that in the 1200XL and the 800XL, but not exactly the same.  Although it seemed like so much of the machine is working properly, with banking ROMs in and out that it's a bit confusing.  Maybe Bob Wooley would dump the PAL A chip like he had done for the PAL C, I'll have to PM him, as he seemed like the only person with the board and the capability to dump it.

 

 

Edited May 21, 2021 by Shawn Jefferson
there, their

[Rybags]

There's some not so well documented features among the MMUs.

 

From memory, on an XEGS Basic will always override the game portion if enabled (there being 4 possibilities there)

And not totally sure if the OS has to be present for the Self Test to also appear (all machines)

[archeocomp]

I programmed and successfully tested GAL16V8 from China on TL866 programmer as replacement for MMU in a 600XL. The original MMU was very running very hot albeit working correctly. GAL in place runs much cooler. I could send you my files.

[Rybags]

I've not done such programming.  Though the logic involved in the Atari memory selection at that level is usually fairly simple.

 

But I don't know if there's specific stuff for the 1450 - entirely possible since there's sufficient differences among the likes of 800XL, 1200XL, XEGS.

[Shawn Jefferson]

10 hours ago, archeocomp said:

I programmed and successfully tested GAL16V8 from China on TL866 programmer as replacement for MMU in a 600XL. The original MMU was very running very hot albeit working correctly. GAL in place runs much cooler. I could send you my files.

 

10 hours ago, Rybags said:

I've not done such programming.  Though the logic involved in the Atari memory selection at that level is usually fairly simple.

 

But I don't know if there's specific stuff for the 1450 - entirely possible since there's sufficient differences among the likes of 800XL, 1200XL, XEGS.

 

Hi, yes, the 1400XL MMU is different from all the others.  It's close, but not quite the same.  I have looked into using a GAL, and the TL866 programmer, and that looks like a good option, but without knowing if I have an actually good set of equations (or a dump of the Atari part) I don't think it will help me much.  I had someone else program the PAL A and PAL C chips for me (actually two different people just to make sure)!