Regen 0.972 and 0.972D
Moderator: AamirM
Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?
this one is weird (happen also in Gens but differently): Plane B VRAM setup is indeed interrupted by Hint which will set some VDP registers and therefore change the code/address values. When returning from interrupt, further VDP Data writes will be ignored, resulting in this black "gap".Shadow wrote:Thanks Ketsuban, and so CRAM do these color dots.
PAL picture very cool, my TV was in PAL standard too, i dream about PAL filter
Added later:
I found bug in Sol-deace, this black border:
Note that code/address need to be updated on register writes, some games (Golden Axe 2 I think, it tries to write DATA port after setting a register write) rely on this. It seems to be more an interrupt/sync issue, I got this one too (original genesis plus did not)
EDIT: more weird stuff, here's the code that seems to accidentely unmask Horizontal Interrrupt too eraly (there is indeed no reason to use HINT during intro).
0x00000816: 0x206E 0x0042 MOVEA.L (0x42,A6),A0
0x0000081A: 0x4E60 MOVE A0,USP
0x0000081C: 0x2F2E 0x0002 MOVE.L (0x2,A6),-(A7)
0x00000820: 0x3F2E 0x0000 MOVE.W (0x0,A6),-(A7)
0x00000824: 0x4CEE 0x1FFF 0x0006 MOVEM.L (0x6,A6),D0-D7/A0-A4
0x0000082A: 0x4E73 RTE
this subroutine seems weird in many ways: first, what's the point of setting the User Stack Pointer, I thought games always run in the Supervisor mode ? Secondly, it seems to push data on the stack (A7 pointer) then call RTE instruction as if it was an interupt callback function (but this subroutine is called from main loop).
Well, what happen is that when the Status register is pulled back from stack, the value returned is 0 which make all interrupts unmasked (previous value was 0x500)
EDIT2: found the issue, it's because of VRAM write timings and the delay between VDP FIFO slots in H32 mode: if the delay is a a little too short or too long, horizontal interrupt will end up corrupting scroll plane setup. Adjusting it a little make the interrupt triggers exactly between VRAM setup and fixes the graphical issue.
Last edited by Eke on Tue Apr 06, 2010 10:48 pm, edited 3 times in total.
No.motke wrote:Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?
Here are some more bugfix/improvements requests regarding current regen (another truckload, previous mentioned ones are still actual as well):
* Sharpness loss on display (non exact size / resizing takes place for some reason), check "didge" "oldschool" and "stateside" letters:
www.dtech.lv/sega_dev/regen1onscreen.png
www.dtech.lv/sega_dev/regen1shouldbe.png
www.dtech.lv/sega_dev/regen1plugin2x.png
* Sound overloading causes ear tormenting wraparound instead of limiting,when PSG/FM volumes are changed (boosted a lot).
* There could be nice button in volume window that would instantly reset PSG/FM volumes to 1.0.
* PSG channel mask selector could be nice, as well as register display (PSG debugger). PSG channel selector could be in the same YM channel selector window.
* There is inconsistency between "sound channel switcher" and "2612 debugger" - channels are called differently (ch0..5 and ch1..6)
* Saving full z80 memory dump crashes regen and dumps a huge file, that also includes i/o range and window to 68k, should save 8k only.
* Z80 RAM viewer crashes regen whenever you scroll "too far away" (somewhere into i/o or m68k window space).
* YM channel select does not close using the close button, only [ok] works. Yet it's totally cosmetic thing.
* Tools could get sorted in a more consistent way (all related things grouped, for all things there is the same item sequence if applicable) - z80 ram editor below z80 debugger; channel/layer selects consistentently before/after the unit debuggers; etc. This would make things more instantly accessible and handy
* On a second attempt to open a 68k RAM viewer (that is - while it is already open) "no game loaded" error appears. A cosmetic thing, yet it would better just switch focus to the already opened window.
* Game "show do milhao" (something from Brasil) does not work in the same way like a bunch of other poor quality carts: at startup, screen becomes filled red and that's it. It might be made on the bugful chinese tomsoft sdk, haven't yet checked.
* There could be some sort of DMA action logger, a list (say for 8192 entries) that keeps last DMA transactions (source and taret address, mode, type) that could just be saved into text file anytime. Implemented as a rolling-pointer list it would have no impact on emulation speed at all, yet could tremendouly help debugging and/or reverse engineering things,
* DAC rate display could average longer so it is readable.
* YM DAC could have independant WAV dumping facility, that saves a sample without anymixing nd processing, whenever it is written into DAC register and DAC is enabled. This is useful to inspect in a bit level z80 samplig stuff to see how well does resampling/decompression/whatever works. Should be simple to implement and a unique feature, useful also for instant sample ripping.
* Mickey Mania level when moose is chasing mickey (that spectacular one) has a few graphical issues (while kega and real hardware shows things fine) - some sprites have a glitch line above them, and when sprite layer is disabled, mickey's foot is still visible and animating around (how come?)
www.dtech.lv/sega_dev/mickeymania_sprite_layer_off.png
www.dtech.lv/sega_dev/mickeymania_spriteglitches.png
* Sharpness loss on display (non exact size / resizing takes place for some reason), check "didge" "oldschool" and "stateside" letters:
www.dtech.lv/sega_dev/regen1onscreen.png
www.dtech.lv/sega_dev/regen1shouldbe.png
www.dtech.lv/sega_dev/regen1plugin2x.png
* Sound overloading causes ear tormenting wraparound instead of limiting,when PSG/FM volumes are changed (boosted a lot).
* There could be nice button in volume window that would instantly reset PSG/FM volumes to 1.0.
* PSG channel mask selector could be nice, as well as register display (PSG debugger). PSG channel selector could be in the same YM channel selector window.
* There is inconsistency between "sound channel switcher" and "2612 debugger" - channels are called differently (ch0..5 and ch1..6)
* Saving full z80 memory dump crashes regen and dumps a huge file, that also includes i/o range and window to 68k, should save 8k only.
* Z80 RAM viewer crashes regen whenever you scroll "too far away" (somewhere into i/o or m68k window space).
* YM channel select does not close using the close button, only [ok] works. Yet it's totally cosmetic thing.
* Tools could get sorted in a more consistent way (all related things grouped, for all things there is the same item sequence if applicable) - z80 ram editor below z80 debugger; channel/layer selects consistentently before/after the unit debuggers; etc. This would make things more instantly accessible and handy
* On a second attempt to open a 68k RAM viewer (that is - while it is already open) "no game loaded" error appears. A cosmetic thing, yet it would better just switch focus to the already opened window.
* Game "show do milhao" (something from Brasil) does not work in the same way like a bunch of other poor quality carts: at startup, screen becomes filled red and that's it. It might be made on the bugful chinese tomsoft sdk, haven't yet checked.
* There could be some sort of DMA action logger, a list (say for 8192 entries) that keeps last DMA transactions (source and taret address, mode, type) that could just be saved into text file anytime. Implemented as a rolling-pointer list it would have no impact on emulation speed at all, yet could tremendouly help debugging and/or reverse engineering things,
* DAC rate display could average longer so it is readable.
* YM DAC could have independant WAV dumping facility, that saves a sample without anymixing nd processing, whenever it is written into DAC register and DAC is enabled. This is useful to inspect in a bit level z80 samplig stuff to see how well does resampling/decompression/whatever works. Should be simple to implement and a unique feature, useful also for instant sample ripping.
* Mickey Mania level when moose is chasing mickey (that spectacular one) has a few graphical issues (while kega and real hardware shows things fine) - some sprites have a glitch line above them, and when sprite layer is disabled, mickey's foot is still visible and animating around (how come?)
www.dtech.lv/sega_dev/mickeymania_sprite_layer_off.png
www.dtech.lv/sega_dev/mickeymania_spriteglitches.png
That's what the game does. It takes tiles from the foot and moves them from the sprite plane to the scroll plane. Don't mind it; there are a lot of weird things going on behind the scenes.dtech wrote:when sprite layer is disabled, mickey's foot is still visible and animating around (how come?)
Pretty basic multitasking. It's using RTE for the switch into user mode then using TRAP #0 for the switch back.Eke wrote:EDIT: more weird stuff, here's the code that seems to accidentely unmask Horizontal Interrrupt too eraly (there is indeed no reason to use HINT during intro).
this subroutine seems weird in many ways: first, what's the point of setting the User Stack Pointer, I thought games always run in the Supervisor mode ? Secondly, it seems to push data on the stack (A7 pointer) then call RTE instruction as if it was an interupt callback function (but this subroutine is called from main loop).Code: Select all
0x00000816: 0x206E 0x0042 MOVEA.L (0x42,A6),A0 0x0000081A: 0x4E60 MOVE A0,USP 0x0000081C: 0x2F2E 0x0002 MOVE.L (0x2,A6),-(A7) 0x00000820: 0x3F2E 0x0000 MOVE.W (0x0,A6),-(A7) 0x00000824: 0x4CEE 0x1FFF 0x0006 MOVEM.L (0x6,A6),D0-D7/A0-A4 0x0000082A: 0x4E73 RTE
Well, what happen is that when the Status register is pulled back from stack, the value returned is 0 which make all interrupts unmasked (previous value was 0x500)
Dumb game bug, though. It could've been avoided with just one line of code.
Yes i noticed it on my real thing, games contains alot of hidden bugs which happen on real things...TascoDLX wrote:this subroutine seems weird in many ways: first, what's the point of
Dumb game bug, though. It could've been avoided with just one line of code.
Added:
Hmm strange...
on Kega Fusion it really don't happen, on my last Mega Drive 2 on Mickey Mania was these graphic bugs, and in game Sunset Riders in options was vertical brown lines...
So i not sure if it correct, and yes this is my opinion.
yeah, I noticed that , the TRAP 0 routine which is located a little above do the exact opposite of this fonction. Still it's rather strange that this is called during the main initialization (not the main loop) and it sets the interrupt mask to zero, isn't it ? And the SR is fetched from a memory address ($FF9920) that always return $0000 (it's cleared on startup with the whole RAM then is never modified).TascoDLX wrote: Pretty basic multitasking. It's using RTE for the switch into user mode then using TRAP #0 for the switch back.
.
exactly, there is a flag in RAM that is set when VDP writes loop are in progress which will prevent interrupts from changing VDP settings if set. For an unknown reason, the flag is not set for this specific portion of code (plane B setup).Dumb game bug, though. It could've been avoided with just one line of code.
On real hardware, VDP writes limitation will delay the previous loop (which fill a big portion of VRAM, over ~ 3frames) and make everything fits, but it's more likely by chance it happens like that
-
- Interested
- Posts: 15
- Joined: Thu Sep 25, 2008 9:11 pm
Does disabling Autofix Checksum solve this?dtech wrote:* Game "show do milhao" (something from Brasil) does not work in the same way like a bunch of other poor quality carts: at startup, screen becomes filled red and that's it.
Sorry I've been away for a while - schoolwork and all that. This is why I suggested that the default for Autofix Checksum should be changed to disabled (since the unlicensed protection chip handling now requires it to be disabled, and some games without such chips depend on it to be disabled); I haven't bothered to check what AamirM said about that, though.
I don't consider that the main initialization, but that doesn't really matter. The thread for that intro sequence contains its own initialization, as do other threads. The routines merely provide a means for executing thread code. It's up to the programmers to decide where they want to put any init code (and if they want to scatter it around).Eke wrote:Still it's rather strange that this is called during the main initialization (not the main loop)
It is modified. It's written back in the trap routine. Although, for that intro sequence, it tends to write back $0000 anyway.Eke wrote:And the SR is fetched from a memory address ($FF9920) that always return $0000 (it's cleared on startup with the whole RAM then is never modified).
Actually, now I see what it's doing. It's using H-INT to set the window on the top and bottom, so that the text is clipped. But I believe that can be done just as easily with sprites. Oh well.Eke wrote:exactly, there is a flag in RAM that is set when VDP writes loop are in progress which will prevent interrupts from changing VDP settings if set. For an unknown reason, the flag is not set for this specific portion of code (plane B setup).
-
- Interested
- Posts: 15
- Joined: Thu Sep 25, 2008 9:11 pm
Sorry for not mentioning this earlier:
It seems that the configuration window for the NTSC filter plugin doesn't expose all the settings used by blargg's NTSC filter engine, and anything not shown in the window is not saved to ntsc.ini. This means that there is no way to make the filter start up in the S-Video preset by default, since it differs from Composite only in some hidden setting which isn't saved. Could the configuration options be expanded for future releases of the filter?
It seems that the configuration window for the NTSC filter plugin doesn't expose all the settings used by blargg's NTSC filter engine, and anything not shown in the window is not saved to ntsc.ini. This means that there is no way to make the filter start up in the S-Video preset by default, since it differs from Composite only in some hidden setting which isn't saved. Could the configuration options be expanded for future releases of the filter?
-
- Interested
- Posts: 19
- Joined: Sat Jul 11, 2009 12:02 pm
i don't know if this glitch also appears on real hardware but it just looks wrong.
in the last dungeon in "Monster World IV" there are these graphical glitches in some screens:
it also appears on fusion 3.64. While the foreground is scrolling, this glitches stay fixed.
here's the rom + savestate
MOD EDIT:
Removed ROM link
in the last dungeon in "Monster World IV" there are these graphical glitches in some screens:
it also appears on fusion 3.64. While the foreground is scrolling, this glitches stay fixed.
here's the rom + savestate
MOD EDIT:
Removed ROM link