It's 600XL time!

[BennehBoy]

And is the ROM the original one/a mask rom etc? Ie. it's not been replaced with a prom/eprom that is the wrong speed rating etc for the 600?

[rubber_jonnie]

And is the ROM the original one/a mask rom etc? Ie. it's not been replaced with a prom/eprom that is the wrong speed rating etc for the 600?

Original mask ROM. Works just fine in my 800XL. I have 2 original mask ROMs, both of which work just fine in the 800XL, so it's not the ROM.

Since the CPU seems to be running, it could just as easily be data lines, and it's getting garbage data and falling into a loop.

[ijor]

I have read that Star Raiders is sometimes referred to as a diagnostic cart, and it seems it jumps into that much earlier than most other cartridges, a bit like the early detect for a cartridge in the ST.
...
I have a Super Salt diagnostic cartridge, however that doesn't start unlike Star Raiders.

Oddly enough, the SALT cartridge doesn't identify itself as a diagnostic cartridge.

I'm not sure, the service manual isn't great, I don't think there is any sort of reset circuit at least not an obvious one, but I'll revisit the schematic see what I can see.

Of course there is a reset circuit. How would you expect it to work without one? Which schematics are you using? If it doesn't include the reset circuit then they are wrong or incomplete.

Hmm, interesting, I just discovered in the small print on the back of the Bounty Bob cartridge that it requires 16KB to run.

This doesn't mean too much. The BBSB cartridge surely doesn't use every single bit of that RAM. You could still have bad RAM in the lower 16K. It could also be a ram refresh issue. Did you replace all the RAM? Speaking about RAM refresh, there is an older version of ANTIC that is not compatible with some RAM chips.

but I found time to take an LA dump of the 600XL and 800XL at boot with just the OS installed,

It is difficult to analyze the traces like that. I think it would be more useful if you could add the main clock and the HALT signal (to distinguish DMA and ram refresh cycles). It might also help if you could consolidate the address signals into a single bus. If you are using Saleae software, at it seems, I think they support a parallel bus analyzer that can do that. Another trace or scope dump capturing the ram control signals might be useful as well.

[rubber_jonnie]

Oddly enough, the SALT cartridge doesn't identify itself as a diagnostic cartridge.

I thought that odd TBH.

Of course there is a reset circuit. How would you expect it to work without one? Which schematics are you using? If it doesn't include the reset circuit then they are wrong or incomplete.

Agreed, it didn't make much sense. The original 2 part schematic I printed was not great, very fuzzy, so I have just printed out the 4 parts from the service manual and I am going to look at it more closely as it is a lot clearer, I can then figure out where the reset circuit is.

This doesn't mean too much. The BBSB cartridge surely doesn't use every single bit of that RAM. You could still have bad RAM in the lower 16K. It could also be a ram refresh issue. Did you replace all the RAM? Speaking about RAM refresh, there is an older version of ANTIC that is not compatible with some RAM chips.

It's upgraded to 64K with new RAM. It won't even boot to Star Raiders with the old RAM installed. The MMU is known good from my 800XL, and the 600XL MMU works just fine in my 800XL. All the main ICs, so GTIA, ANTIC, SALLY and POKEY all test fine in the 800XL and I have a new genuine Atari 6520 PIA, also tested in the 800XL. Trying the main ICs from the 800XL in the 600XL makes no difference and vice versa. All other ICs have been replaced with new and the problem persists.

It is difficult to analyze the traces like that. I think it would be more useful if you could add the main clock and the HALT signal (to distinguish DMA and ram refresh cycles). It might also help if you could consolidate the address signals into a single bus. If you are using Saleae software, at it seems, I think they support a parallel bus analyzer that can do that. Another trace or scope dump capturing the ram control signals might be useful as well.

Main clock has been scoped and is fine, and the HALT appears to behave identically to the 800XL on the scope. I have another 8ch analyser I could potentially add.

Would be nice if I had another 600XL that worked to compare against, though I can't help but think that during boot they should behave the same, at least as far as the OS goes.

