exxos's Atari, Amiga & retro forum

Badwolf wrote: 29 Mar 2021 11:58 You had 1.820 in this post with AltRAM, and here's my 50MHz 030 with ST-RAM only:

Bang on.

Thanks for the clarification!

exxos wrote: 29 Mar 2021 12:08

Badwolf wrote: 29 Mar 2021 11:58 You had 1.820 in this post with AltRAM, and here's my 50MHz 030 with ST-RAM only:

Bang on.

Thanks for the clarification!

Which, BTW, might explain your AltRAM issues -- SDRAM is bloody voodoo at the best of times in terms of timing, but if there's an extra delay in asserting STERM, you'll miss the data.

BW.

Badwolf wrote: 29 Mar 2021 12:34 Which, BTW, might explain your AltRAM issues -- SDRAM is bloody voodoo at the best of times in terms of timing, but if there's an extra delay in asserting STERM, you'll miss the data.

It seems so!

I wrote a quick test routine in STOS.. pokes 0-255 into TTRAM and outputs on errors.. seems random..

TTRAM Is now passing tests, but I actually have a 350ns delay on DTACK for it now :shrug: So no idea what is going on there :shrug:

exxos wrote: 29 Mar 2021 15:18 TTRAM Is now passing tests, but I actually have a 350ns delay on DTACK for it now :shrug: So no idea what is going on there :shrug:

That sounds very suspect. Does AltRAM even use DTACK? It's 32 bit and probably supports bursting. It ought to be using STERM.

BW

Badwolf wrote: 29 Mar 2021 15:59 That sounds very suspect. Does AltRAM even use DTACK? It's 32 bit and probably supports bursting. It ought to be using STERM.

I tried taking out DTACK but then in STOS poking a address is just locked up... I don't know is programs need 8bit or 16 bit access to alt-ram... STERM apparently is for 32bit only.

I also think the CPU can't run for long at 50Mhz, so ive dropped to 25MHz now as well.

exxos wrote: 29 Mar 2021 16:05 I tried taking out DTACK but then in STOS poking a address is just locked up... I don't know is programs need 8bit or 16 bit access to alt-ram... STERM apparently is for 32bit only.

I also think the CPU can't run for long at 50Mhz, so ive dropped to 25MHz now as well.

Yeah, sorry. I'm spitballing from own experience rather than knowing the code.

With a 32 bit data bus you can use either DSACK or STERM. STERM is one cycle faster (although I don't think that matters in this case as the RAM's the limiting factor) but the big pluses for STERM are it's synchronous (handy when using synchronous RAM where the bloody data buggers off after the read) and that you can do 'burst' mode (filling multiple lines of cache on one (elongated) read cycle.

Either way, the bus size is always 32 (DSACK0 and DSACK1 will both go low), even if you're reading or writing a byte. The CPU will always read all four bytes (how it fills its cache) and when writing the DQM lines will mask off what doesn't get written (like UDS/LDS, but four-way).

Anyway back to the original point, if you're delaying STERM or DSACK[1:0] in an alt-ram cycle, you'll possibly be missing the data on reads. The first negative edge during STERM (or the second negative edge during DSACK[1:0]) needs to occur on the second *rising* edge after CAS goes low.

The way the TF330 does it (so 536 may be the same) is to perform two reads from the same address back to back to give you a single cycle of leeway. Any more than that and you risk the data lines having gone high-Z by the time you try to latch.

BW

Badwolf wrote: 29 Mar 2021 16:31 The way the TF330 does it (so 536 may be the same) is to perform two reads from the same address back to back to give you a single cycle of leeway. Any more than that and you risk the data lines having gone high-Z by the time you try to latch.

It could literally be anything, I don't really have any idea how SDRAM works as never used it...


It is odd because it seems to test okay for several seconds then goes nuts for several seconds rinse and repeat...


I'm going to put back the original code and test the RAM out more thoroughly...

EDIT:

Not working either, so either the SDRAM code is wonky or the IC's are iffy... I guess I will resolder them first...

Interesting that's it's the f0xxxx range in both those screens, but 16 megabytes apart.

BW

EDIT: just seen your edit. Check the higher lines on the low-word chip.

Badwolf wrote: 29 Mar 2021 16:46 Interesting that's it's the f0xxxx range in both those screens, but 16 megabytes apart.
EDIT: just seen your edit. Check the higher lines on the low-word chip.

I just resoldred both RAM chips and the buffers... Was odd because before the top brand now is 1F00000 and it was 5000000 before, so 32MB to 64MB... so far its passing TTRAM....


EDIT:

Put my code back in and its saying 5000000 again.. will leave it running see if it passes the tests...