Page 12 of 13

Posted: Tue Mar 23, 2010 12:18 am
by 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:

Image

Posted: Fri Apr 02, 2010 12:06 pm
by motke
Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?

Posted: Fri Apr 02, 2010 4:12 pm
by Shiru
This russian guy is the same, whose post is just before yours.

Posted: Fri Apr 02, 2010 4:24 pm
by Eke
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:

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

Posted: Sat Apr 03, 2010 6:18 pm
by AamirM
motke wrote:Hmm, this Russian guy is saying that Regen extensively uses Gens' GPL'd source code (see the spoiler). Is he correct?
No.

Posted: Tue Apr 06, 2010 2:03 pm
by Shadow
I found new bug:

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

Posted: Wed Apr 07, 2010 2:43 am
by 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

Posted: Wed Apr 07, 2010 4:10 am
by 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).

Posted: Wed Apr 07, 2010 7:02 am
by TascoDLX
dtech wrote: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.
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).

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.

Posted: Wed Apr 07, 2010 7:40 am
by Shadow
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.
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.

Posted: Wed Apr 07, 2010 8:45 am
by Eke
TascoDLX wrote: 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 :?

Posted: Wed Apr 07, 2010 11:14 pm
by eighty5cacao
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.
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.

Posted: Thu Apr 08, 2010 12:53 pm
by TascoDLX
Eke wrote: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).
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).
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: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.

Posted: Mon Apr 26, 2010 8:17 am
by 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?

Posted: Mon May 03, 2010 5:25 pm
by 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:

Image

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