BTW, if I hook up the keyboard, and press reset on boot, it takes me to the memory test, but not the self test menu like the 800XL does. The test runs, but then crashes after the first 16 blocks of RAM test completes.

It's pretty clear that the OS isn't loading as even with the BASIC ROM removed, it never shows the Blue screen with the cursor. The 800XL does and then drops into self test.

[ijor]

Main clock has been scoped and is fine, and the HALT appears to behave identically to the 800XL on the scope.

I didn't mean that the clock or HALT are necessarily bad. I meant that including those signals in the same trace with the address bus is very helpful to decode the bus activity.

BTW, if I hook up the keyboard, and press reset on boot, it takes me to the memory test, but not the self test menu like the 800XL does. The test runs, but then crashes after the first 16 blocks of RAM test completes.

It's pretty clear that the OS isn't loading as even with the BASIC ROM removed, it never shows the Blue screen with the cursor. The 800XL does and then drops into self test.

The OS performs a quick RAM test at boot time. If it detects a ram problem or a (ROM checksum error) it goes directly to the RAM selftest. This is what you are seeing in the 600XL on reset. If you boot without any cartridge or basic, and there is no boot disk drive either, then the OS jumps to the main selftest menu (because it has nothing better to do).

It is a bit strange that the reset behavior is different than when you power up. You don't get a jump to the RAM test at power up, do you? This might suggest a reset issue or a heating problem. But difficult to be sure. Again, might be a ram refresh issue.

So far the evidence points to a RAM issue. It doesn't necessarily have to be a RAM chip. It could be a socket, a trace or even a minor component. In theory you can trace the OS activity and detect exactly why it jumps to the RAM selftest at reset time. But this is a bit cumbersome if you are not familiar with the OS internals. Might be better to wait for Sys-Check and see what it shows.

[rubber_jonnie]

I didn't mean that the clock or HALT are necessarily bad. I meant that including those signals in the same trace with the address bus is very helpful to decode the bus activity.

Ok, see what you mean.

It is a bit strange that the reset behavior is different than when you power up. You don't get a jump to the RAM test at power up, do you? This might suggest a reset issue or a heating problem. But difficult to be sure. Again, might be a ram refresh issue.

So far the evidence points to a RAM issue. It doesn't necessarily have to be a RAM chip. It could be a socket, a trace or even a minor component. In theory you can trace the OS activity and detect exactly why it jumps to the RAM selftest at reset time. But this is a bit cumbersome if you are not familiar with the OS internals. Might be better to wait for Sys-Check and see what it shows.

Apologies, I didn't mean to write reset, I meant to write OPTION.

On boot I get a black screen. On boot without the BASIC ROM I get a black screen. I only get a RAM test if I boot with OPTION held down, that is with either the BASIC ROM fitted or not. The system freezes on a blank green screen when it gets to 16KB tested.

The sockets are all new as the originals were single wipe, now double wipe. CAS and RAS look as they do on the 800XL. RAM chips are new.

I'm not familiar with the OS internals, but I do have a copy of Mapping the Atari and I'm wondering if it can give me some clues as to the boot process.

I honestly think it may be a trace problem as there is already some evidence of trace repairs on the board.

You may be right in that Sys-Check is my main hope.

I have identified the reset circuit, it is quite rudimentary.

[BennehBoy]

BTW, you're famous Jonnie ->

Skip to7:07 :D

[olivier.jan]

Ijor has a point, these machines are known for their crappy sockets, did you try booting while firmly pushing down the RAM chips or other surrounding chips ?

[rubber_jonnie]

Ijor has a point, these machines are known for their crappy sockets, did you try booting while firmly pushing down the RAM chips or other surrounding chips ?

All of the sockets have been replaced with new.

[rubber_jonnie]

BTW, you're famous Jonnie ->

Skip to7:07 :D

:girldance: :girldance: :girldance:

Well I never, I had no idea, first time I've seen this!!

My 65XE subsequently got an upgrade to an Ultimate 1MB, but it was a fun upgrade to do, though I would say it was harder to get the RAM chips than the memory controller at the time.

Still got it too and have owned it from new :)