Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

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

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby AtariZoll » Sat Jan 18, 2014 4:04 pm

Tested little on Falcon with 14 MB ST RAM, TOS 4.02, CF card on IDE, PP hard disk driver. VGA monitor.
WAD file is 12408292 bytes long one.
There was no sound, so I did same as with some STE games - run following seq.:

Code: Select all


    move.w  #1,-(sp)
    clr.l   -(sp)
    move.w  #8,-(sp)
    clr.w  -(sp)
    move.w  #$8B,-(sp)
    trap   #14
    lea   12(sp),sp


After it sound worked well. Above sets audio DMA in STE compatible mode, and is not needed with TOS 4.04 . I guess that you can add it with some basic TOS v. test.

Only error I saw is right after start - often credit list is in background of game start/selection menu, what looks pretty bad and confuses.
Really impressive considering 22 years old, slow HW. I was not able to test on some TV or classic monitor - should be faster as is said, and looking better - on high-res LCD pixels are too big.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jan 18, 2014 4:15 pm

AtariZoll wrote:There was no sound, so I did same as with some STE games - run following seq.:

Code: Select all

    move.w  #1,-(sp)
    clr.l   -(sp)
    move.w  #8,-(sp)
    clr.w  -(sp)
    move.w  #$8B,-(sp)
    trap   #14
    lea   12(sp),sp

After it sound worked well. Above sets audio DMA in STE compatible mode, and is not needed with TOS 4.04 . I guess that you can add it with some basic TOS v. test.


Yes this should be the fault Xerus found. Thanks for the codesnip, it will save me looking through the docs again. Although I'll need to check that's all that is needed since I don't remember doing much with the audio HW initial state - probably forgot all about it after it started working.

AtariZoll wrote:Only error I saw is right after start - often credit list is in background of game start/selection menu, what looks pretty bad and confuses.


I agree its pretty annoying - and when the titles flip it resets the menu selection too, which can be even more confusing.

It came about mainly because I disabled builtin demo replay during attract mode and shortened the title duration for certain tests - but it highlights this new problem, with the flip occurring very often while using the menu.

Will be revisiting the menus for beta anyway so it will get tidied up.

AtariZoll wrote:Really impressive considering 22 years old, slow HW. I was not able to test on some TV or classic monitor - should be faster as is said, and looking better - on high-res LCD pixels are too big.


Thanks - and yes, if you run with fat pixels on VGA it's better to stand well back :-D

Cheers,

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jan 18, 2014 4:35 pm

Have logged all the bugs reported to me so far.

http://devilsdoorbell.com/bug-tracking/

Feel free to add your own if you find anything. I'll reclassify them if necessary after submission.


I have still to enter all of the items on my own list but some are there already.

User avatar
GokMasE
Captain Atari
Captain Atari
Posts: 221
Joined: Sun Mar 02, 2003 11:16 pm
Location: Sweden
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby GokMasE » Sun Jan 19, 2014 11:20 am

Congrats again on the release Doug, it is really nice seeing you're getting the recognition you deserve for all the hard work :)

Strictly hypothetically speaking, would it be possible to reuse the BadMood engine for a Falcon implementation of e.g. Heretic?
I understand the game engine for the AI might be totally different from the one in Doom but from the looks of it I suppose the specs on the graphic rendering might be quite similar?
(Maybe for the exception of the ability to look/aim up/down, which IIRC is present in Heretic)

Regards,

/J

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 1:49 pm

GokMasE wrote:Congrats again on the release Doug, it is really nice seeing you're getting the recognition you deserve for all the hard work :)


Many thanks :-)

GokMasE wrote:Strictly hypothetically speaking, would it be possible to reuse the BadMood engine for a Falcon implementation of e.g. Heretic?
I understand the game engine for the AI might be totally different from the one in Doom but from the looks of it I suppose the specs on the graphic rendering might be quite similar?
(Maybe for the exception of the ability to look/aim up/down, which IIRC is present in Heretic)


