ST536 STE EDITION

[exxos]

@agranlund I will try the BLTFIX on your site later just to make sure im not using a old version..

But when I run memspeed with desktop cache on, when I get back to desktop, they are off again. So I assume memspeed turns caches off. I think I did mess with the caches in GB6 earlier and wasn't much different anyway.

[exxos]

Grabbed the latest BLTFIX

Clean boot TOS206.. desktop cache ON.

IMG_3241.JPG

Loaded BLTFIX desktop cache went OFF!

Turned cache back on in desktop.

Ran memtest again...

IMG_3242.JPG

Back on desktop cache is OFF again!


I turned cache ON, ran GB6, toggled cache on and off various times, long story short, made no odds.. :shrug:

GB6 has:

Code: Select all

; bits (used by 68020/30)
ienab030_bit	=	0
ifrz030_bit	=	1
iclre030_bit	=	2
iclr030_bit	=	3
ibrst030_bit	=	4

denab030_bit	=	8
dfrz030_bit	=	9
dclre030_bit	=	10
dclr030_bit	=	11
dbrst030_bit	=	12
wa030_bit	=	13

[agranlund]

Interesting. And that sucks.
Perhaps it doesn't matter too much if most(?) people running accelerated machines has NVDI anyway?
But you'd still want TOS to respond with Yes if a polite program is asking TOS if blitter is "enabled" before choosing render codepath, so for that reason it's nice to have. I know there was at least one fullscreen program/game that did so even though the rest of its blitter code was doing direct hardware access.

I've got no conclusive ideas what the issue is, only vague guesses which are at best useful for narrowing down which areas I would have looked at first in blitfix and tos206 sourcecode (I'm not going to :) )
Out of interest, I'm assuming you ran blitfix from the autofolder and got the same bad behavior.

[exxos]

Out of interest, I'm assuming you ran blitfix from the autofolder and got the same bad behavior.

Just tried and exactly the same.

Turning the blitter OFF in GB6 made no odds.

I did wonder if its was running in STram. So set PRG flags.. Speed jumped up a bit from to 746% so 87% drop (was 121% drop before)

Also odd int-div test drops to 1630% from IIRC 1720%.

[exxos]

@Badwolf I am trying to setup your register but I really don't get Verilog. Its driving me nuts!

I mean I have..

Code: Select all

wire selected_patch_test = (A[29:2] == 28'h00200000) && (AS30 == 1'b0); // 8MB long word aligned 
//wire selected_patch_test = 1'b0; // ok

