DFB1 BadMooD issues

[dml]

Hi,

I hopped over here from AF to look at the BadMooD issue on DFB1. I should be able to post a WIP build soon to try, maybe it will shed some light on whats going on here. (Note that it will be a WIP - not intended for release. I am still working on a new release)

By default, on VGA, BadMooD will use tweaked 58Hz modes (and a special 56Hz mode for overscanned titlescreen) - which *should* be ok on most monitors. It does work on the various displays I have access to.

Earlier versions of BadMooD used even lower refresh - 55Hz but it did cause some monitor sync troubles so I had to nudge it up to 56/58 for later versions.

With the -vgasafe switch, the released version will use Atari-standard 60Hz mode for the titlescreens but this does not change the ingame modes at all. I'm now modifying the code to use clean/standard modes for all cases when -vgasafe is used.

When I re-release this, I will probably drop the -vgasafe switch and default everything to standard 60hz modes - using the tweaked modes will require -vgatweaks or similar...


While the problem does appear as a loss of display sync - it is not at all clear that it is caused by these VGA frequency tweaks because the same problem should occur with/without DFB1 on the same displays. This part is puzzling.

The non-hatari builds change the Videl registers mid-display, which might have contributed. But the Hatari build avoids this, yet seems to produce the same result.

BadMooD does use the blitter for some things, although not much. Mainly for statusbar updates and some colour overlay fx.

It may be that writing to Videl registers with the DFB1 enabled is causing some kind of new issue. Perhaps they can be written at certain times but not others, or can't be written too close together, or something odd like this. Bus access on the Falcon is complicated by the fact there are caches and an MMU (+ asynchronous arbitration / busmaster competition) between the CPU read/writes and the actual events taking place to/from memory. All of this can be influenced by the presence of an accelerator and how it functions. It is still not clear why DFB1 would be special here vs any other accelerator...

[Steve]

Thanks for looking into this. Besides being good for the DFB1, I'll be happy to use these modified versions not requiring -vgasafe, as my falcon is bus boosted, so it'll be handy to just be able to double clock ;) (rather than typing -vgasafe each time)

[Badwolf]

It may be that writing to Videl registers with the DFB1 enabled is causing some kind of new issue. Perhaps they can be written at certain times but not others, or can't be written too close together, or something odd like this.

Possible -- perhaps there's a delay between wanting to write to the Videl and that write taking place as the clock has to switch down first? Would normally only be an issue with one-off-writes in the middle of a stream of internal processing, or TT-RAM accesses.

My first guess would have been DSP write slowness as writes to that from an accelerator are complicated (no A0 line, has to be synthesised by the GALs, requires timing funkiness pin the CPLD). But then I wouldn't have expected the RGB display to work either!

Bus access on the Falcon is complicated by the fact there are caches and an MMU (+ asynchronous arbitration / busmaster competition) between the CPU read/writes and the actual events taking place to/from memory. All of this can be influenced by the presence of an accelerator and how it functions. It is still not clear why DFB1 would be special here vs any other accelerator...

I'm guessing clock switching. Not sure how CT2 worked, but perhaps it did asynchronous clock bus access mediation rather than clock switching?

Unfortunately the firmware I currently have flashed doesn't have a 'go slow' mode (ie. run at 16MHz all the time), but I need to do some firmware work next week anyway, so I might see if the VGA mode works when running external CPU but at stock speeds. Would give us an additional data point if nothing else.

Cheers,

BW

[dml]

My first guess would have been DSP write slowness as writes to that from an accelerator are complicated (no A0 line, has to be synthesised by the GALs, requires timing funkiness pin the CPLD). But then I wouldn't have expected the RGB display to work either!

Aside from VGA refresh rates, the next thing to fall over is usually the DSP. But when this happens, the game freezes. If it somehow manages to fail a DSP exchange without freezing, it would draw garbage somewhere visible. There is plenty of non-DSP related drawing also. So you'd get a freeze, or a visible display with something on it.

In the video capture you shared, it looks like the Videl is just switching off - the sync goes and no more data. It looks very similar to what you would see if you switched to an external video clock.

I expect BadMooD can continue running without any vblank/refresh events happening as it uses 200Hz MFP TimerC as the event clock for game ticks. So it is possible the Videl has just shut down while the game look just keeps going.

Why that would happen, no idea. :)

I'm guessing clock switching. Not sure how CT2 worked, but perhaps it did asynchronous clock bus access mediation rather than clock switching?

Not sure what CT2 does. But I know that early F030 cpu overclock mods just fed a faster clock to the 030 clock pin and let it compete with slower devices via BG signals (which meant it was waiting for the bus much of the time).

The BLiTTER, Videl, SDMA all compete with the CPU for STRam access. This is why running higher bandwidth videomodes on Falcon result in slower CPU performance.

BTW probably not so interesting, but all Falcons have a HW register flag controlling the bus frequency - it can be changed from 16 to 8MHz in software. I don't rememeber if the CPU is included in this change or not but the BLiTTER is affected.

Unfortunately the firmware I currently have flashed doesn't have a 'go slow' mode (ie. run at 16MHz all the time), but I need to do some firmware work next week anyway, so I might see if the VGA mode works when running external CPU but at stock speeds. Would give us an additional data point if nothing else.