Yes I think so. There are lots of derivatives of Doom, using versions of the original Id engine. Some are more heavily modified, or are more expensive to run (since they followed Doom - some a few years later when 486 and 586 were already common).

But in principle yes, and Heretic might be one of the more practical ones.

Other source ports of Doom probably also have some value, although anything which depends on user-side scripting for AI is probably going to be too expensive for a 16MHz 68030 - I'd be surprised if anyone these days implements such a thing with performance as a high priority.

There are certain changes which could (and should) be made to make scripted AI more realistic - e.g. a java-like bytecode representation for the AI (like QuakeC) which can also be compiled into fast ASM code if required, once 'complete'. If all of the expensive game functions - like line of sight checking and collision testing - are provided as 'black box' engine services, the AI doesn't need to cost so much on its own. It just needs to carefully use appropriate interaction flags and provide callbacks for certain kinds of interesting event (like being shot, or bumping into something). In this way, the engine does everything in compact, efficient bursts of related work for all objects at once, and the AI just responds to signals and issues a few signals of its own.

Doom would need a bit of rewriting to do that properly - it really only began with Quake. I think source ports like ZDoom already went in that direction for Doom although I haven't studied the details yet and I bet its expensive!

If I were writing a new engine, I'd probably do something along those lines - not allowing the AI to do complex work but simply provide rules and conditions for complex work done by the engine. It's quite a lot of effort to provide decent scripting though on a small machine, and only worthwhile if several games are planned using the same tech. At this time it's a bonus if even one game gets finished so it's probably best to think in this direction for good performance - but to avoid scripting and directly use C and ASM as the 'script'.

That's probably more info than you were looking for but it might be interesting for anyone who wants to have a go at hacking the engine into other games. :)

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sun Jan 19, 2014 7:31 pm

GokMasE wrote:Strictly hypothetically speaking, would it be possible to reuse the BadMood engine for a Falcon implementation of e.g. Heretic?


The original BM viewer from 90's supported Heretic WAD I think. Note that rendering was only 1/2 of Doom CPU usage, Douglas needed to optimize thinking part of Doom radically to get things working at acceptable speed (starting from 1/3 game tick, short-circuiting game AI event propagation etc).

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 9:58 pm

I spent a little time today looking at that Hatari crash (after fixing a few of the other open issues).

This is another strange one.

It doesn't seem happen on my Falcon at all, but I can get it to happen very easily inside the emulator. It occasionally happens immediately on startup.

After much pain debugging it, I found the stack is filling up with exception frames from the vblank interrupt. i.e. the vblank starts to occur on top of itself, and continues doing that until the stack is all used up, and it walks across the system variables.

This seems to occur because my VBL code lowers the interrupt priority mask to $2300 shortly before the RTE. This move SR instruction is the last executed before the recursion occurs (the subsequent address is on the stack, repeated over and over...)

Removing this 'yield' operation stops the fault occurring.

Just in case TimerB was somehow complicating matters (it is configured on the VBL), I removed it completely and that made no difference. I didn't remove TimerA or TimerC but there didn't seem to be much point - neither are related to VBL and neither are visible in the callstack anyway.


So I'm not sure how this can actually happen unless the VBL signal is issued very rapidly for some reason (or the signal is never released in the first place?). The VBL interrupt code contains no loops or other stuff which would extend it's execution - in fact it terminates shortly afterwards. Another one should not come along until quite a long time later.

The yield operation isn't needed in that particular interrupt and it can be removed anyway. It's mainly useful inside the TimerA since completing that is not time critical and it would otherwise block other stuff. But I do want to know how this can occur, and why it doesn't seem to occur on my Falcon :)

I'm wondering if it might start while changing the Videl register group. I haven't tested this idea yet, but probably will look into it. Still even if that was involved, I would expect a fixed number of VBL events in sequence before stopping on its own. Whatever is happening here does not stop on its own.

(?? scratches head ??)

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sun Jan 19, 2014 10:42 pm

