exxos's Atari, Amiga & retro forum

Well, I've got the SRAM on the board. I think it's OK. There are definitely no shorts!


Unfortunately it doesn't work. The machine still reports 256K of RAM. From the look of things from the oscilloscope the right sort of things are happening, though some of the data pulses look a bit on the short side.

The next phase will be soldering on some headers onto the board so that I can connect the logic analyser. It's not OK if it's playing all the right note, just not necessarily in the right order, so paraphrase Eric Morecambe.

It looks like I have a few bits missing! Still, it does show that it is writing to some bits.


I'm not sure about the spiky output on D1, D7 and D8 though.

I reflowed the solder using hot air and then tested...

It saw the RAM!


Once.... It's now reporting 256K again. *sigh*

OK, I can see the system doing the initial memory test but there are spurious 'bits' on some of the data lines.


D6 and D14 seem especially prone to these.

I've also seen both /BHE (Byte High Enable) and /BLE (Byte Low Enable) go high at the same time which, according to the documentation and truth table, shouldn't be able to happen. These are generated directly from signals being sent by the system.

I'm guessing though that the reason for the failure are these spikes. However, this could be an addressing problem or noise but there's no way I can tell. the pin pitch on the SRAM is too small for any of my probes.

I could potentially test this with a RAM test program which wrote the address into memory from the bottom to the top and then re-read it to see if anything had been overwritten. I could write this IF I had either the complete knowledge of x86 real mode assembler and how to send characters to the screen or a compiler which could handle far pointers, neither of which I have access to.

Hmm. I may need stronger pull-ups on the data lines. There are a lot of very short spikes to 0V on the main system data bus which the 74LS245s are passing through but the data lines are taking too long to get back to 5V, so it may be writing spurious bits to memory. The memory could be reacting too fast!

Looking awesome sir, though I did spot the blue bodge wire :)

Yeah. You can blame Atmel for that one. Their GAL programmer doesn't allow pin 19 to be active high, so I had to switch to pin 15.

Looking like some good progress to me @stephen_usher

Can you bodge in one of the delay ic parts give your self a 40ns delay

Tom

Hmm.. Changed the pull-ups and no difference.

I've managed to write a program which writes and then reads from memory and that seems to work. Of course this is reading and writing whole words.

I can see on the oscilloscope data being written and read. I don't know what may be causing the glitches when it's doing the memory test.

The address line output looks crisp so I doubt that it's a delay there.