Page 6 of 9
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 14:26
by Badwolf
exxos wrote: 05 May 2022 14:07
Just a sanity check here that TOS206 does actually run from alt-ram without any crazy-ass patching ? as I was sure that PP's program which loads TOS into alt-ram did a lot of crazy patching to get it to work ?
But in this particular case I don't think there is any point in ROM running in alt-ram. The physical ROM can be accessed at 16Mhz anyway.
There's a few things here.
* Firstly, you're still running normal ROM. Don't play with AltROM.PRG until you're happy with AltRAM.PRG. AltROM.PRG is just a cool hack.
* Next, with AltROM.PRG (which we're not using), TOS isn't running from system RAM anyway.
As far as it's concerned it's running from memory at 0xE00000, just as normal. No patching required. That we allow it to be written to as well is besides the point -- we could elect not to and it would be utterly indistingishable from an external ROM chip (like yours on the ST536).
With AltROM.PRG, it's not that the system sees 4MB ST-RAM and 8MB of AltRAM and the OS is running from a reserved block within that allocation. The system only has 4MB ST-RAM and
7MB AltRAM.
You follow?
BW
PS The next evolution of AltROM, once you're happy with AltRAM, is to load the ROM image from disc instead of from phsyical ROM. This would allow you to do away with decoding logic altogether... :signhere:
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 14:41
by exxos
@Badwolf altram.prg seems fine currently. passes RAM tests.
IMG_0547.JPG
Currently I am trying to work out why the blitter is unhappy.
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 14:48
by Badwolf
exxos wrote: 05 May 2022 14:41
@Badwolf altram.prg seems fine currently. passes RAM tests.
Cool.
So this is 'stock' (CPU on top) or slave mode? (I'm so confused -- I thought we'd gone back to stock and were looking at floppy issues on the other thread!)
Currently I am trying to work out why the blitter is unhappy.
Blitter is not allowed access to AltRAM in the stock firmware. What I believe the main problem to be is that timing (pin to pin latency) is marginal on the SDRAM controller and one more logic gate in the chain pushes it over the edge.
The key is combining
altram_access_int with
altram_access_ext in the SDRAM controller's .ACCESS() input.
BW
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:10
by exxos
Badwolf wrote: 05 May 2022 14:48
So this is 'stock' (CPU on top) or slave mode? (I'm so confused -- I thought we'd gone back to stock and were looking at floppy issues on the other thread!)
I have "shelved" the H5 setup (slave mode) for now. I am working with the "CPU in booster" now.. But I wasn't having much luck with your firmware.. Hence coming back here for the "experimental" firmware. Basically my hacked up firmware , in trying to sort the blitter out etc.
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:13
by exxos
Badwolf wrote: 05 May 2022 14:48
The key is combining
altram_access_int with
altram_access_ext in the SDRAM controller's .ACCESS() input.
That has actually got stripped out kinda now..
Code: Select all
wire altram_access_int = (AS & AS_INT) | ENABLE | ( A[23:22] != 2'b01 && A[23:22] != 2'b10 ) ; //& rom_access
//wire altram_access_ext = AS | ENABLE | ( A[23:22] != 2'b01 && A[23:22] != 2'b10 );
//wire [3:0] REWRITE_A2320 = rom_access ? A[23:20] : 4'hB;
//& altram_access_ext
nouveau_sdram sdram(
.CLK(RAMCLK),
.CLK8(CLK8),
.RST(RST),
.ACCESS( altram_access_int ) ,
etc
I will add it back in on my next test...
Code: Select all
wire altram_access_int = AS_INT | ENABLE | ( A[23:22] != 2'b01 && A[23:22] != 2'b10 ) ; //& rom_access
wire altram_access_ext = AS | ENABLE | ( A[23:22] != 2'b01 && A[23:22] != 2'b10 );
//wire [3:0] REWRITE_A2320 = rom_access ? A[23:20] : 4'hB;
//
nouveau_sdram sdram(
.CLK(RAMCLK),
.CLK8(CLK8),
.RST(RST),
.ACCESS( altram_access_int & altram_access_ext ) ,
Blitter still fine.. but I have changed other stuff as well..
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:17
by exxos
This is working with blitter now...
IMG_0548.JPG
Just doing a RAM test for a bit to make sure I did not break that :lol:
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:25
by Badwolf
exxos wrote: 05 May 2022 15:17
This is working with blitter now...
Cool. But you thought you were here before, as well.
I refer the hon. gentleman to the reply I gave some days ago:-
https://www.exxosforum.co.uk/forum/viewt ... =30#p84015
Although, seriously, if you can get it to work reliably, that'd be a big upgrade.
BW
EDIT:
In case it's been lost in the mists of time, blitter *ALMOST* worked for me with that extra & term. However MiNT failed and certain combinations of menus showed artefacts, so it wasn't good enough to ship.
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:30
by exxos
Badwolf wrote: 05 May 2022 15:25
Cool. But you thought you were here before, as well.
.........
In case it's been lost in the mists of time, blitter *ALMOST* worked for me with that extra & term. However MiNT failed and certain combinations of menus showed artefacts, so it wasn't good enough to ship.
I had some intermittent RAM issues before.
I will send you my jed.. seems to work fine here with the quick tests I've done so far. But I don't have anything set up like MiNT which hammers the alt-ram.
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 15:46
by exxos
It ran GB6 fine, YAARTTT fine, load FB and :fire: :fire: :fire:
IMG_0549.JPG
@Badwolf You don't think the clock switching is adding random timing glitches into the RAM logic do you ? 8Mhz we know isn't happy. So if a slower CPU causes problems, maybe if there are timing discrepancies in the clock that could throw it out as well.
Re: DSTB1 exxos first tests & experimental firmware.
Posted: 05 May 2022 16:57
by Badwolf
exxos wrote: 05 May 2022 15:46
It ran GB6 fine, YAARTTT fine, load FB and :fire: :fire: :fire:
@Badwolf You don't think the clock switching is adding random timing glitches into the RAM logic do you ? 8Mhz we know isn't happy. So if a slower CPU causes problems, maybe if there are timing discrepancies in the clock that could throw it out as well.
I couldn't rule it out, but the way the controller has been coded from the ground up is to be (relatively) clock agnostic. It's meant to react in the shortest time to stimulus and only assert DTACK when it's ready, holding the output for as long as AS remains low. The switching, if anything, should give it more time.
There are, however, a LOT of terms in the equations governing the SDRAM. I honestly just think this is one too many. The line probably isn't stable in time and the state machine gets out of whack. For you, it's FB that shits out, for me it's MiNT.
Try removing the altram_ext term from the .ACCESS() line again, and I bet the problem goes away.
BW