How do you check for VBL?

E.g. Paolo's Hextracker freezes on startup with Falcon emulation because Videl emulation doesn't recalculate video address when related registers are read, they're currently updated only when explicitly written to (Laurent has TODO about that in videl.c).

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 10:52 pm

While finishing off alpha I had been thinking about other ways to do some of the engine stages, and eventually came to the conclusion that most (if not all) could be done almost as fast - or faster - without the DSP. Or at least, without the DSP doing what it does right now.

A lot of the core DSP code is from 1996 or somewhere around that time, and it implements some fairly complicated stuff in a reasonably optimized way. But the a lot of that 'stuff' is algorithmically quite similar to DView, which is not at all similar to Carmack's original methods - and causes sector fragmentation - something I had to then find separate solutions to (adding more code, complexity and DSP costs).

Also, neither of these are as efficient as some of the stuff I more recently cooked for STRay on the STE (having attacked those same problems a few times already over the years, in different ways), which solves fragmentation before it starts.

One of the more amusing realizations involved the possibility of performing an 'unbeatably fast' pixel-perfect wall (seg) occlusion test (or insertion), using just a single 68k instruction. It turns out the DSP will be slower in most - probably all - cases when compared with that. This is a bit weird, because I should have noticed that immediately when working on BM right at the start. I don't know why I missed it. Carmack had a 68040 when he wrote Doom. I wonder if he actually used this trick and never mentioned it? I've never seen it mentioned!

OTOH I don't see much evidence that he did any assembly code while writing Doom - it was Abrash who did that side of things later (and it was for x86).


So I think the complex stuff done by DSP to defragment floors can be largely sidestepped by slightly adapting and differently indexing the STRay floor spanbuffer, which greatly benefits from left-to-right ordered wall column insertion. This is something else which can be 'arranged' without DSP help. There are still some problems which would need solved there but I have some notes on it.

So it would be fun to see if BadMood could run at something like the same speed - without a DSP - by adopting new methods. Or even better, to then re-employ the DSP in a better way where it matters most. :)

I don't think I'll be able to test some of these ideas in the near future but I though it was worth bringing up, in case somebody else does. I'm trying to keep the number of live projects to 1.5 maximum (!), otherwise nothing useful will get done at all. Free time seems to shrink by the day.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 10:56 pm

Eero Tamminen wrote:How do you check for VBL?

E.g. Paolo's Hextracker freezes on startup with Falcon emulation because Videl emulation doesn't recalculate video address when related registers are read, they're currently updated only when explicitly written to (Laurent has TODO about that in videl.c).


That's interesting - interesting because one of the last things I did (*after* alpha release) was move the physbase register setting into an early stage of the VBL itself (before the yield), and away from the game's view finalize step. After this (and a few other, semi-related changes) the problem got much, much worse.

I'm trying to get my head around the implications of what you've just told me, but it seems like it could be related.

It's getting late now but I'll go away and think about it for a while.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 10:59 pm

Ok I think it does explain it.

1) the VBL occurs
2) I set the physbase register
3) I do some other, unrelated stuff (set up timerb etc)
4) I 'yield' to other interrupts as soon as the time-critical bits are done
5) bang - writing the physbase caused a new VBL to occur, when the SR goes below $2400... but the VBL hasn't quit yet
6) go back to 1), with a bit less stack than we had before

Make sense? :)

[EDIT]

Actually I saw the relevant code snippet on the Hatari devel list, and I don't think it explains what I'm seeing. I don't poll the video address anywhere in the program, it's not a 'wait vbl' problem, but rather vbl events occurring before a previous one completes.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sun Jan 19, 2014 11:43 pm

Do you read & use the video address counter for something?

Hatari Videl emulation seems to return always zero for that, and now that I looked closer, video address counter register write is also no-op.

I.e. Hextracker freezes because it doesn't advance anywhere in Hatari's Falcon emulation.

