REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

Come on!

:ball:

Hopefully the only-a-quarter-of-your-memory-being-detected was a bit of a one off, else the obvious place to inspect would be the BA lines.

BW

[exxos]

Hopefully the only-a-quarter-of-your-memory-being-detected was a bit of a one off, else the obvious place to inspect would be the BA lines.

I think @PhilC said there was 64MB on it, so "lost" half ... Might be a iffy PLD solder... but if this current RAM passes, then at least I can carry on with other stuff...

[PhilC]

I've only ever made two 128mb boards, one I've got and another was for a forum member. The ram price is nearly 10 times as much for 128mb.

[Badwolf]

I've only ever made two 128mb boards, one I've got and another was for a forum member. The ram price is nearly 10 times as much for 128mb.

My first board was 128... second one is 32. :lol:

BW

[exxos]

My first board was 128... second one is 32. :lol:

:lol: Mine is zero currently :roll:

[exxos]

The original TF536 actually comes out the same amount of TTRAM... Odd the start address is "out"... It seems to be passing memory test just fine..

IMG_6349.JPG

I tried porting my firmware over to the original board, but I just get a row of bombs as soon as FASTRAM.PRG is run :roll: So there must be some problem with my changes somewhere even though I have not touched the TTRAM code :roll:

[Badwolf]

The original TF536 actually comes out the same amount of TTRAM... Odd the start address is "out"... It seems to be passing memory test just fine..

That just means some of the AltRAM has been used already and isn't available for testing. Probably YAARTTT itself is loaded into it!

0x1000000 to 0x5000000 is expected each block of 1000000 is 16 meg, so four blocks = 64.

I tried porting my firmware over to the original board, but I just get a row of bombs as soon as FASTRAM.PRG is run :roll: So there must be some problem with my changes somewhere even though I have not touched the TTRAM code :roll:

You can choose not to run FASTRAM.PRG and instead, when running YAARTTT choose the (hidden) "M" option from the menu and type in your own address range.

So, for example, run YAARTTT.TOS, press "M", put in a start address of 1000000 and an end address of 2000000 and you'll test the first 16Meg. You can selectively chose the blocks to test to verify certain lines are behaving.

Of course pointless in this case as that particular board passes with the original firmware.

SDRAM timing is much more likely. What's the Integer Division figure at 50MHz on the original board with your firmware and *without* FASTRAM.PRG? Basically, if it's not 1.820, you're likely going to have SDRAM trouble.

BW

[exxos]

You can choose not to run FASTRAM.PRG and instead, when running YAARTTT choose the (hidden) "M" option from the menu and type in your own address range.

That is what I have been doing... RAM just fails after a few seconds... But running in STOS, assume because the loops are slower, the RAM tests just fine...

I have avoided every type of bus access imaginable to hold off DTACK on TTRAM access.. it just does not seem to matter at all what the delay is there... In theory if the RAM is 70ns, then 100ns should be just fine.. but nope...

I would have thought there would have been some sort of "hold off" routine in the SRAM section somewhere, to stop the CPU accessing RAM if it's doing a refresh or something... I only assume I have not found it yet and that is the reason it seems to pass for a few seconds then go nuts.

[PhilC]

I know I might be sitting the obvious but you do remember the ram runs at 100mhz?

[exxos]

I know I might be sitting the obvious but you do remember the ram runs at 100mhz?

Yep, not touched it.