Topic: dink's FBN Development & Fixes thread

[iq_132]

This is probably a stupid question, but how does one set the window'd mode to 32bit using the Enhanced blitter?  My windows desktop settings are 32bit.

I'm not sure you can. ^^

[iq_132]

Btw, mostly fixed the problem. for depths < 32 bit alpha is handled as "flicker." It's a little cheesy, but it works.

[dink]

 ** Starting DirectDraw7 blitter.
  * Initialising video: Total video memory minus display surface: 212.84MB.
  * Initialisation complete: 210.00MB video memory free.
    Displaying and rendering in 32-bit mode, emulation running in 32-bit mode.
    Transferring the image to video memory before blitting.
    Running in windowed mode. (this works fine)

 ** Enumerating available DirectDraw drivers:
 ** Starting Direct3D7 blitter.
  * Initialising video: Total video memory minus display surface: 212.84MB.
  * Initialisation complete: 180.10MB video memory free.
    Displaying and rendering in 32-bit mode, emulation running in 16-bit mode. <- maybe this can be forced to 32bit? ya think?
    Running in windowed mode, using Blt() to transfer the final image. (this doesn't)
I tried under blitter options -> advanced -> uncheck force 16bit, but, its still 16bit. hehe. drat!

[dink]

When using just the Enhanced (d3d7) blitter, it starts in 32bit for both rendering and emulation:
 ** Starting Direct3D7 blitter.
  * Initialising video: Total video memory minus display surface: 212.84MB.
  * Initialisation complete: 179.60MB video memory free.
    Displaying and rendering in 32-bit mode, emulation running in 32-bit mode.
    Running in windowed mode, using Blt() to transfer the final image.

but, when a game is selected, it goes to 16bit mode for emulation:
 ** Starting Direct3D7 blitter.
  * Initialising video: Total video memory minus display surface: 212.84MB.
  * Initialisation complete: 180.10MB video memory free.
    Displaying and rendering in 32-bit mode, emulation running in 16-bit mode.
    Running in windowed mode, using Blt() to transfer the final image.

Out of curiosity - Is there a reason why that happens like that?

[dink]

... see previous message ..

Out of curiosity - Is there a reason why that happens like that?

The [long] answer comes soon..
If hardware gamma is selected, it must render at 16bit, so it forces the emulation at 16bit.  Due to a mixup in the logic, it doesn't check to see if the gamma correction is actually enabled.  If hardware gamma is selected, but not enabled, it will still force emulation to be 16bit.  A small change to the logic in src/intf/video/win32/vid_d3d.cpp (see svn) solves the problem

best regards,
- dink

[dink]

I've been looking into a strange issue with the neogeo driver, every once in a while a savestate will crash when loaded.  It usually happens between 1 and 10 states saved - or not at all (especially when running fba under gdb.... or when I want it to..) - making it a really tough one to track down.

EDIT:
Later that day... Let's get things going..
Installed Dr. MingW (just-in-time debugger) on my system and into FBA by replacing the current exception handler with Dr.Mingw's, recompiled the neogeo core with better debug flags and no optimization. [don't worry - dr.mingw will only stay in my local codebase!]

Did some playing & crashing, fixed Prehistoric Isle 2's crashing savestates (which happens right around/after/when you go underground)

Now its time to take a break, the daytime heat is horrible!  Later after it cools off a bit, I'll try to fix the other intermittent savestate crash.  I think its separate from the one I just fixed, because the crash address was in a totally different place.  Its going to be a tough one, though, since I can't make it happen on demand.  It can be really illusive, too, sometimes it'll happen every other neogeo game one day, and the next day, not at all. 

best regards,
- dink

[dink]

A little info about this crash (pointer is trying to access an unallocated part of memory):
It would occur after loading a savestate which was saved (between 1 and 20 times - more or less) in neo_run.cpp, in neogeoWriteWordVideo() at

Code: [Select]