[EDIT]
OK. Because Hatari timings aren't yet quite correct for Falcon, maybe some interrupts can happen in different order, in a way that triggers the issue?

It's a bit weird that it takes so long of idling (with no user input) in game before the issue gets triggered. It's like some counter in BM overflows.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 11:53 pm

Eero Tamminen wrote:Do you read & use the video address counter for something?

Hatari Videl emulation seems to return always zero for that, and now that I looked closer, video address counter register write is also no-op.

I.e. Hextracker freezes because it doesn't advance anywhere in Hatari's Falcon emulation.


No, there is no reading of Videl state, only writing.

The only regularly written Videl registers are the usual physbase, and the current display counter (if screensplit is on, which it won't be in Hatari mode, or with timerb off - which it was during my last test).

Moving the physbase write into the VBL code *seems* to have made the problem more frequent / occur earlier. It's happening regularly now during the startup sequence and with any WAD (not just doom1.wad). Although I haven't properly figure out if that or some of the other smaller changes are responsible.

It does stop if I don't lower interrupt priority mask in the vbl. It's very strange that the VBL can recurse on top of itself without a loop present, or any jumps. I might even say its borderline not-possible.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Jan 19, 2014 11:55 pm

Eero Tamminen wrote:It's a bit weird that it takes so long of idling (with no user input) in game before the issue gets triggered. It's like some counter in BM overflows.


I agree. I've been trying to think of some way idling could cause this. However I think it may just be aggravating it. I don't think its limited to idling. I now see it during the early init sequence, before Videl init, but after vbl has been set up. Well before any idling.

[EDIT]

When I get a chance I'll do more testing on real HW, to see if I can force it to occur. If it happens even once it's a bug in my code and I'll just have to figure it out.

If it continues to not happen, I'll perhaps start to worry about whats going on inside Hatari. For now lets assume it's a bug.

Zamuel_a
Atari God
Atari God
Posts: 1236
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Mon Jan 20, 2014 7:25 am

Would it be possible without to much of work to make it runnable on a TT machine aswell? I understand the DSP code needs to be removed and probibly alot of other changes aswell. I tried one DOOM version for the TT once, but it runned in like 1 fps and I think it should be able to handle it better than that.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 10:01 am

Zamuel_a wrote:Would it be possible without to much of work to make it runnable on a TT machine aswell? I understand the DSP code needs to be removed and probibly alot of other changes aswell. I tried one DOOM version for the TT once, but it runned in like 1 fps and I think it should be able to handle it better than that.


It should be possible.

The TT doesn't have a chunky pixel mode so it would need to do a c2p pass. This limits the size of the display/resolution because c2p on 8 bits is quite expensive. I suppose two ST-style c2p/zoom passes from TT RAM would help but I can't guess what the max res would be in the end. Maybe similar to the current Falcon version, possibly smaller (?).

The rendering code would need to be changed to plot 8bit like the original. This isn't too bad though. I had 8bit/c2p in BM at one point in 2012 for tests. Mipmapping would need to be changed to work with a global, constant palette. Again not too hard.

It's really the 'not much work' part that poses the biggest problem :-) Very little would be untouched in the process, although it could be done incrementally on the Falcon until it becomes TT-clean, much easier than trying to get it to work directly on TT.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 10:50 am

So I tested that Hatari-crash bug overnight using DOOM1.WAD on the real Falcon, and didn't find any problems.

Run the same binary in Hatari and it dies either during startup, or after flipping through a few frontend pages.

So I'm left with the strange facts:
- when game crashes, stack is full of duplicate exception frames / return addresses pointing back to the code inside the VBL
- the address pointed is the instruction immediately after the move #$2300,sr - which was just there to yield to other interrupts
- removing this priority change makes the fault stop

I can only think of one scenario where a self-interrupting VBL could really happen, and even then it would happen only once and stop, and wouldn't cause any problems. And it would involve a large block of work interrupting the VBL - which I can find no reason for, unless it's a disk based event. There are no disk events taking place while repeatedly cycling through the 2-3 title screens according to the hatari log.

I'll try to see if something else is happening inside the VBL using Hatari, but I am starting to worry this might be an emulation fault of some kind with the best course of action being to just remove that instruction from the VBL.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 11:16 am

jvas wrote:Is it me, or what, but the game saves 0Byte files. Should saving/loading work? (I use an external SCSI CF card reader)


Jvas - can you confirm a few things for me before the next release?

I need to know if the game created BMC folder while playing it, and there should be 3 folders inside that, and many files inside those.

e.g. your directory tree should look something like this:

Code: Select all

BMDOOM.TTP
DEFAULT.CFG
DOOM1.WAD
BMC\
 FLT\
  file1.bmf
  file2.bmf
  ...
 TEX\
  file1.bmt
  file2.bmt
  ...
 SPR\
  file1.bmt
  file2.bmt
  ...


If there are folders and files like this (the files will have different names from above!), please check to see if any of the files are 0-bytes. And if most seem to be 0-bytes, please check if any are NOT 0-bytes.

I have made a change to the code but I am unable to test the problem here. Might as well get as much info from you as possible before releasing the next update. :-)

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Mon Jan 20, 2014 12:40 pm

