Re: REV 3 - The beginning
Posted: 29 Mar 2021 21:16
Yep... keep having problems with it resetting at 50mhz... But I dont think CPU speed makes any odds anyway.
We welcome retro users & hardware gurus alike! Come and join the party :)
https://www.exxosforum.co.uk/forum/
Yep... keep having problems with it resetting at 50mhz... But I dont think CPU speed makes any odds anyway.
Will the CPU be ready to read the data in time?
Have no idea, it only works at all with 350ns delay on it.. I seem to have broken it even more, so falling back to yesterday's code (when I got ROM working) to try again.. Though I think I need a more friendly SDRAM controller.. but I don't have endless time to throw at this anyway :(Badwolf wrote: 29 Mar 2021 22:07 Will the CPU be ready to read the data in time?
For argument's sake, say the DATA is presented at cycle 4. That will only be cycle 2 if it's running at half speed.
Code: Select all
//12 bus error - address error
//11
//10 bus error - random errors
//9 random errors
//8 random errors
//7 random errors
//6 bus error
//5 massive errors
//4
//3 massive errorsOn the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.Badwolf wrote: 30 Mar 2021 10:26 Is your DTACK delay logic *only* applying for ST-RAM and ROM? It's imperative it doesn't interfere with AltRAM timings.
SDRAM is *not* like DRAM. It doesn't hold the data until you stop asserting CAS. The data appears two (or three, it's configurable, but at this speed it's likely two) clock cycles after CAS is asserted and then it's gone again.
The TF330 requests the same address on two concurrent clock cycles (CAS stays low for two cycles) to give you some leeway in latching the address *two clock cycles later*.
If you delay that latching, you will get gibberish. The lines will be undriven and you might get away with it some of the time, if they're slow to recover high, but fundamentally you *cannot* slow down the cycles by inserting wait states in the 030 during an SDRAM access. It's synchronous so you *have* to hit the timings.
The problems I had a lot of early on was that I'd modify the code, it'd hit the timings on some lines, but not others (I don't know, perhaps the memory address 8 line was 12ns slow, for example). It's possible something like that is happening, but if you're adding delay between when CAS gets asserted and when the CPU latches the data, it *will* fail.
Scope on CAS and STERM?
BW
Isn't that for 32bit only ? I have been trying 16bit reads and without DTACK the program just hangs.terriblefire wrote: 30 Mar 2021 10:47 On the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.
It always reads 32bits from sdram. even when you ask for 16bits. SDRAM needs to be sync with the CPU so it uses STERM. The 030 does the byte lane sorting.exxos wrote: 30 Mar 2021 11:14Isn't that for 32bit only ? I have been trying 16bit reads and without DTACK the program just hangs.terriblefire wrote: 30 Mar 2021 10:47 On the TF536 DTACK/DSACK is not used for SDRAM. We use STERM and you have to use that.