Ok that will be interesting. I still don't have a clear picture of whats happening here but I should have a test build soon to try.

[dml]

A random question on DFB1...

Does the interface between 68030 and FastRAM support Motorola's burst mode protocol? The 030 has a flag in its CACR cache register which enables 'burst mode' - which should (under certain circumstances) read 4 contiguous longwords from RAM instead of 1, to fill a single cache line (there are 16 lines, each 4x 32bits or 16 bytes wide = 256 bytes). A kind of prefetch behaviour for block copy operations. The exact details of how/when this happens are covered in the 68030 User Manual but accessing this seems to depend on how the 030 is interfaced with the RAM.

The 'burst' is somehow negotiated without granting the bus back to other devices. I think it claims the bus, reads 4 x 32bit words then releases it. The access pattern depends on the address fetched (it will fetch a 16 byte window, aligned to 16 bytes, around the actual fetch requested).

The 040 and 060 have a move16 instruction which explicitly make use of this type of exchange (versus implicitly, which is all the 030 can manage via the cache).

Anyway, just curious. This flag defaults to OFF on the Falcon. Not sure about TT. Enabling it on Falcon normally has no effect because the signals/logic is not there to deal with it.

[Badwolf]

A random question on DFB1...

Does the interface between 68030 and FastRAM support Motorola's burst mode protocol?

Yes. It does with the release firmwares, although I don't quite recall if the bastardised firmware I'm running at the moment has it turned on -- which means I can't promise the tests I did with your new version were with burst or not.

I'm afraid I have the STE back on the surgeon's table ATM. I really need to give some more love to DFB1's firmware. Memory access is not as quick as it could be, even with burst working.

The 'burst' is somehow negotiated without granting the bus back to other devices. I think it claims the bus, reads 4 x 32bit words then releases it. The access pattern depends on the address fetched (it will fetch a 16 byte window, aligned to 16 bytes, around the actual fetch requested).

If the 030 is in a state to accept a burst, CBREQ is asserted by the processor[1]. If the memory wishes to continue serving data (it's entirely optional), it will assert CBACK with STERM[2]. The 030 will then keep accepting data with every subsequent clock that STERM is asserted until it negates CBREQ or until 4 cycles have completed.

ie. it's one bus cycle but (up to) four memory cycles.

DFB1's current implementation of the memory controller is an almost direct lift of Stephen Leary's TF330 logic and only accepts burst when starting on a 16-byte boundary.[1]

Anyway, just curious. This flag defaults to OFF on the Falcon. Not sure about TT. Enabling it on Falcon normally has no effect because the signals/logic is not there to deal with it.

That's odd -- I didn't know it was normally inhibited. During development I would certainly see burst accesses during normal OS operation and the effect is certainly noticeable in benchmarks.

BW


[1] https://github.com/dh219/DFB/blob/main/ ... ram.v#L118
[2] https://github.com/dh219/DFB/blob/main/ ... ram.v#L265

[dml]

That's odd -- I didn't know it was normally inhibited. During development I would certainly see burst accesses during normal OS operation and the effect is certainly noticeable in benchmarks.

Yes that's odd (and thanks for answering the rest of the question). I should have a look at Nembench again to see if it actually includes a test for CACR|BURST or not. Probably not, since I probably never ran into a hardware config that let me confirm it. It will be enabled on Afterburner040 but the CACR control isn't exactly the same.

There is a separate burst control flag for instructions vs data BTW. But IIRC normally both are off (I will check).

[dml]

You're correct and I'm remembering things wrongly - burst mode is enabled by default. I only checked it with Hatari but it's TOS4 which decides so result will be same on HW.

I wrote a little program just now to dump the CACR state on 030:

https://www.dropbox.com/s/0qy30bovf2ew9 ... p.zip?dl=1

IEn = i-cache enable
IBu = i-cache burst mode enable
DEn = d-cache enable
DBu = d-cache burst mode enable
WrA = write-allocate (data cache allocates written 32bit words to the cache, instead of dirtying the cache entry)

(WrA is also an interesting one with FastRAM attached)

[dml]

Apologies - that binary required a FPU fitted for no good reason.

Link to the fixed version: https://www.dropbox.com/s/0qy30bovf2ew9 ... p.zip?dl=1

Why might this even be useful? Because it might help detect when some piece of software has changed the CACR but hasn't put all the flags back - especially the ones nobody notices on a base Falcon, which in turn could quietly affect the performance of your DFB1. If any such software is noticed, it could then be cautioned in your notes.

Hopefully that doesn't actually happen though :)

[Badwolf]

Why might this even be useful? Because it might help detect when some piece of software has changed the CACR but hasn't put all the flags back - especially the ones nobody notices on a base Falcon, which in turn could quietly affect the performance of your DFB1. If any such software is noticed, it could then be cautioned in your notes.

Thanks!

Whilst burst mode is noticeable in the benchmarks, I'm not sure if I could detect it in normal operation. Perhaps if a marginal game felt oddly sluggish?

A bit like exiting BM, though, if you're not 100% sure about the state of the system, a reboot should fix things.

I've been working on PiStorm a couple of days, but I think I'm going to get out the old Xilinx programmer and do a bit of firmware work on DFB1 today. Can give you some figures.

This util should also work for TF536 users, BTW. That has better TT-RAM performance than my card by default and then burst on top of that too.

BW