Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

dml wrote: Fri Sep 30, 2022 4:16 pm BM does attempt to split-screen for the status bar (changes video mode at line #168), which is a bit rude on VGA probably. Maybe it is something to do with that. Although it is more likely a signal issue in the Falcon (while doing that, or while hitting the DSP... or some other noise).

The only build of BM that does not do this is bmhat.ttp - the Hatari build. Simply because Hatari doesn't emulate Videl register changes mid-frame, so drawing the status bar needs workarounds.
I tried bmhat.ttp (as I hadn't before) in VGA mode just to see if that were the issue and sadly not. Same as the other failures, it gets past the menu screen and then as proper rendering commences, the screen breaks down and ends up black.

Can hear the sound effects, so the game is running!
dml wrote: Fri Sep 30, 2022 4:20 pm
Badwolf wrote: Fri Sep 30, 2022 2:44 pm The way DFB1 works is to speed up and slow down the external 030 depending on bus accesses, so clock can vary between 8 and 50MHz. I don't see immediately how that would affect Videl timings, but it's grist for the mill.
I'm kind of amazed the bm030.ttp binary works under those conditions. It doesn't bother handshaking with the DSP except when there is no other choice. But if it works it works :)
If it's running from ST-RAM there won't be much up-changing anyway, so perhaps that's actually what's allowing it to work?

Cheers,

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

mikro wrote: Fri Sep 30, 2022 4:39 pm Any chance you could post them together somewhere? I remember your FPU test but can't recall seeing the other two you mention. :)
I'll try to dig out what I can and put them somewhere although I will need to pop my stack 5 or 6 levels before I can get to it :)
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Badwolf wrote: Fri Sep 30, 2022 9:22 pm I tried bmhat.ttp (as I hadn't before) in VGA mode just to see if that were the issue and sadly not. Same as the other failures, it gets past the menu screen and then as proper rendering commences, the screen breaks down and ends up black.

Can hear the sound effects, so the game is running!
If you can hear SFX (i mean active, new sounds happening not just a repeating loop of the last sound) then the problem is display / VGA signal related - or it has tried to put the screen in TT ram for some reason. Or some other display related foible. But can't imagine why it would usr the wrong ram since the TT ram is detected and mapped separately and there are rules in the BM memory allocator for the type of ram it is allowed to use for different things.

Badwolf wrote: Fri Sep 30, 2022 9:22 pm If it's running from ST-RAM there won't be much up-changing anyway, so perhaps that's actually what's allowing it to work?
If it wasn't for your comment on the SFX still going - I'd agree. But if you can hear stuff happening the game has not frozen so it has not run into a bus handshaking fault (which is the expected fault for trying to talk to the DSP when its not ready, or more typically, DSP trying to talk to the CPU when its not ready).

It seems to be display related and therefore probably not hard to sort out once understood.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

So the BadMood '-vgasafe' command switch informs the game that your machine may not have the builtin 32MHz/16MHz system clock running at 32MHz i.e. the system is bus-boosted to 20MHz or more.

VGA modes normally use the secondary (25MHz) system clock but BadMood uses some funny displaymodes for its title, intermission and game modes and a few of them select the 32MHz system clock with a modified Videl config. This is certainly true for the title screens which are 416x240 truecolour on VGA (not achievable on the default 25MHz clock). I'm less sure of the ingame modes - will need to look at that.

So in short, you need the -vgasafe mode if you're trying to run BM on a 20-24MHz system bus with a VGA monitor.

I think running it on RGB with a boosted system bus just won't work at all because there are no custom modes to force the RGB modes to change from the 32MHz system clock to an external/alternative clock, which is always required in that situation. Maybe BM doesn't mess with the clock select in this case but I expect it just doesn't work as-is. OTOH I don't think anyone relies on such a config anyway.

If your main system clock is still 32MHz (and if your accelerator still works with an RGB monitor - doesn't dynamically mess with the bus clock which is shared with RGB signal) then -vgasafe isn't going to make any difference to you.

But it can still be a problem with the ingame displaymodes. Those ignore the -vgasafe flag because there is only one set of displaymodes for VGA and RGB for ingame. I'll take a look soon to see whats going on with that.

[EDIT]

"If your main system clock is still 32MHz ... then -vgasafe isn't going to make any difference to you."

...actually not always completely true. This flag will still force a 'safe' VGA mode (320x240) on the menus etc, which *might* help if your monitor doesn't like the titlescreens and goes into 'no signal' mode - but it won't affect ingame display either way.
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

dml wrote: Sat Oct 01, 2022 9:42 am "If your main system clock is still 32MHz ... then -vgasafe isn't going to make any difference to you."

...actually not always completely true. This flag will still force a 'safe' VGA mode (320x240) on the menus etc, which *might* help if your monitor doesn't like the titlescreens and goes into 'no signal' mode - but it won't affect ingame display either way.
My system clock is till 32 (only CPU and FPU clocks are affected) and I see the opposite -- menus work, game doesn't.

-vgasafe: no difference.

Yes, it's running in the background, I can fire shots and hear the monsters and *every now and again* a frame or two will flicker onto the screen -- which suggests it's just displaymode rather than allocating screen RAM to TT-RAM or similar.

Exiting the game 'blind' results in a corrupted display (rather than all black like in game) on return:

IMG_5901.jpeg

Cheers,

BW
You do not have the required permissions to view the files attached to this post.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Just curious - but how does a DFB1 machine publish TT-ram availability and address range to TOS? e.g. does it use some software in the auto folder? Is it software specific to the card or a more general thing?
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

dml wrote: Sat Oct 01, 2022 1:17 pm Just curious - but how does a DFB1 machine publish TT-ram availability and address range to TOS? e.g. does it use some software in the auto folder? Is it software specific to the card or a more general thing?
It just supplies RAM at 0x01000000. TOS4 itself doesn't do anything with it unless it's told about it. To that I normally use FASTRAM.PRG from Anders Granlund (intended for the TF536, but my board and the 536 are very similar designs and handle TT-RAM similarly).

I don't think it's a TT-RAM issue, however, as 1) not declaring the RAM with FASTRAM.PRG makes no odds and 2) BM030 doesn't use TT-RAM anyway (I've an LED that flashes on TT-RAM access).

