exxos's DFB1 trials

[Rustynutt]

Can you test at 50MHz without fast ram enabled?

[exxos]

That switch is really early on in TOS.
Something, if a solution or related issue can't be discovered, I can easily test. I boot in "stock" configuration at "16MHz", with it jumping to 32MHz as soon at the bus control bit is read. I've not given that much though as its not been an issue here (non DFB).
But don't think the 8MHz startup is due to TOS, it's the COMBEL. The configuration bit only switches the COMBEL to full clock at that point.

Is odd because at some points I have seen a LED I had to indicate 16MHz light up just before the logo comes up.

However the current code does not see any write register access until it gets to desktop :shrug: So how the hell is it switching to 16MHz mode ?|

EDIT:

If I look for READ access, then I can switch into 50MHz mode around the time the logo comes up :WTF:

[Rustynutt]

That switch is really early on in TOS.
Something, if a solution or related issue can't be discovered, I can easily test. I boot in "stock" configuration at "16MHz", with it jumping to 32MHz as soon at the bus control bit is read. I've not given that much though as its not been an issue here (non DFB).
But don't think the 8MHz startup is due to TOS, it's the COMBEL. The configuration bit only switches the COMBEL to full clock at that point.

Is odd because at some points I have seen a LED I had to indicate 16MHz light up just before the logo comes up.

However the current code does not see any write register access until it gets to desktop :shrug: So how the hell is it switching to 16MHz mode ?|

EDIT:

If I look for READ access, then I can switch into 50MHz mode around the time the logo comes up :WTF:

Yes, the logo is drawn shortly after. Thought I'd read you mentioned something about getting to the desktop, which is of course much later.

The default in TOS is to boot at 16MHz, at least the setting of the bit.
Other than accelerating the COMBEL, don't think theres a way around the initial 8MHz boot The Sparrow COMBEL is the same in this instance.

Something to think about maybe, have to check with Badwolf, is how dependent is the DFB at boot on the TOS ROM? AIRC, the DFB can boot flashed TOS without the Falcon ROM, but at what point does the DFB take over?
A stock Falcon switches to 16MHz pretty early. If there is a boot dependency of the DFB on the stock ROM to bootstrap, maybe something going on there, although a flashed TOS would be 16MHz, by default.

Afraid you're well past what ive worked with :)

[Rustynutt]

Could do a quick hack here.
Have one of the old CPU expansion boards. Eagle Sonic. It's only the CPU. Not a huge effort, it ties to the GALs nearly the same as the AB, with no other mods.

Could test the 2 50MHz 030's here to see if there are issues at 50MHz.

[exxos]

Something to think about maybe, have to check with Badwolf, is how dependent is the DFB at boot on the TOS ROM? AIRC, the DFB can boot flashed TOS without the Falcon ROM, but at what point does the DFB take over?
A stock Falcon switches to 16MHz pretty early. If there is a boot dependency of the DFB on the stock ROM to bootstrap, maybe something going on there, although a flashed TOS would be 16MHz, by default.

The DFB1X can boot from flash perfectly well. I've even verified this by removing the motherboard ROM.

"something" presumably the combel, defaults to 8MHz on reset. Then at some point just before the logo appears, something switches the 16MHz bit high for 16MHz mode.

The problem I have found is that the register is only WRITTEN to as it gets to the desktop. But clearly this is conflicting because it switches to 16MHz even before the logo appears.

My fix for this is to check for READS to the register, but this does not make any sense. but it works.

The problem with the DFB1 Is the clock switching cannot switch between 8MHz/50Mhz. It can only switch between 16Mhz/50Mhz.

So there is basically a "wait" which disables the acceleration until it is known the CPU is running at 16MHz. The only way to reliably do this I think is by checking that register for WRITES on bit zero. but again, those WRITES never appear until it gets to desktop.

They could be some bug in the firmware somewhere but I cannot see what. I mean if I did something dumb like have RW are inverted, then yes it would make sense but there is no inversion on it.

[mikro]

Oddly the Falcon seems to actually boot up in 8MHz mode until it basically gets to desktop.

That is not correct. TOS does

Code: Select all

ori.b     #$25,($FFFF8007).w

pretty early in the reset handler.

Btw that bit 6 is to check whether the Falcon has been powered up to avoid reinitialising some memory stuff.

[exxos]

@mikro the problem I'm having is I don't detect any writes to that register until it gets to desktop. The falcon switches to 8mhz if you hold reset, then at some point very soon after releasing reset, it switches to 16mhz. But there doesn't seem to be any writes to set 16mhz until it gets to desktop.

If I check for any CPU access to that register, I see a access just before the logo comes up. But that would be a read. Not a write. Hence I'm confused :(

[mikro]

Hmm, that's really odd. Because from what you describe it seems like the switch to 16 MHz is indeed happening "very soon", i.e. that would be the code I have posted.

To me it looks like the issue is the detection of the write itself, not whether the write is happening because it is surely happening.

@exxos oh, now it occured to me: isn't possible that you got confused that this is a RMW cycle? I.e. it's not a write per se, it's an OR against the hardware register.

[exxos]

@exxos oh, now it occured to me: isn't possible that you got confused that this is a RMW cycle? I.e. it's not a write per se, it's an OR against the hardware register.

Hmmm I'll have to check the timings diagram but I'd assume write would still actually go low ?

[Badwolf]

Bus control register detect is my mistake -- I'm only decoding 0x00FF8007 whereas TOS access it as 0xFFFF8007.

Blitter issue is simply that TOS uses it extensively, both to draw the Atari logo and in the VDI. There are no soft-blit routines in TOS4.

This is only a problem if one of two conditions occurs and you're not using a VDI replacment:

1) TOS in flash but differs from the one on board.

This is because fonts, the Atari logo, etc are blitted from ROM to the screen. Blitter will see the onboard ROM in the range 0xE00000 to 0xE7FFFF whereas the processor will see flash in that range. You get black blocks or messed up fonts (when using TOS's VDI).

2) TT-RAM is declared before the AES launches.

As Stephen suggests, the AES loads into TT-RAM. This is nice as it's quick, but the blitter tries to access TT-RAM and gets nonsense from elsehwere in ST-RAM.

The solution is indeed to patch TOS to soft-blit. The problem is no soft-blit code exists in TOS4, so it'd have to be lifted from TOS3, EmuTOS or fVDI. Only fVDI of those presently has soft-blitting code for the true colour mode, IIRC.

This is not something I personally know how to do yet.

Once EmuTOS supports true colour modes and the full AES 3 menu extensions it will be the one-stop solution for users with flash.

DFB1 doesn't technically need a motherboard ROM to boot and run, but the 1.0 firmware does, just to bootstrap to 0xE00030. Exxos' firmware will not require an onboard ROM at all, but if using TOS you'll get black boxes instead of the Atari logo, even using NVDI

There's no speed issue with the blitter, @Rustynutt, it's simply it has no physical way of reaching the RAM that's on the daughterboard and to access the flash would require new firmware and removing the onboard ROM. Not something I'd ship.

BTW, the 50/8MHz switching failing is a bug and one I imagine will be solved in firmware down the line. I think it's so unlikely someone would want to use an 8MHz system board but a 50MHz CPU that it's basically a problem in theory only. The only benefit would be for heat management (cf. the old CT2 instructions).

BW


I hope that clears up a ffe