Bad Mood : Falcon030 'Doom'

[mikro]

Your thoughts about the write-allocate bit reminded me of one thing: When a data write causes a cache miss, the 68030 will act as if it has no data cache and write directly to memory (except in write-allocate mode). So, in case you don't read content of video ram (and I guess you don't), you can skip all the fun with PMMU tree and disable the WA bit only :)

[dml]

Your thoughts about the write-allocate bit reminded me of one thing: When a data write causes a cache miss, the 68030 will act as if it has no data cache and write directly to memory (except in write-allocate mode). So, in case you don't read content of video ram (and I guess you don't), you can skip all the fun with PMMU tree and disable the WA bit only

Yes that's right - I didn't expect any change with WA disabled, but hoped to get some use out of it with WA enabled always.

And yes, it should be possible to do most of the same stuff without the PMMU using CACR manipulation (perhaps less efficiently and with more code scattered around).

The shadowing *should* be useful for a few things in BM - the one that interests me most is wall drawing where there can be 2 memory sources and one destination per pixel (at least for large, non-prelit textures which also don't live on the DSP), and where one of the sources may 'skip' addresses frequently (textures scaled down). It's nice to have the lighting table in the cache (source 2), but keep the texels (source 1) out of the cache in this case. This can probably also be done with prefetching and freezing - but with more code.

OTOH even this case may become redundant with mipmaps introduced - because there won't be nearly so much drawing using scaled down textures, and it will be possible to prelight (convert from 8 to 16bits with light level already rolled in) the small mip pages for direct drawing. Possibly even put the smallest pages on the DSP. This leaves only large texture pages used for scaled-up drawing - in which case no read-inhibiting is needed anyway.

However I'll finish poking around with the PMMU to see if there are any advantages to keeping it. At the very least it should reduce the amount of code needed to do that sort of thing on a plain Falcon booted into TOS, and it's one more thing explored that I don't need to think about anymore

[EDIT]

Actually I seem to remember another rule about d-cache and writes - if WA is disabled and there is a write 'hit' the associated cache entry gets invalidated anyway, even if it isn't filled. But I'm less sure about this one - will need to revisit the manual. And even if this is the case I'm not sure if the behaviour is any different with the cache-inhibit flag - it could be the same :-z.

[bullis1]

So very thorough...

This thread is always a good read.

[dml]

This thread is always a good read.

Mikro and others keep me on my toes. Although I should really post less and code more to get this done...

[dml]

Had some other thoughts about BM/Doom comparisons.

While there are areas where Doom simpler than BM (and might help simplify BM too), there are definitely some areas where BM looks a bit better. Occlusion testing for example.

It seems Doom has a 1D, 2-state occlusion test. Either a wall seg (that means anything between floor and ceiling - including upper/lower platforms, windows, walls) is solid, or its not. It either gets added to the occlusion buffer, or it doesn't. There isn't anything happening at finer resolution than that (although it is at least accurate to display columns).

The problem with this is, there are plenty of places where a wall isn't 'solid', but you still can't see through it. Like a raised platform near the viewer's face - or a window placed high on a wall such that you can only see some ceiling through it - or a 'door' which is nearly, but not quite closed (in fact I can see a special-case rule in the Doom code which turns fully-closed doors into solid walls, to help optimize this frequent case).

ocdm.png

BadMood uses a 2D occlusion buffer which tracks display column heights on the upper and lower bounds of each wall. This means if something is view-blocked by anything at all, it doesn't get drawn - even if the wall happens to be a non-solid wall. This applies to both walls and ssectors.

ocbm.png

There are plenty of places in Doom maps where the difference won't amount to much - but some places where it helps a lot. It isn't a huge deal but it's a nice thing to have in the F030 version.

[DarkLord]

Hate to butt in on a (very interesting!) technical thread, and/or slow down Doug
at all but I'm apparently being dense about getting this to run on my Falcon...

I grabbed the bm ttp, doom1.wad and ran it first by just dropping the wad on
the ttp (and later by opening the ttp and typing in doom1.wad). Same result
either way, it goes through a long list of things not found, then finally says
press any key to start.

It does start. In the upper left hand corner, I get a small display. looks like its
loading and going through textures or something, then just halts, requiring a
reboot. Sometimes there are few multi-color lines running across the entire
screen.

I tried 060 on/off, motherboard mods on/off, low res 16colors, low res 256
colors, low res TC.

All of course, with no ACC's, AUTO folder programs, etc, loaded.

If it makes any difference at all, I can run PMDoom etc just fine.

I took some pictures:

P3070004.JPG

P3070005.JPG

P3070011.JPG

P3070012.JPG

Thanks! (and sorry for any distraction).

EDIT: trolled through the thread here, noticed some of the posted pics
look like mine...am I supposed to load a level in the command line? If
so, what's the syntax for that? Thanks!

[dml]

I grabbed the bm ttp, doom1.wad and ran it first by just dropping the wad on
the ttp (and later by opening the ttp and typing in doom1.wad). Same result
either way, it goes through a long list of things not found, then finally says
press any key to start.

Can you try running the TTP and enter this commandline:

"-idoom1.wad -we1m1"

(without the quotes, and with DOOM1.WAD in the same directory as the TTP - alternatively specify -ic:\doom1.wad or wherever it happens to live on your HD)

This tells it to load the main IWAD and warp to level e1m1. This is normally what I do for testing - haven't looked at what happens if you just drag & drop (maybe doesn't work!). If this doesn't work something's up.