I'm putting together a little example video of the symptoms.

Cheers,

BW.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

Badwolf wrote: Sat Oct 01, 2022 1:53 pm I'm putting together a little example video of the symptoms.
Here we go, does this explain what I'm seeing better?

https://youtu.be/ZMtsa4rw66Q

(No audio -- I muffed up the mic input)

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Thanks for the video. Interesting. The first one I'm sure is a display sync issue of some kind, or Videl config is getting messed up for some reason. But definitely a video config/signal issue.

Difficult to say much about the other cases yet. Probably the same thing but could be a mixture.

BTW in your sysinfo dump in RGB mode it registers 'TOTAL TT-RAM' = 0, yet 'FREE TT RAM' = 128mb. The sums for ST+TT reflect the same. Any idea what's going on there? Maybe that's normal but surely TOTAL should be >= FREE? :-)

I realise that is not likely involved with the issues seen here but its curious and could complicate testing with TT ram.

BTW even BM030.TTP will try to use TT ram (for the code and local data only) if the PRGFLAGS say that it should be loaded into TT ram - which might be enough to cause some problems but it does seem the main issue is video signal related and occurs with or without TT ram present.

Anyway I'm looking at the video config to see what might be going on here.

[EDIT]

The last case is a typical freeze going into the game and probably getting into DSP/CPU handshaking issues. Which could just be a problem with the code for that version on that accelerator. I think we can ignore it for now.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Looking at the displaymode setup code, the profile used for ingame mode on VGA is a 320x200 or 160x200, both at 55Hz.

So the 55Hz refresh is probably too low for some VGA monitors. This part can be easily corrected and tied to the -vgasafe switch.
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

dml wrote: Sat Oct 01, 2022 4:26 pm BTW in your sysinfo dump in RGB mode it registers 'TOTAL TT-RAM' = 0, yet 'FREE TT RAM' = 128mb. The sums for ST+TT reflect the same. Any idea what's going on there? Maybe that's normal but surely TOTAL should be >= FREE? :-)
I think that's a particular issue with this version of Sysinfo. Everything else seems to report fine.
dml wrote: Sat Oct 01, 2022 6:59 pm Looking at the displaymode setup code, the profile used for ingame mode on VGA is a 320x200 or 160x200, both at 55Hz.

So the 55Hz refresh is probably too low for some VGA monitors. This part can be easily corrected and tied to the -vgasafe switch.
Thanks.

Just to be clear, my monitor is happy in VGA mode with DFB1 disabled (ie. running as stock).

Cheers,

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Badwolf wrote: Sat Oct 01, 2022 7:16 pm Just to be clear, my monitor is happy in VGA mode with DFB1 disabled (ie. running as stock).
That part I can't explain, so maybe there is still some fun ahead.

I did think of one other thing - can you check the default.cfg (or whatever cfg you use to launch it) for the initial detail levels:

xdetaillevel 1
ydetaillevel 0

