exxos's Atari, Amiga & retro forum

Yes.

I've now reverted the machine as close to stock as I can, fitted sockets in the lower bank and lifted the three 68R resistors and then reinstalled the original RAM.

No change, but at least it's a start.

I think the most important thing is to understand what triggers the MMU to start the /CAS lines in the first place.

I can see that there are at least a couple of memory reads and then some writes.

I'm wondering if I should look across the board and start 'scoping out the GLUE. If that's not putting the correct addresses on the bus then the CPU will be reading junk rather than the ROM. Having said that things change when I swap to TOS 2.06 on the dualtos board which suggests that the CPU is at least reading the first few bytes and then trying to jump into the ROM.

P.S. The only other thing I've not removed is the wire from the underneath of the MMU which is supposed to add the extra address line for the Exxos memory board. I wonder if that's causing interference.

Do you have a logic analyzer? Have you checked if any address/data line is not stuck low or high?

Is the /reset line staying high or is it cycling high and low? You mentioned fitting a reset switch IIRC. Reset behaviour should be press switch /reset goes low, then a second later goes high and stays there, the same for /halt unless something is halting the system.

RAS and CAS lines are controlled by MMU itself. Even if it is not selected, it should issue a DRAM refresh cycles.

Well, that was stupid of me. I was counting the 68000 pins the wrong way! I was counting as if the chip was orientated the other way around. Doh!

This makes more sense... /RESET is never low and /BERR goes low once, briefly.

Anyway, other than the Blitter socket the machine is as close to stock as I can get it now.

tzok wrote: 26 Sep 2020 13:49 RAS and CAS lines are controlled by MMU itself. Even if it is not selected, it should issue a DRAM refresh cycles.

That's the puzzling thing. It's generating /RAS but none of the /CAS signals, but it does in another machine.

On the other machine, which only has 512K of memory, it doesn't generate /CASH1 or /CASL1, which means these at least have to be turned on by something. I'm guessing that there's a similar mechanism for bank 0.

I've now checked every address, data and control line on every RAM location, traced them down past the 74LSxxx chips to the CPU and the memory address lines down to the MMU and they all check out, so it can't be the RAM side.

stephen_usher wrote: 26 Sep 2020 14:31On the other machine, which only has 512K of memory, it doesn't generate /CASH1 or /CASL1, which means these at least have to be turned on by something. I'm guessing that there's a similar mechanism for bank 0.

One of the first things ST does after powering up is determining the memory configuration, and setting the MMU configuration register located at $FFFF8001. First two bits (counting from LSB) are Bank 0 configuration, and the next two are Bank 1 configuration: 00 = empty bank, 01 = 512kB, 10 = 2048kB.

tzok wrote: 26 Sep 2020 17:47

stephen_usher wrote: 26 Sep 2020 14:31On the other machine, which only has 512K of memory, it doesn't generate /CASH1 or /CASL1, which means these at least have to be turned on by something. I'm guessing that there's a similar mechanism for bank 0.

One of the first things ST does after powering up is determining the memory configuration, and setting the MMU configuration register located at $FFFF8001. First two bits (counting from LSB) are Bank 0 configuration, and the next two are Bank 1 configuration: 00 = empty bank, 01 = 512kB, 10 = 2048kB.

Thanks, so it's obviously not getting that far.

The data bus on the CPU side of the 74LS244's is VERY noisy.
e.g. If you notice some of that noise actually goes above the TTL 0/1 transition voltage.