Regen 0.972 and 0.972D

[Shadow]

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:

[motke]

Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?

[Shiru]

This russian guy is the same, whose post is just before yours.

[Eke]

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:

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".

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.

[AamirM]

Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?

No.

[Shadow]

I found new bug:

Game for SMS - Super Tetris after "press start" cause Regen to crash...

[dtech]

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

[Gigasoft]

May I also suggest stepping and breakpoints for Z80?

And selection and editing in memory viewer using the mouse and keyboard (instead of the current approach which reminds me of old computers that were programmed with switchboards, setting the address and data and flipping the "set" switch).

[TascoDLX]

when sprite layer is disabled, mickey's foot is still visible and animating around (how come?)

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.

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).

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

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)

Pretty basic multitasking. It's using RTE for the switch into user mode then using TRAP #0 for the switch back.

Dumb game bug, though. It could've been avoided with just one line of code.

[Shadow]

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.

Yes i noticed it on my real thing, games contains alot of hidden bugs which happen on real things...

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.

[Eke]

Pretty basic multitasking. It's using RTE for the switch into user mode then using TRAP #0 for the switch back.
.

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).

Dumb game bug, though. It could've been avoided with just one line of code.

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).

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

[eighty5cacao]

* 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.

Does disabling Autofix Checksum solve this?

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.

[TascoDLX]

Still it's rather strange that this is called during the main initialization (not the main loop)

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).

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).

It is modified. It's written back in the trap routine. Although, for that intro sequence, it tends to write back $0000 anyway.

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).

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.

[eighty5cacao]

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?

[Kettenhund]

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