Chances are it wont run too well in 060 mode but 030 should be ok.

[EDIT]
...also, can you report the filesize of your IWAD? (doom1.wad? I assume it's the shareware version)

The colourful corruption is just the GEM desktop appearing in 16colour (or whatever) mode, with the VIDEL still stuck in truecolour mode. i.e. it crashed back to the desktop without restoring the video. It doesn't provide any useful information on the cause.


[EDIT #2]
...the 'missing' errors you are seeing suggests the level data isn't loading properly - like it's a different format (or content) from the ones I have been testing. Where did you get the WAD file from? Is it from shareware PC Doom, or did it come alongside PMDoom?

The IWAD versions I have tested with are:

DOOM1.WAD [4,225,504 bytes] - Shareware Doom (1.666?)
DOOM1.WAD [4,260,146 bytes] - Shareware Doom (1.9)
DOOM.WAD [12,408,292 bytes] - Ultimate Doom (1.9?)
DOOM2.WAD [14,612,688 bytes] - Doom2 v1.7
DOOM2.WAD [14,604,584 bytes] - Doom2 v1.9

[DarkLord]

Thanks for the quick reply.

Okay, it is the shareware wad, downloaded from a link in this message thread.

Filesize is: 4196020

Okay, I tried that command, "-idoom1.wad -we1m1" with no quotes and the
results were the same.

I also tried, "-if:\bad_mood\doom1.wad", again with no quotes and the same
results.

I also have a doom2.wad that I tried. It at least, gives no error messages about
not being able to find things, but it still gives the same end result.

Guess I've just got something weird going on here at Hall Manor. (nothing
unusual there! )

PS Both those wads work in PMDOOM. Go figure.

[DarkLord]

Ah, I see from your edit that the filesizes are different! I'll have to look and see
if I can find those and try them - will report back.

[dml]

Ah, I see from your edit that the filesizes are different! I'll have to look and see
if I can find those and try them - will report back.

If possible, try to get a clean download, and avoid loading it into PMDOOM before you try it in BM - I don't know what PMDOOM is doing and it would be nice to rule out the possibility that PMDOOM 'converts' the WAD to some 'Atari formatted' WAD...

(I really doubt that's the case but it would be pretty confusing if it did, and would break BM).


I think it's more likely to be a machine compatibility or 4mb/14mb thing. The current build gets tested on a 14mb stock machine - no fastram, no cpu acceleration, no funny timings. Just standard 16mhz CPU, 32mhz DSP, 14mb ram.

It may still work ok on 4mb machines but I have changed a lot of stuff and that may not longer be the case, could be temporarily overrunning 4mb. If your machine has 4mb STRam that might be it.

I can also do more 'timing compatible' builds for accelerated / timing-modified machines but they run slower on a stock Falcon, and I've been focusing on the stock spec this time round. I can put up a 'compatible' build later to see if that helps.

[EDIT]

I checked the most recent BM against DOOM1.WAD (shareware) and I get the same warnings/errors - it's not the cause. It's just that I only added some of these errors recently and hadn't tried that WAD in a while. It runs ok here.

So my guess is it needs 14MB and you have 4MB STRam?

[DrTypo]

I'm testing BadMood on a 4Mb Falcon.
BMT401.TTP does complain about missing stuff when loading DOOM1.WAD. I can see that the sky is missing when looking outside. Other than that I don't see any obvious texture missing. This also happen on a Hatari (14 Mb emulated Falcon).
However it doesn't crash and works fine (on both real Falcon and Hatari).
BMT307.TTP doesn't complain and there is sky outside.

The effect of lack of memory is that BadMood fetches textures very frequently when moving around. I can mitiguate this issue by removing ACC and AUTO stuff and starting from a low resolution, to free up as much memory as possible.

I start BadMood by typing with DOOM1.WAD as a parameter.
DOOM1.WAD size is 4196020 bytes.

[dml]

I'm testing BadMood on a 4Mb Falcon.

Ok so it's not running out of memory then. That narrows it down a bit.

BMT401.TTP does complain about missing stuff when loading DOOM1.WAD.

BM307 doesn't complain when the leveldata requests resources which can't be found - but BM401 does. I added that when I started getting problems with more recent PWADs not working (like UDMX/UDM1..) but the problems are probably related to fancy extensions/format changes for ZDoom/Boom etc...

I can see that the sky is missing when looking outside. Other than that I don't see any obvious texture missing. This also happen on a Hatari (14 Mb emulated Falcon).

The strange looking pink sky is actually the floor/ceiling texture normally assigned to the sky. You're just not normally supposed to be able to see it because Doom hijacks it with a special sky texture and shader. This is broken in BM just now so you see the default sky 'flat' instead.

However it doesn't crash and works fine (on both real Falcon and Hatari).
BMT307.TTP doesn't complain and there is sky outside.

BM307 has the special sky shader, it will be reimplemented later with a faster version.

The effect of lack of memory is that BadMood fetches textures very frequently when moving around. I can mitiguate this issue by removing ACC and AUTO stuff and starting from a low resolution, to free up as much memory as possible.

This will hopefully get much less painful when the textures get cache-preprocessed into a temporary folder so it doesn't have to convert them on the fly while wandering around the map.

Thanks for the input. Not sure what is causing DarkLord's crash - will have to think about it a bit more.

[dml]

Here's a build which is more suited to 'modified' Falcons - most of the timing sensitive optimizations are disabled - except the DSP floor texturing, which isn't so easy to disable at the moment (something for later...).

Curious to know if this works better.

[Eero Tamminen]

I think it's more likely to be a machine compatibility or 4mb/14mb thing. The current build gets tested on a 14mb stock machine - no fastram, no cpu acceleration, no funny timings. Just standard 16mhz CPU, 32mhz DSP, 14mb ram.

Latest BM still works fine in Hatari with 4MB. For me it still works only with old UAE core, not with latest WinUAE CPU core, with that it crashes after processing/showing all textures. Nearly about only difference between the cores should be timings accuracy...

Btw: the Linuxdoom build you attached earlier here doesn't run with 4MB (crashes to NULL pointer error), that requires 8MB of RAM.

[Eero Tamminen]

Here's a build which is more suited to 'modified' Falcons - most of the timing sensitive optimizations are disabled - except the DSP floor texturing, which isn't so easy to disable at the moment (something for later...).

This one also works for me only with Hatari's old UAE CPU core. (And if I mistype the WAD file name, it crashes...)

[f030]

Curious to know if this works better.

works better with fast ram, previous version crashes after some time
both versions do not work with 32 mhz cpu (MS32 set to 32 mhz)

[CiH]

New version works fine for me, tested on Centurbo 2 (50 MHz, 14mb ST-RAM, 64mb Fast ram.)

Frame rate between 13 frames and 23 frames a second generally, maxes out at 27 frames a sec.

[DarkLord]

Okay, with the new "c" version, success. I just ran both doom1.wad and doom2.wad
just fine. Drag 'n drop worked, didn't even have to bother with the command line.

Both seemed fast and responsive.

This was running in '060 mode, motherboard mods on.

So I guess my setup just didn't like something, timing wise, with the old one?

BTW, I do have a 14 meg ST RAM Falcon, with 256 megs of SDRAM in 060 mode.

Thanks for the alteration Doug!

[f030]

@dml, do you maybe know why do not work on MS32 at 32 mhz, and works well on other accelerators ?
BM 307 does not work too

[Omikronman]

Assuming that the Mighty Sonic is the same accelerator as the Eagle Sonic I had years ago (but the Eagle had no FastRAM), I can explain this. These cards seem to have some bad issues. When the Eagle Sonic ran an 32 Mhz CPU, the FPU was working but the DSP crashed. When the Eagle Sonic ran at 16 Mhz, die DSP was working, but the FPU crashed. So if you like to run Bad Mood you need a working DSP. Using the Mighty Sonic it will only be possible at 16 Mhz CPU. I replaced the Eagle Sonic with the Afterburner later. A good choice.

[dml]

Latest BM still works fine in Hatari with 4MB. For me it still works only with old UAE core, not with latest WinUAE CPU core, with that it crashes after processing/showing all textures. Nearly about only difference between the cores should be timings accuracy...

Still don't really understand the scenario here - unless we're using different settings under the same core. It appear to work for me. These are the settings I have:

(Hatari built with --enable-winuae-cpu)

haset.jpg

Btw: the Linuxdoom build you attached earlier here doesn't run with 4MB (crashes to NULL pointer error), that requires 8MB of RAM.

Ok. Might be related to the extra TC framebuffer required to display on the Falcon. In any case I wont be doing much with the linuxdoom port except to help with the binding process later on.

This one also works for me only with Hatari's old UAE CPU core. (And if I mistype the WAD file name, it crashes...)

I'll add that to my list (although I get an error message here if it cant find the WAD).

[dml]

works better with fast ram, previous version crashes after some time
both versions do not work with 32 mhz cpu (MS32 set to 32 mhz)

The recent builds do seem to crash in Hatari after a while, with the aggressive optimizations enabled. It runs reliably though with them disabled.

Not sure what's going on with the MS32... I wouldn't expect any problems with the BM402C build unless the CPU or bus is slightly quicker than a normal Falcon during floor drawing (or the DSP is slower, or missing/skipping clocks due to a bad signal...).

[dml]

New version works fine for me, tested on Centurbo 2 (50 MHz, 14mb ST-RAM, 64mb Fast ram.)
Frame rate between 13 frames and 23 frames a second generally, maxes out at 27 frames a sec.

Yes it should indeed fly on that system (Unlikely to work with the aggressive optimizations enabled though - not that they are needed in this case).

[dml]

@dml, do you maybe know why do not work on MS32 at 32 mhz, and works well on other accelerators ?
BM 307 does not work too

Some guesses...

- The MS32 is coupling the CPU to the bus faster at 32MHz than other accelerators, so the DSP isn't keeping up so well (Afterburner for example, is *slower* at STRam/DSP access than a stock Falcon, in my tests - so it's possible another accelerator might be slightly faster instead?)
- Your DSP is having problems with signals.

Try to get a NEMBENCH dump of your machine in 'clean' 16MHz mode and the 32MHz mode you're testing with - ideally in 320x240 truecolour mode. Would be interesting to see how this compares with other machines....


Also, do you have anything else that tests the DSP? Particularly DSP/CPU exchanges... I think the CT60 comes with something like that (or R Czuba provided a test app of some sort for checking the SRAM).

DSPBENCH is worth a try also but it only tests the DSP internally - doesn't do much CPU communication at all.

I don't think it's a faulty DSP but it's worth trying to rule it out anyway.

[dml]

Okay, with the new "c" version, success. I just ran both doom1.wad and doom2.wad
just fine. Drag 'n drop worked, didn't even have to bother with the command line.

Ok so this means your Falcon in 'clean' mode isn't 100% clean - there's something different about timings of one or more devices (cpu, dsp, memory...) or the behaviour of those devices on the bus. I can't really guess what - but it's probably time for *BENCH tests and comparisons with normal unmodified machines

This was running in '060 mode, motherboard mods on.

I'm surprised that works - 060 is really not within the aims of this project (esp. since the PMDOOM port of the original C code runs fine on 060 anyway) and the reliance on DSP is probably not ideal for 060 performance too.

(The aim for this one is to push a 16MHz 030 + DSP as far as possible, and get it playable on that spec).


I will try to make it as compatible as possible in the end for all Falcons of course, but it will only aim to be 'performant' relatively speaking, on the base spec machine.