I get the problem also with GCC 2.x build and TIMERBASE=1. And when disabling timer-D patching.

dml wrote:I can only think of one scenario where a self-interrupting VBL could really happen, and even then it would happen only once and stop, and wouldn't cause any problems. And it would involve a large block of work interrupting the VBL - which I can find no reason for, unless it's a disk based event. There are no disk events taking place while repeatedly cycling through the 2-3 title screens according to the hatari log.


The problem happens only when VBL priority is lowered within VBL handler?

I.e. additional things can interrupt it and delay its finishing before next VBL interrupt happens. What interrupts those could be?

Is there on real Falcon something that reduces number of those other interrupts, or VBL handler being called again, before currently running VBL handler returns?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 12:56 pm

Eero Tamminen wrote:The problem happens only when VBL priority is lowered within VBL handler?


The crash / infinite regress only occurs if priority is lowered. Leaving it alone stops the regress.

However another problem surfaces - double buffering is broken. There is no functioning backbuffer anymore, and I can see tearing in the game on Hatari (which does not occur when testing on HW). So it is behaving like an extra VBL is failing to occur inside the original VBL, and just executes after it - messing up the buffer switch. This happens *during the game*, and isn't visible on the titles. So that's also quite strange.

Eero Tamminen wrote:I.e. additional things can interrupt it and delay its finishing before next VBL interrupt happens. What interrupts those could be?


Maybe disk - but I can find no disk activity via Hatari tracing. And none is needed to cycle between those title screens anyway, it's all cached in memory.

Maybe TimerA - it mixes audio. But it has a limited duration (~20 lowres scanlines?).

If a TimerA did occur inside the VBL, it would delay it - but not for long. And if it did delay it for > 1 VBL, then it would have to keep doing that over and over, every interrupt, to cause infinite regress.

There is another reason I don't believe it can be TimerA - it also yields *immediately* before mixing audio, so subsequent VBLs would be able to occur inside the TimerA, and the TimerA would record many exception frames on the stack, mixed with VBL frames. I saw none. They were all VBL frames (about 100k worth of them!). I can see no evidence that suggests another interrupt delays the VBL.