Assuming 'xdetaillevel' is 1, can you set both of these to 0 and retry both bm030.ttp and bmhat.ttp to see if anything looks different? I doubt it, but easy to rule out quickly.



Anyway I'll let you know when I have a version with a 'normal' VGA mode ingame.
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Badwolf »

dml wrote: Sat Oct 01, 2022 8:29 pm Assuming 'xdetaillevel' is 1, can you set both of these to 0 and retry both bm030.ttp and bmhat.ttp to see if anything looks different? I doubt it, but easy to rule out quickly.
Will try this when I'm back at home on Friday. :thumbs:

Thanks!

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Badwolf wrote: Mon Oct 03, 2022 11:38 am Will try this when I'm back at home on Friday. :thumbs:
Probably not worth the trouble for that test TBH. I should have a new build ready by the weekend anyway.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

I noticed recently that Hatari debugger 68k disassembly has changed quite a bit since v1.x-2.0 era. (I'm using v2.5.0-devel)

Disassembly syntax is very strange 'sub.l (a3,$00c)', address column seems to be blended into the instruction data column, indentation is bad and square braces [ are not closed, among other things. Combining these things = very very difficult to read. :-P

Also, the '== $0058a4a' runtime evaluation hints are helpful, but not in the middle of the instruction text. This makes the code impossible to recognise vs the source code. Needs a separate column. I think it is not aiming to be human-readable in this form but I don't really know...

It this a consequence of changing a library somewhere and/or a format scheme isn't working on Windows, or just broken and hasn't been noticed yet? Or am I doing something silly here. Or are these changes intended to drive a debugger UI.

(I guess this Q should really go to Hatari mailing list but maybe Eero knows whats happening here? I am way behind on Hatari changes so maybe this is intentional and/or configurable).

Code: Select all

> d pc
(PC)
0058a6e65da                    bcs.b #$da == $0058a4a (T)
0058a7049fa0b2               lea.l (pc,$0b2 == $0058b24,a4
0058a742cae024               move.l (a6,$024) == $015263a [0053e8e,(a6) [005077e
0058a7828cb                    move.l a3,(a4)+ [0000000
0058a7a2016                    move.l (a6) [005077e,d0
0058a7c90ab00c               sub.l (a3,$00c) == $01cf87c [0000080,d0
0058a806f3c                    ble.b #$3c == $0058abe (T)
>
0058a822c80                    move.l d0,(a6) [005077e
0058a84202b008               move.l (a3,$008) == $01cf878 [*01cf7f0,d0
0058a882040                    movea.l d0,a0
0058a8a41e8ffe0               lea.l (a0,-$020) == $01b04e0,a0
0058a8e7020                    moveq #$20,d0
0058a90c028015               and.b (a0,$015) == $01b0515 [1,d0
0058a9466b4                    bne.b #$b4 == $0058a4a (T)
0058a96206801c               movea.l (a0,$01c) == $01b051c [01b09c0,a0
czietz
Hardware Guru
Hardware Guru
Posts: 2040
Joined: Tue May 24, 2016 6:47 pm

Re: Bad Mood : Falcon030 'Doom'

Post by czietz »

Hatari used to have two disassemblers. The UAE one, which is the one you're currently seeing. I don't like it, either; for the same reasons as you. Then there was the "external" disassembler, which probably is the one you (and I) were used to.

The Hatari developers recently decided to remove the external disassembler. They added support for the Capstone library, instead (which is not totally bug-free, tbh). However, the Capstone library obviously needs to be installed and found by the build process. It guess it wasn't for your Hatari binary, and, therefore, it fell back to the UAE disassembler. Do you build your own binaries?

Or you somehow lost the configuration option. You can test whether you get the Capstone disassembler by running Hatari with the "--disasm ext" commandline option.
User avatar
npomarede
Atari God
Atari God
Posts: 1424
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Bad Mood : Falcon030 'Doom'

Post by npomarede »

The above disassembly extract does indeed look very strange ; unless I badly merge some WinUAE's change, there should be no such closing "]" error.
As christian wrote, maybe your config is still using the 'ext' disassembler ? which is in fact in a very "raw" state for cpu >= 68020.
could you try with "--disasm uae" and "--disasm ext" and see which one matches the above disassembly ?
czietz
Hardware Guru
Hardware Guru
Posts: 2040
Joined: Tue May 24, 2016 6:47 pm

Re: Bad Mood : Falcon030 'Doom'

Post by czietz »

No, this certainly looks like a broken(?) version of the UAE disassembler. For me, the UAE disassembler ("--disasm uae") looks like that: Ugly and cluttered (imho!), but the braces are all closed:

Code: Select all

00e00120 41f9 00fa 0000           lea.l $00fa0000,a0
00e00126 0c98 abcd ef42           cmp.l #$abcdef42,(a0)+ [00000000]
00e0012c 6622                     bne.b #$22 == $00e00150 (F)
00e0012e 0128 0004                btst.b d0,(a0,$0004) == $003f83ac [00]
00e00132 6716                     beq.b #$16 == $00e0014a (T)
00e00134 48e7 fffe                movem.l d0-d7/a0-a6,-(a7)
00e00138 2028 0004                move.l (a0,$0004) == $003f83ac [00000000],d0
00e0013c 0280 00ff ffff           and.l #$00ffffff,d0
00e00142 2040                     movea.l d0,a0
00e00144 4e90                     jsr (a0)
For comparison, Capstone disassembler, selected by "--disasm ext".

Code: Select all

$00e00120 : 41f9 00fa 0000                     lea.l     $fa0000.l,a0
$00e00126 : 0c98 abcd ef42                     cmpi.l    #$abcdef42,(a0)+
$00e0012c : 6622                               bne.b     $e00150
$00e0012e : 0128 0004                          btst.l    d0,$4(a0)
$00e00132 : 6716                               beq.b     $e0014a
$00e00134 : 48e7 fffe                          movem.l   d0-d7/a0-a6,-(a7)
$00e00138 : 2028 0004                          move.l    $4(a0),d0
$00e0013c : 0280 00ff ffff                     andi.l    #$ffffff,d0
$00e00142 : 2040                               movea.l   d0,a0
$00e00144 : 4e90                               jsr       (a0)
EDIT: This is with Hatari built from commit a72c58bae.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

czietz wrote: Wed Oct 05, 2022 3:59 pm Or you somehow lost the configuration option. You can test whether you get the Capstone disassembler by running Hatari with the "--disasm ext" commandline option.
I saw this earlier but wasn't able to reply. Thanks for the info, I'll try the --disasm ext switch in this build.

I usually obtain new Hatari builds (including this one) from the Windows nightly builds posted here http://antarctica.no/~hatari/ although I update to new versions very rarely, typically between projects :)
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

npomarede wrote: Wed Oct 05, 2022 5:34 pm As christian wrote, maybe your config is still using the 'ext' disassembler ? which is in fact in a very "raw" state for cpu >= 68020.
could you try with "--disasm uae" and "--disasm ext" and see which one matches the above disassembly ?
The new build picked up the config from the previous version so it could be complicating matters yes. I'll test it with a clean config and see what the disasm select switches give me. Thanks.
czietz
Hardware Guru
Hardware Guru
Posts: 2040
Joined: Tue May 24, 2016 6:47 pm

Re: Bad Mood : Falcon030 'Doom'

Post by czietz »

dml wrote: Wed Oct 05, 2022 6:54 pm I usually obtain new Hatari builds (including this one) from the Windows nightly builds posted here http://antarctica.no/~hatari/
If I see it correctly...
http://antarctica.no/~hatari/latest/windows/cmake-win64-release-a72c58b.log wrote: -- Checking for module 'capstone'
-- No package 'capstone' found
-- Could NOT find Capstone (missing: CAPSTONE_LIBRARY CAPSTONE_INCLUDE_DIR)
... these builds do not include the Capstone disassembler; so you're limited to the UAE one. But even that should NOT be broken as you've shown in your previous post.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2760
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Eero Tamminen »

czietz wrote: Wed Oct 05, 2022 6:26 pm No, this certainly looks like a broken(?) version of the UAE disassembler. For me, the UAE disassembler ("--disasm uae") looks like that: Ugly and cluttered (imho!)
You could provide wishes to Toni about that on the hatari-devel list. With suitable subject line, he's likely to notice it.

Btw. UAE disassembly should now include symbols in the disassembly itself, when instruction refers to symbol address.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3909
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Preview captures of latest BadMooD progress, posted yesterday:

https://www.youtube.com/watch?v=59VGI14_U7E


This is not quite ready to release as the full version is still a bit broken (and I wanted to do some additional minor stuff). But this is currently how it is looking.
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Bad Mood : Falcon030 'Doom'

Post by sunaiac »

Wow <3
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
viking272
Atari Super Hero
Atari Super Hero
Posts: 700
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Bad Mood : Falcon030 'Doom'

Post by viking272 »

dml wrote: Fri Oct 07, 2022 7:56 am Preview captures of latest BadMooD
Stunning, all that on a 4mb stock Falcon! Great work Doug. :cheers:
Post Reply

Return to “680x0”