case 0x02: {
-->here-->        *((UINT16*)(NeoGraphicsRAMBank + NeoGraphicsRAMPointer)) = wordValue;
NeoGraphicsRAMPointer += nNeoGraphicsModulo;Upon deeper investigation, the NeoGraphicsRAMBank was getting clobbered by SCAN_OFF() in DrvScan():
SCAN_OFF(NeoGraphicsRAMBank, NeoGraphicsRAM, nAction); <- here.

So, I thought, Instead of using this SCAN_OFF(), lets just recalculate the NeoGraphicsRAMBank pointer upon savestate load,
the same way it is calculated later on in the code.  That should be foolproof, right?

*success!* I wrote a script that did over 2000 savestate & loadstates while Prehistoric Isle 2 was running, and not a single crash happened.  Now, the big question is, is this the same SS bug that I noticed in other MVS games?  I hope so, but I have a strange feeling that I might be revisiting this at a later time.

Big thanks to Jose Fonseca for his wonderfull Dr.Mingw just-in-time debugger.  Before this, I would always get a very strange crash address from this bug, which was usually situated somewhere around LoadRoms() - as gdb told me. 

best regards & happy gaming, my friends
- dink

[iq_132]

Excellent work! That crash has been around for aaaages!

[dink]

iq_132, thanks 
I am stupidly happy to have fixed this one before the big release

p.s. do you know of any others?

[dink]

Re: Fix SCAN_OFF() too [Re: Re: fix the crashing neogeo savestate thinggy]

Earlier today whilst reviewing yesterdays code I realized SCAN_OFF() was used in other parts of the code and thought that it would be a good idea to investigate how/why SCAN_OFF() is messing up pointers.  If SCAN_OFF() is bungling pointers that don't cause a crash - who knows what kind of corruption is going on behind the scenes.  Scary stuff!

I lifted SCAN_OFF() from FBA, put it in a little test program and added some printf's to see whats going on....

start: rambank=1020,ram=1000.
SCAN_OFF(rambank, ram, 0);
end: rambank=980,ram=1000.

rambank after SCAN_OFF() executes is supposed to be 1020, but here its 980.  This is really bad, especially since we're dealing with pointers 

To get the offset, SCAN_OFF was subtracting the rambank variable from ram. 1000 - 1020 = -20
So, it was saving -20 as the offset, and to recalculate the rambank(on savestate load), it was adding this saved value to the ram variable, which is where the 980 came from (1000 + -20=980).  A simple change so that it now subtracts the ram variable (1000) from rambank (1020), which gives 20 [which is stored in the savestate].  Now, when it adds the stored value of 20 to the ram variable, we get the proper value of 1020.

*I'm confused - What does all that mean?* Better reliability & stability when using savestates.  and, of course, none of that Guru Meditation sh*t 

Thats it for now,
best regards,
- dink

[Barry Harris]

Nice work dink. Very nice.

[dink]

thanks

[dink]

Heres my latest erm, effort, at tlcs90841 + rapid hero soundcpuenablement.  I really need help from someone with experience with porting cpu cores for this one.  Double check the basic stuff, like read / write byte from memory address, and everything else - as I must be totally missing the point here.  Some info: it inits the cpu in RapheroLoadCallback(), raphero_sound_read/write handle all the memory mapped stuff.  It does a few things at reset, but then the cpu just stops.   
To get started: toss tlcs* into src/cpu, d_nmk16.cpp into drv/pst90s, add edit makefile.burn_rules, search for sh2.o, add tlcs90.o after it & save then make.

[iq_132]

Heres my latest erm, effort, at tlcs90841 + rapid hero soundcpuenablement.  I really need help from someone with experience with porting cpu cores for this one.  Double check the basic stuff, like read / write byte from memory address, and everything else - as I must be totally missing the point here.  Some info: it inits the cpu in RapheroLoadCallback(), raphero_sound_read/write handle all the memory mapped stuff.  It does a few things at reset, but then the cpu just stops.   
To get started: toss tlcs* into src/cpu, d_nmk16.cpp into drv/pst90s, add edit makefile.burn_rules, search for sh2.o, add tlcs90.o after it & save then make.

I started my own port of that cpu core as well, I'll probably finish it up early next week. (hopefully). I'll probably end up merging what you've got with mine.

[dink]

iq_132, Awesome