And if it did, it should do the same on my Falcon if left long enough (which it doesn't).

Eero Tamminen wrote:Is there on real Falcon something that reduces number of those other interrupts, or VBL handler being called again, before currently running VBL handler returns?


I can't think of anything. All of the interrupts yield as soon as their time-critical work completes. TimerB is used on a real Falcon - which is one difference, but I hacked that out by pretending Hatari-mode while testing the bug. I also physically removed the lines of code which set it up, just in case. It doesn't seem to be involved at all.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Mon Jan 20, 2014 3:11 pm

dml wrote:There is another reason I don't believe it can be TimerA - it also yields *immediately* before mixing audio, so subsequent VBLs would be able to occur inside the TimerA, and the TimerA would record many exception frames on the stack, mixed with VBL frames. I saw none. They were all VBL frames (about 100k worth of them!). I can see no evidence that suggests another interrupt delays the VBL.


Mixing of audio reminds me that Hatari's Falcon CrossBar DMA transfer code does funky stuff with negative frame counter. Could BM code have something related to that?

Also, was your VBL handler still the VBL handler being called, nothing had changed that to something random?

[EDIT] negative = end address < start address.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 3:20 pm

Eero Tamminen wrote:Mixing of audio reminds me that Hatari's Falcon CrossBar DMA transfer code does funky stuff with negative frame counter. Could BM code have something related to that?


I'm not familiar with this at all.

Eero Tamminen wrote:Also, was your VBL handler still the VBL handler being called, nothing had changed that to something random?


I didn't confirm the VBL vector at $70 when the fault happens - although once it has started the whole system area gets deleted quite quickly. Catching it will involve a hatari bkpt on ($70) while also checking it's not a side effect of the regress, when the bkpt occurs!

I did get some more tests done over lunch though and found it is an interaction between TimerA and VBL after all. But nothing that explains how or why. See the hatari devel list for details.

I have stopped doing tests now, because I can't draw any sensible conclusions from the results, beyond the fact there's an interaction and that it can be prevented relatively easily. It still seems wrong to me, but I could have overlooked something, and for some reason my Falcon HW agrees :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 3:29 pm

Eero Tamminen wrote:[EDIT] negative = end address < start address.


I don't think this is possible - because I was careful to always calculate the end address in the TimerA / DMA frame handler itself, which is a fixed offset of 320*4 bytes from the frame start. This should exclude the possibility of a -ve buffer size.

However... I just remembered that I apply a nocache mask to all hardware buffer addresses - including the DMA buffer, so the adress 0x00050000 would become 0x0f050000. Perhaps that address is also being plugged into the DMA base address registers. I didn't check that.

[EDIT]

It seems I was stuffing the nocache version of the DMA buffer address into the DMA base address registers, which isn't helpful. However fixing this has no effect on the bug.

I'll need to leave this alone for now - got a lot of other stuff to do. Will look again in the evening.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jan 20, 2014 4:11 pm

There have been some crazy looking queries made on my source control server - almost random attempts to figure out whats on that port, and half-baked attempts at pulling data.

There are only 3 other people with the access details, and I don't think they have any trouble pulling code if/when they want to.

I'm not sure why it would be interesting to access this repo - but it's probably not aimed at the project specifically, just some random person or service nosing around to find security holes. For the moment it has been taken offline.

User avatar
jvas
Captain Atari
Captain Atari
Posts: 462
Joined: Fri Jan 28, 2005 4:30 pm
Location: Budapest, Hungary
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby jvas » Mon Jan 20, 2014 4:16 pm

dml wrote:
jvas wrote:Is it me, or what, but the game saves 0Byte files. Should saving/loading work? (I use an external SCSI CF card reader)


Jvas - can you confirm a few things for me before the next release?

I need to know if the game created BMC folder while playing it, and there should be 3 folders inside that, and many files inside those.

e.g. your directory tree should look something like this:

Code: Select all

BMDOOM.TTP
DEFAULT.CFG
DOOM1.WAD
BMC\
 FLT\
  file1.bmf
  file2.bmf
  ...
 TEX\
  file1.bmt
  file2.bmt
  ...
 SPR\
  file1.bmt
  file2.bmt
  ...


If there are folders and files like this (the files will have different names from above!), please check to see if any of the files are 0-bytes. And if most seem to be 0-bytes, please check if any are NOT 0-bytes.

I have made a change to the code but I am unable to test the problem here. Might as well get as much info from you as possible before releasing the next update. :-)


Uploaded the complete file list into Mantis ...


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 6 guests