exxos's DFB1 trials

[exxos]

Code: Select all

wire berr_ram = A[27:24] != 4'b1001; // 128MB

:2k2:

tt.jpg

One thing I have noticed is the STERM LED is very dim. So I may see if I can be on for longer so it is more visible..

EDIT:

OK done that.

Pretty odd because the RAM test makes it light up 50% most of the time, but has spouts of much brighter time :shrug:
Maybe read and write times different :shrug:

[Badwolf]

One thing I have noticed is the STERM LED is very dim. So I may see if I can be on for longer so it is more visible..

You could try slaving it to ttram_access instead. STERM is only asserted for one 50MHz cycle whereas the ttram_access state is active during the whole bus transfer.

In burst mode you'll see more STERMs per unit time, so that'll be the brighter read, I assume. But yes, writes are faster too. So bursting reads will look brighter than writes which will look brighter than non-bursting reads.

It's only meant to be a 'something's happening' indicator :)

BW

[Badwolf]

OK, deep breath... :)

Only just got home and turned on the booster is to have some weird reset issues now :shrug: I assume it only happens when the machine is "cold"

@Badwolf There is some notes in your code mentioning problems with EMUTOS starting up ?

Disabling the flash seems to alleviate the problem..

Here's what I think is happening, why that resetblock is wrong and what EmuTOS has to do with it.

The Falcon boots up in 8MHz mode. At a short time later the OS switches it to 16MHz mode.

On my earlier boards I could happily clock switch 50MHz to both 16 and 8MHz modes and I didn't realise that this had changed. It turns out, for whatever reason, my current board design or clockswitch logic cannot cope with a 50 to 8MHz switch.

(The switching works by holding one half cycle for up to two 'slow' cycles. So at 16MHz there's an 8MHz half cycle injected before 50MHz goes down to 16MHz. That's fine and normally transparent as all my 'slow' accesses take more than two cycles anyway. But at 8MHz, there's a 4MHz half-cycle in there. THEORY: It's possible that's too slow for some chips as the 030 has a dynamic core and hence a minimum clock frequency which is, roughly, around that figure)

So, long story short, if you toggle the system clock to 8MHz using a CPX or a poke to the bus control register, DFB1 hangs. This is non-ideal, but who the hell does that anyway? Just disable the DFB1 i f you want 8MHz mode.

THEORY: Normally at bootup, the 030 is reading from system ROM and using ST RAM both at system board speeds. There's no reason to speed up to 50MHz until the switch to a 16MHz motherboard has happened. So you kind of get away with it.

THEORY CONTINUED: I put EmuTOS on my flash ROM. I start seeing reset problems. I mistakenly identify it as an EmuTOS difference (cf. the comment in code) and discover that adding a timer delay after reset before allowing acceleration works. I just go with it as I have space.

THEORY CONTINUED: In retrospect it seems more likley it's this 8/50 swtiching issue and when executing code from Flash, the system is performing this switch immediately, before the OS has changed to 16MHz.

PROPOSAL: change the (arbitrary) timer to instead veto acceleration on reset and only clear after the first access to the bus control register, assuming it's the OS's speed-up call. This should have the advantage of saving macrocells to boot.

LONG-TERM FIX: come up with better clock switching logic. I'm sure it's doable, but I've not really thrown more than a few hours at it so far.

BW

[exxos]

PROPOSAL: change the (arbitrary) timer to instead veto acceleration on reset and only clear after the first access to the bus control register, assuming it's the OS's speed-up call. This should have the advantage of saving macrocells to boot.

Yeah, I did think similar, but my coding wasn't good enough to sort out anything fancy like that. I took your resetblock to basically add a delay.

But if the 8MHz issue is the case, why does pressing the reset button work ? I'd assume the Falcon would still boot up in 8MHz after a reset ?

EDIT:

Doesn't like 8MHz that's for sure.

IMG_0743.JPG

I guess monitoring the register like you say may be the best fix. Then if 8MHz is found, it disables the 50MHz switch totally. That's beyond my coding abilities unfortunately.

[Badwolf]

But if the 8MHz issue is the case, why does pressing the reset button work ? Id assume the Falcon would still boot up in 8MHz after a reset ?

Reckon it's down to the vagaries of the ramp up of the reset line and it determining it's 'high' at a varying different time to the motherboard, IYSWIM.

Anyway, switch on first access to the register would, I hope, cover most bases. When I get a board and do some firmware cleanup, I'll try that.

BW

[Badwolf]

So alt-ram was flashing during reset, so ive added XAS in that (need to test its not broke anything yet) also added resetblock into the rom_decode and that seems to have fixed the problem.. need to do more tests yet..

Had to remove XAS from ttram , some reason it was getting stuck after loading HD11.

Careful with quick fixes like that. You're almost certainly adding a circular dependency.

XAS is generated from AS if ttram (amongst other) is inactive, for example.

BW

[exxos]

Reckon it's down to the vagaries of the ramp up of the reset line and it determining it's 'high' at a varying different time to the motherboard, IYSWIM.

That's what I thought originally, hence mentioning the caps may be bad on my falcon. Or may need a better pullup on reset etc. But I didn't want to get side-tracked fixing problems with the motherboards.. again..

Though holding your reset jumper on the booster for some time then releasing after powerup doesn't work either anyway.

[Badwolf]

Though holding your reset jumper on the booster for some time then releasing after powerup doesn't work either anyway.

That reset is wired through to the system line. Only really there to let you flash the CPLD in situ without corrupting anything.

BW

[exxos]

Didn't know (or forgot) the blitter can also run at 8MHz!

Capture.PNG

[Badwolf]

Didn't know (or forgot) the blitter can also run at 8MHz!

Yeah, Rustynutt uses that for his bus acceleration trick.

BW