exxos's Atari, Amiga & retro forum

Posted: **19 Apr 2022 08:39**

@agranlund The reboot problems seems to be related to Maprom. If I remove maprom from AUTO, I can use keyboard reset and IDE boots every time. If I enable Maprom, IDE boots from power up, but keyboard reset, IDE locks up. Pressing the reset button however works fine, I don't get it ?

Posted: **19 Apr 2022 08:56**

exxos wrote: 19 Apr 2022 08:39 @agranlund The reboot problems seems to be related to Maprom. If I remove maprom from AUTO, I can use keyboard reset and IDE boots every time. If I enable Maprom, IDE boots from power up, but keyboard reset, IDE locks up. Pressing the reset button however works fine, I don't get it ?

This is my guess :)

On first start, TOS206 will be doing its autoboot thing before the MMU has been setup, so you are going to see address $FFFFFA01

Once Maprom is executed it will setup the MMU for TOS206 just how TOS3+4 does it, translating all things FFxxxxxx into 00xxxxxx to prevent pre-32bit software from exploding.

So after the MMU is setup you will see requests for $00FFFA01 instead of $FFFFFA01.
I'm guessing the MMU setup is still active after a TOS206 soft-reset as well.

Posted: **19 Apr 2022 09:08**

agranlund wrote: 19 Apr 2022 08:56 This is my guess :)

On first start, TOS206 will be doing its autoboot thing before the MMU has been setup, so you are going to see address $FFFFFA01

Once Maprom is executed it will setup the MMU for TOS206 just how TOS3+4 does it, translating all things FFxxxxxx into 00xxxxxx to prevent pre-32bit software from exploding.

So after the MMU is setup you will see requests for $00FFFA01 instead of $FFFFFA01.
I'm guessing the MMU setup is still active after a TOS206 soft-reset as well.

ahhhh.

So basically

Code: Select all

localparam PATCH_ADDRESS = 30'hffFFFA01; 
localparam PATCH_ADDRESS2 = 30'h00FFFA01; 
wire BUSEN_INTREQR = ((A[29:0] != PATCH_ADDRESS) & (A[29:0] != PATCH_ADDRESS2)) | AS30 | ~RW30  | ~IDEINT ;

But code doesn't fit :(

But this is why I went with like

Code: Select all

24'hFFFA01

so it would decode 16 & 32bit ranges, but it never worked ?

Posted: **19 Apr 2022 09:26**

exxos wrote: 19 Apr 2022 09:08

Code: Select all

localparam PATCH_ADDRESS = 30'hffFFFA01; 
localparam PATCH_ADDRESS2 = 30'h00FFFA01; 
wire BUSEN_INTREQR = ((A[29:0] != PATCH_ADDRESS) & (A[29:0] != PATCH_ADDRESS2)) | AS30 | ~RW30  | ~IDEINT ;

But code doesn't fit :(

Yep either something like that, but it becomes cumbersome since you'd want to always be doing two comparisons for other things too (IDE address decoding for example)

I do this in main_top.v

Code: Select all