always @(posedge CLK7M) begin
    if (BUSEN_IRQ == 1'b1) begin
        data[7:0] <= { D[7:6], 1'b0, D[4:0] };  // IRQ logic modifies incoming D
    end
    else if (selected_patch_test == 1'b1) begin
        data[7:0] <= 8'b10101010;  // hardcoded value from patch address read
    end
end

assign D[7:0]  = BUSEN_IRQ ? 8'bzzzzzzzz : data[7:0];

IRQ part (lets just assume that works fine for now :lol: )

The code seems straightforward.. but as soon as I decode the address, the STE won't even try to boot up!!

I was trying to multiplex assign D[7:0] = BUSEN_IRQ ? 8'bzzzzzzzz : data[7:0]; before and gave up. DTACK issued OK but all I got back was random numbers.. which you would think I would just get back FF really anyway!

I did have it at the 80MB and 90MB mark, but not sure STOS is happy there, so moved it to the 8MB mark as nothing should be there.. but something still isn't happy.....

EDIT:

This seems a lot happier ( as in the STE boots now! )

Code: Select all

wire selected_patch_test = (A[29:2] == 28'h00200000) & ~AS30 & DTACK;

Tried this and it just locked up after the Atari logo ! :roll:

Code: Select all

reg SWAP_ON;

always @(posedge CLK7M) begin
    if (BUSEN_IRQ == 1'b1) begin
        data[7:0] <= { D[7:6], 1'b0, D[4:0] };  // IRQ logic modifies incoming D
        SWAP_ON <= 1'b1;
    end
    else if (selected_patch_test == 1'b1) begin
        data[7:0] <= 8'b10101010;  // hardcoded value from patch address read
        SWAP_ON <= 1'b1;
    end
    else begin
        SWAP_ON <= 1'b0;
    end
end

// Drive the bus only when SWAP_ON is high
assign D[7:0] = SWAP_ON ? data[7:0] : 8'bzzzzzzzz;

I'm really starting to hate Verilog! :pullhair: :headbang:

And the AI's as they hell bent on swapping things around when they shouldn't be doing!!!

EDIT

Even more fancy..

Code: Select all

always @(posedge CLK7M or negedge RESET) begin
    if (!RESET) begin
        SWAP_ON <= 1'b0;
        data[7:0] <= 8'h00;
    end else if (AS30 == 1'b1) begin
        // Bus inactive → release SWAP_ON
        SWAP_ON <= 1'b0;
    end else if (BUSEN_IRQ == 1'b1) begin
        data[7:0] <= { D[7:6], 1'b0, D[4:0] };  // IRQ format
        SWAP_ON <= 1'b1;
    end else if (selected_patch_test == 1'b1) begin
        data[7:0] <= 8'b10101010;              // test pattern
        SWAP_ON <= 1'b1;
    end else begin
        SWAP_ON <= 1'b0;
    end
end

:comp:

EDIT:

Well one problem is I forgot to rename the BUS_EN variable :roll:

My first read comes back as 255 and all second ones 127.. wait a few seconds and 255 again ! I mean the value is supposed to be 170!

Think I got SWAP_ON values backwards as well ... maybe I should just goto bed :)

[exxos]

Finally!!!

IMG_3244.JPG

I'm not sure my autoboot code is right now.... I thought that was tried and tested.....

[exxos]

I'm coming to the conclusion that the address bus isn't stable when AS30 goes low!! To much random crap keeps happening!

Or there's some odd internal "fan out" issue screwing things up.

Possible generating a internal AS30 might fix it as it would give the internal address time to settle before trying to use the address for anything.

But I'll probably try a address latch per module and see how that goes. I'm pretty much at that point anyway now.

I suppose I could test AS30 and ROM CE. and see what the real world delay is there...

[exxos]

ERROR:Cpld:886 - Function block FB3 was too congested to route successfully.
This occurs due to excessive (>= 50) product term input fanins to this
function block. Consider moving output signals in this function block to less
congested function blocks, buffering output signals that must remain in this
function block, or selecting a larger package.

:shrug:

[exxos]

It doesn't like the extra logic of the latched address bus then :roll: Solve one problem.. create another :roll:

Trying to add in a word register and as soon as a bit more logic gets tied into the address bus, all hell breaks loose !

IMG_3246.JPG

I don't think these PLD's have the internal capabilities for running lots of stuff like multiple address decoding.

I seem to have found another odd problem now. BLTFIX lockups up when running from AUTO after my TOSCOPY.PRG runs..

[Badwolf]

I'm not sure if it's helpful at all but IIRC STEs decode (ie. issue DTACK) for the 0x00Dxxxxx range.

Here's how I do register decodes on DSTB1:

https://github.com/dh219/DSTB/blob/rev2 ... _68k.v#L70

This is a write-only setup, though. You poke it. Thinks happen. No read back.

For a two-way register, I've an example in DFB1 starting here:

https://github.com/dh219/DFB/blob/main/ ... 1r5.v#L149

and look for reg_access throughout.

I've not seen any issues with address line decoding on either platform, though.

PTERMs is a limit you specify on the fitting page. You can choose to have logic more spread out at the expense of further 6ns (in your case) delays.

It's one of the two setting that 'exhaustive fit' fiddles with. If you're worried enough about timing to use the 6ns version, I'd probably not worry about this enhancement request if it involves you needing to move away from 'speed' optimisation or changing the PTERM limit.

BW

PS. my daughter is going through a period of not sleeping unless someone sits with her for an hour or more so I've had exactly no time the last couple of days for CPLD changing. :(