REV 3 - REV 5 - The beginning (ST536)

[terriblefire]

Been busy rerouting the buffer isolator chips... It went from two chips to one chip, the fastest one I can really find is a ABT version. About 7ns isolation time, the old ones were about 20ns.


Capture.PNG

20ns is 1 50mhz clock so it should be fine!!

You're breaking the golden rule... if it works don't f*ck with it.

[exxos]

20ns is 1 50mhz clock so it should be fine!!

You're breaking the golden rule... if it works don't f*ck with it.

It doesn't work faster when it should, that's the point, I want to know why

55ns ROM access time, + 20ns buffers to catch up... 50MHz CPU access is a lot slower than the STE booster running at 8/32Mhz.

Plus 20+ns for the ROM to disable.. that's a lot of time... Faster buffers I can turn the ROM off faster. As LTT Say, it is leaving performance on the table

[terriblefire]

20ns is 1 50mhz clock so it should be fine!!

You're breaking the golden rule... if it works don't f*ck with it.

It doesn't work faster when it should, that's the point, I want to know why

55ns ROM access time, + 20ns buffers to catch up... 50MHz CPU access is a lot slower than the STE booster running at 8/32Mhz.

Plus 20+ns for the ROM to disable.. that's a lot of time... Faster buffers I can turn the ROM off faster. As LTT Say, it is leaving performance on the table

The 030s dont work any faster than that... they cant latch before S4.. some wont latch reliably until S5/S6. Seems to be mask dependant.

[exxos]

The 030s dont work any faster than that... they cant latch before S4.. some wont latch reliably until S5/S6. Seems to be mask dependant.

Maybe so, but I am doing it anyway

[terriblefire]

The 030s dont work any faster than that... they cant latch before S4.. some wont latch reliably until S5/S6. Seems to be mask dependant.

Maybe so, but I am doing it anyway

Ok but be warned some 030s wont work at all if you do. :/

[exxos]

Just tried the latest EMUTOS and it finds 68MB TTRam ?! I need to check my code but I'm sure I had a limited to 16MB RAM. in any case, it seems to run fine other than the FASTROM.PRG seems to be messing up, presumably because the RAM has already been declared by EMUTOS In any case it does not seem to load EMUTOS into fastram, it is put a lot of corruption on the screen though But is pretty bonkers as I am booting EMUTOS from ROM, and when it re-reboots it still seems to have TOS206 in TTRAM..

In any case will revisit all this again when I have the new boards eventually done. Will probably make a useful feature in EMUTOS actually.. Like when it boots if a key is held down it will automatically load itself into fast ram and reboot ..

[PhilC]

@exxos have a word with @agranlund about setting maximum ram, he had it worked out pretty well

[exxos]

@exxos have a word with @agranlund about setting maximum ram, he had it worked out pretty well

I had to set mine to 16MB as there are faults somewhere.

[Badwolf]

@exxos have a word with @agranlund about setting maximum ram, he had it worked out pretty well

I had to set mine to 16MB as there are faults somewhere.

+16MB should mean bus error at 0x02000000. Easy to test with YAARTTT.

I believe EmuTOS does bus error check first, then tries a few writes and read backs to sanity check. The latter is a veto on insanity rather than a reliable detection method.

..and yes, don't double declare the memory!

BW

Something like:-

Code: Select all

wire altramberr = AS30 | ( A[25:24] != 2'b10 ); // 16MB; low is asserted; OR me with the BERR pin

[exxos]

@Badwolf yeah YAARTTT will error at 0x02000000. The fastram installer correctly finds the amount of ram and YAARTTT also reports correct amount. But EMUTOS reports 68MB which is odd anyway as there is only 64MB on board. It finds 4MB STram which is correct. So no idea where EMUTOS gets 68MB from when it will bus error after 16MB anyway..

Saying that.. It might not bus error on TTram.. So if EMUTOS is checking for bus errors then it will fail... I think fastram.prg checks chunks of ram every 16MB with data to see if its there. Can't remember offhand exactly.