.A({A[31] ? 8'h00 : A[31:24], A[23:0]}),

I'm only checking the topmost bit here to decide what address to pass onto all the rest of the cpld code - it's not like you're ever going to have gigabytes of fastram anyway so it doesn't really matter that takes a shortcut and makes everything $80000000 and above into $00xxxxxx
The correct way would be to check all of the top 8bits though.

The rest of the cpld code then only ever have to consider $00xxxxxx when dealing with hardware registers.
Maybe something similar fits for you? I guess you could check A[29] or A[29:24] ?

Before I made that change, I had something like this in the patch-code to cover both normal and shadow.
(And a similar style check in logic for IDE address decoding)

Code: Select all

localparam PATCH_ADDRESS = 24'hfffa01;
wire ACCESS = ((A[31:24] != 8'h00) & (A[31:24] != 8'hFF)) | (A[23:0] != PATCH_ADDRESS) | AS20 | ~RW20 | PATCH;

exxos wrote: 19 Apr 2022 09:08 But this is why I went with like 24'hFFFA01 so it would decode 16 & 32bit ranges, but it never worked ?

Just checking the 24bit range seems risky? Wouldn't it potentially react to valid fastram reads when it shouldn't, like a read from $01FFFA01 ?

I don't know how the rest of the 24'hFFFA01 code looked like but I saw this in a previous post, and that one would actually compare 30 bits even though PATCH_ADDRESS only defined 24.

Code: Select all

localparam PATCH_ADDRESS = 24'hfffa01; 
wire BUSEN_INTREQR = (A[29:0] != PATCH_ADDRESS) | AS30 | ~RW30  ;

Posted: **19 Apr 2022 14:12**

agranlund wrote: 19 Apr 2022 09:26 Before I made that change, I had something like this in the patch-code to cover both normal and shadow.
(And a similar style check in logic for IDE address decoding)
Code: Select all
localparam PATCH_ADDRESS = 24'hfffa01;
wire ACCESS = ((A[31:24] != 8'h00) & (A[31:24] != 8'hFF)) | (A[23:0] != PATCH_ADDRESS) | AS20 | ~RW20 | PATCH;

ahhh yep, I was trying to think how to plug 00 and FF in but beyond my n00b skills.

agranlund wrote: 19 Apr 2022 09:26 the 24bit range seems risky? Wouldn't it potentially react to valid fastram reads when it shouldn't, like a read from $01FFFA01 ?

Good point , I keep forgetting about alt-ram.

I managed to compile using "Exhaustive fit" option ( which I just spotted) .

Code: Select all

localparam PATCH_ADDRESS = 30'hffFFFA01; 
localparam PATCH_ADDRESS2 = 30'h00FFFA01; 
wire BUSEN_INTREQR = ((A[29:0] != PATCH_ADDRESS) & (A[29:0] != PATCH_ADDRESS2)) | AS30 | ~RW30  | ~IDEINT ;

I will try your line to see if that fits easier. Your other examples I'll probably screw up the thing trying to make the changes.

It was indeed the 00 to FF thing.. It does now boot after a keyboard reset! very hard to program stuff when things keep moving about :lol:

Right then.. about this ST-RAM cache thing.. :lol: :pullhair: :stars: :crazy:

Posted: **19 Apr 2022 16:05**

@agranlund So trying out MR19 now.

Normal version.

IMG_0481.JPG

Cache version.

IMG_0480.JPG

Thing is, there is no ST-RAM cache code in my 536 yet.... :shrug:

Posted: **19 Apr 2022 16:35**

With ST-RAM cache enabled in code:

Oddly seems slower. :shrug: I might have screwed the code up :shrug:

IMG_0482.JPG

Will get FrontBench tested see what happens...

Posted: **19 Apr 2022 16:44**

exxos wrote: 19 Apr 2022 14:12 It was indeed the 00 to FF thing.. It does now boot after a keyboard reset! very hard to program stuff when things keep moving about :lol:
Right then.. about this ST-RAM cache thing.. :lol: :pullhair: :stars: :crazy:

Nice!! That's awesome :dualthumbup:

I don't know how good the fitter is at optimising and if something like this would even take up less space or not?

Code: Select all

localparam PATCH_ADDRESS = 24'hFFFA01; 
wire BUSEN_INTREQR = ((A[29:24] != 6'b000000) & (A[29:24] != 6'b111111)) | (A[23:0] != PATCH_ADDRESS) | AS30 | ~RW30  | ~IDEINT ;

or perhaps maybe even something like this is sufficient?

Code: Select all

wire BUSEN_INTREQR = ((A[29:24] != 6'b000000) & (A[29] != 1'b1)) | (A[23:0] != PATCH_ADDRESS) | AS30 | ~RW30  | ~IDEINT ;

Posted: **19 Apr 2022 16:46**

agranlund wrote: 19 Apr 2022 16:44
I don't know how good the fitter is at optimising and if something like this would even take up less space or not?
Code: Select all
localparam PATCH_ADDRESS = 24'hFFFA01; 
wire BUSEN_INTREQR = ((A[29:24] != 6'b000000) & (A[29:24] != 6'b111111)) | (A[23:0] != PATCH_ADDRESS) | AS30 | ~RW30  | ~IDEINT ;

That line is better for sure.

Struggling with the ST_RAM decode for the cache.. the fitter managed it after like 10mins though!

Posted: **19 Apr 2022 16:53**

@agranlund @Badwolf

GB6 seems slower with ST-RAM caches enabled. But FrontBench shows some difference.

FB with MR19_C & ST_RAM decode used - 3145

FB with MR19_C & WITHOUT ST_RAM decode used - 3032

113 frames difference with ST-caches enabled by the looks of it.

I guess having the boost on ST-RAM would be worth the performance hit on GB6 tests (mostly GEM) as its running way faster than stock anyway.

exxos's Atari, Amiga & retro forum

REV 3 - REV 5 - The beginning (ST536)

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning

Re: REV 3 - The beginning