ST536 STE EDITION

[exxos]

GB6 been on a while now.. Using fast rom (physical ROM) ..

IMG_3190.JPG

Its done 2 passes of YAARTTT so far... So its not like its unstable on this "older" revision STE.

[Badwolf]

The board boots up. So it was a simple one to get up and running!

:2k2:

BW

[Badwolf]

Whilst you're fiddling with the firmware, @exxos, can I suggest you add a toggle for disabling the SDRAM buffers entirely (or something similar)?

The idea would be to cause TT-RAM detection to fail.

I've been doing a lot of testing of games recently for my videos and I was sure some games worked during early testing, but I couldn't get them to again.

I realised that previously I had tested many with plain TOS2.06 (no automatic TT-RAM detection) rather than ExxTOS or EmuTOS (which both merrily announce 64MB to the world).

Sure enough, popping out the ROM and putting in vanilla 2.06 (only possible because of the 'slow ROM' firmware I'm still running) caused these games to boot up and play again. A bit of screen corruption was the clue in the end.

So I think a method to cause TT-RAM detection to fail might be warranted. Either via a software toggle or perhaps doing the old hold-reset-for-three-seconds trick or something.

Or don't auto-declare TT-RAM in ExxTOS so the user can run a driver if he wants it?

BW

[exxos]

@Badwolf currently you would have to use the noTTram firmware. I have put a proper switch in the later code. Idea was to have a jumper to disable ram , but was more intended for debugging. It's the only way really to stop TOS & EMUTOS detecting the RAM.

A software switch could be added to my build of TOS at some point. Maybe holding down a key on powerup or something... Not thought about it much yet.

Odd that games are fussy about TTram in the first place ? It's still.possible the booster is malfunctioning with the 144 chip. It was totally unstable on my machine. It's why I totally abandoned the 144 branch.

A switch could be added to disable the buffers as there's a OE line from the PLD to the buffers..but not sure if TOS will still declare the TTram even though its technically faulty.... It might declare a lot.of faulty ram.. TOS keeps going until it sees a bus error.. I don't know how TOS handles bad ram... I mean it shouldn't allocate faulty ram... But if games simply don't like TTram, then they still may not like faulty TTram..

I guess you would simply have to try hacking the buffer OE and see what happens...

EDIT
Wherever TOS stores the amount of TTram found could be cleared so it doesn't know about TTram.. But that might not be enough...

[stephen_usher]

Have the games accidentally got their PRGFLAGS set to use TT RAM? If they don't then they'd have to explicitly allocate TT RAM with xalloc... Unless they're doing something stupid such as reading how much free memory and then using that as a offset to put their display buffer... Which wouldn't surprise me when it comes to games developers.

[Steve]

@Badwolf could this be a bit of a moot / redundant thing though? ie; when you're running an 030 booster, you're gonna be running 030 patched games anyway (which should inevitably support a system with fast RAM) Running unpatched games would be a minefield overall whether you have TT RAM or not.

[PhilC]

A quick update from me.

I've fitted the 33pf cap to the clock as suggested and tried to boot with current5 firmware.

Tos gets as far as about to test the TT ram but stalls, ET won't load at all, no splash screen or anything.

Loaded up current3 firmware again with the ca still in place and it boots tot TOS using the BBAN HDD and I can run GB. ET loads and I can run GB with TT ram enabled.

I'll leave it on ET for a bit doing some loops on GB.

[exxos]

Loaded up current3 firmware again with the ca still in place and it boots

So current3 works but not current5?

Coincidentally, I was talking to @ijor about some stuff... All the later version does is enable the buffers quicker. Last night I was testing with buffers enabled all the time, current3 only enables buffers on TTram access... But it ran fine... The whole thing makes no sense.

I'll build a test firmware when I get home without IDE auto boot to see if that's a factor. But it's like the goalposts keep moving making it impossible to figure out what the problems actually are.

Maybe ship me your board so I can test in my STE...

At this point I'm starting to wonder if the PLDs are faulty or something.. but I'd assume verify would fail if that was the case.

[PhilC]

@exxos yes Current3 is fine and was before adding the cap I think. Remember the only difference on mine is the ram, its Micron Technologies ram on it.

[Badwolf]

@Badwolf could this be a bit of a moot / redundant thing though? ie; when you're running an 030 booster, you're gonna be running 030 patched games anyway (which should inevitably support a system with fast RAM) Running unpatched games would be a minefield overall whether you have TT RAM or not.

There simply aren't many patched 030 games. There are loads of PP's game, but they're not patched for accelerators but for stock machines (and sometimes they've been intentionally patched in such a way that frequent accelerator OS combinations will actively fail). Klaz has some genuinely thoroughly patched games, but only about 80 of those.

So I'm mostly booting floppies.

Have the games accidentally got their PRGFLAGS set to use TT RAM?

Which rules out that too.

Odd that games are fussy about TTram in the first place ? It's still.possible the booster is malfunctioning with the 144 chip.

Well, that's true. I can't rule that out.

But with the increased overhead a 288 gives you, it would be really easy to disable TT-RAM on the board & also safer than doing it in the OS, I'd have thought.

If the TT-RAM detection works like the ST-RAM detection then the RAM does need to pass some basic checks. There's no bus error below 4MB on a 512k machine, for example. Simply isolating the SDRAM chips with the buffer OE line would seem an easy win to me.

This is only an issue because both banks in the shipped ROM autodetect TT-RAM. You could provide ExxTOS and normal TOS2.06 for example but it's a pity to lose EmuTOS there.

Something like

Code: Select all

reg allow_sdram = 1'b0;
reg [24:0] reset_counter = 'd0;
always @(posedge CLK8 ) begin // assume the 8MHZ clock is your slowest available
	if( !RESET )	
		reset_counter <= reset_counter + 'd1;
	else
		reset_counter <= 'd0;
end		

always @( posedge reset_counter[24] ) begin
	allow_sdram <= ~allow_sdram;
end

assign SDRAM_BUFFER_OE = allow_sdram;

That's a nasty 25 bit counter, but I don't know if you've a slower clock you could use (E, perhaps?)

Idea would be the board would always power up with SDRAM enabled, but you can toggle the buffers off (nixing TT-RAM) if you hold reset for more than 2.1 seconds (ok, pedants: and less than 6.3 seconds ;) ).


BW