Forums

i don't know if more people here noticed it

most (or all) of the classic sms games runs fine on mame (sms emulation), but some from the homebrew here at smspower doesn't (like all of mine ones, for example - and wing warriors as well - but some of them runs fine) - but they all run fine on emulators like mednafen, gearsystem, etc. (i didn't test on all emulators yet, sorry)

and all of the game gear games, the classic ones as well as the homebrew ones, all runs fine, on mame and on other emulators

and about my homebrew ones, as i can remember asking for testing on sd cartridges on real sms hardware, they all seems to run fine

so, it seems weird why it seems to happen on mame only - and also it seems to be affecting on just one vdp register bit for switching between 4kb and 16kb ram mode (like on 9918), like bit 7 from register 1, but that is not affecting at all

what do you all think about?

Hi nitrofurano,

For SMS emulation, MAME has implementation of some models of SMS hardware, defined by the driver you choose, each model has unique behaviors, unlike most SMS emulators, that emulates a generic SMS with a switch for PAL/NTSC. For homebrew roms, there are some common problems:

1 - Lack of header signature, that is checked by non-japanese/korean BIOS.

2 - Lack of procedure to clean RAM before use, what could become a compatibility problem with the Japanese drivers (smsj and sg1000m3), that power up with RAM filled with $F0.

3 - The homebrew rom does some changes using an exotic timing that the VDP currently does not expect. I'm currently writing and doing tests on hardware to later improve the VDP implementation and hope it will behaves correctly when a rom uses a different timing.

I suggest you to try the problematic homebrew roms on the sg1000m3 driver (Sega Mark 3, no bios, RAM has $F0 pattern on startup) or on the smskr driver (korean sms2 clone, RAM has $00 pattern on startup, IIRC).

I know you uses the VDP text mode with some of your homebrew roms. I am aware of one bug with the text mode: in the file src/devices/video/315_5124.cpp, method sega315_5124_device::draw_scanline_mode1, change the multiplier in the calculation of name_row_base from 32 to 40 (text mode has 40 columns).

well, it is only affecting display mode 4, not the sg legacy display modes - and i tried on all the emulated sms variations available (sg1000m3, sms, smsj, etc.)

why the msb of the VDP register $1 is set?

probably because i thought that was triggering that (supposed?) bug on mame - but it's not because i changed it now and nothing changed... :S

so it is indeed a mystery for me why none of the classic mode-4 sms games shows that issue, most of the homebrew ones neither, and all of mine ones does... :O (and happening on mame only)

which other homebrew show the issue?

these are the values SMSlib uses to initialize the VDP:

const unsigned char VDPReg_init[11]={
0x04, /* reg0: Mode 4 */
0x20, /* reg1: display OFF - frame int (vblank) ON */
0xFF, /* reg2: PNT at 0x3800 */
0xFF, /* reg3: no effect (when in mode 4) */
0xFF, /* reg4: no effect (when in mode 4) */
0xFF, /* reg5: SAT at 0x3F00 */
0xFF, /* reg6: Sprite tiles at 0x2000 */
0x00, /* reg7: backdrop color (zero) */
0x00, /* reg8: scroll X (zero) */
0x00, /* reg9: scroll Y (zero) */
0xFF /* regA: line interrupt count (offscreen) */

$FF on reg 6?
I use $FB on my side

ichigobankai wrote

$FF on reg 6?
I use $FB on my side

that's fine if you want to use the first half of VRAM for sprites

sverx wrote

why the msb of the VDP register $1 is set?

On official Doc it's set to 1 by default and should be 1 (as few bits on reg 0) but i'm pretty sure you already know that ^^

PS. Why do you set frame int with/when screen is off?

ichigobankai wrote

sverx wrote

why the msb of the VDP register $1 is set?

On official Doc it's set to 1 by default and should be 1 (as few bits on reg 0) but i'm pretty sure you already know that ^^

it's probably one of the very few bits where it *really* doesn't matter

sverx wrote

which other homebrew show the issue?

Wing Warriors also shows the same issue
(i didn't test intensively yet, might be there more homebrew around too, with the same issue)

sverx wrote

const unsigned char VDPReg_init[11]={
0x04, /* reg0: Mode 4 */
0x20, /* reg1: display OFF - frame int (vblank) ON */
0xFF, /* reg2: PNT at 0x3800 */
0xFF, /* reg3: no effect (when in mode 4) */
0xFF, /* reg4: no effect (when in mode 4) */
0xFF, /* reg5: SAT at 0x3F00 */
0xFF, /* reg6: Sprite tiles at 0x2000 */
0x00, /* reg7: backdrop color (zero) */
0x00, /* reg8: scroll X (zero) */
0x00, /* reg9: scroll Y (zero) */
0xFF /* regA: line interrupt count (offscreen) */

i now rewrote one of the codes using this sequence, and using the values i used, and now it works - might it be some kind of "i/o synchronicity lag" only happening on mame?

and when i comment out (disable) lines affecting registers 3 and 4, that garbage appears again - so we always need to set these registers to 0xFF even iif it has "no effect" in theory, at least on mame? (i have no idea about what would happen on real hardware using a everdrive cartridge...)

and now i'm setting 0xFF in registers 3 and 4, and fixing everything on mame - "weird"... :O

and curious that sega-e emulation on mame doesn't need it... :O (isn't it supposed to sega-e arcade games (at mamedev sources) use the same display code from sms and so on, even considering that sega-e uses a dual-layered vdp? :O )

From Charles' VDP doc:

Quote

Register $03 - Color Table Base Address

D7 - No effect
D6 - No effect
D5 - No effect
D4 - No effect
D3 - No effect
D2 - No effect
D1 - No effect
D0 - No effect

For the SMS VDP only, all bits should be set. Otherwise the VDP will fetch pattern data and name table data incorrectly.

Register $04 - Background Pattern Generator Base Address

D7 - No effect
D6 - No effect
D5 - No effect
D4 - No effect
D3 - No effect
D2 - No effect
D1 - No effect
D0 - No effect

For the SMS VDP only, bits 2-0 should be set. Otherwise the VDP will fetch pattern data and name table data incorrectly.

I also think I should change the 'no effect' description to 'must be $FF' in my code too...

edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain...

Most emulators avoid emulating behaviour that is useless and unhelpful :) but more recently we try to emulate things that would happen on a real system. I suspect a lot of the trouble comes from my old tutorial code where I also didn’t try too hard to set the unused bits correctly.

sverx wrote

edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain...

MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3)

Is MAME still a thing? I gave up on it more than a decade ago, there's only so much "the ROM which worked perfectly fine until yesterday doesn't work in the new release anymore" that I can take, there were a few Neo-Geo games that I had to redownload like three times.

lidnariq wrote

sverx wrote

edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain...

MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3)

all of them behaved the same way on mame, about those $FF values on registers 3 and 4

Tom wrote

Is MAME still a thing?

for me it is for lots of reasons:
- scaling, offset and ratio flexibility (is really a must for me! indeed, i'd love seeing on other emulators such features as great as we can find on mame)
- sega-e emulation (which other emulators also emulates sega-e?)
- as i use to try to develop homebrew to almost all z80-based hardware (including arcade machines), mame emulates most of them (if not all of them), so it seems very relevant, so i can try everything in the same emulator in the same way
- etc.

Quote

I gave up on it more than a decade ago, there's only so much "the ROM which worked perfectly fine until yesterday doesn't work in the new release anymore" that I can take, there were a few Neo-Geo games that I had to redownload like three times.

yes, that's the worst part of mame, they are constantly renaming rom files inside the .zip ones (bios, games, etc. - specially bios, like on sms ones, also happened there) - a clue can be checking how these rom files inside these .zip files are named and rename them accordingly (as from mame error messages from terminal)

nitrofurano wrote

lidnariq wrote

sverx wrote

edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain...

MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3)

all of them behaved the same way on mame, about those $FF values on registers 3 and 4

MAME's sms driver emulates a Master System 2 NTSC console and sms, smspal, smsbr, smskr and smspaln drivers are all based on Master System 2 (renamed Master System 3 for smsbr, smspaln), with a 315-5246 VDP, instead of the 315-5124 VDP on sms1, sms1pal, smssdisp, smsj, sg1000m3, sms1kr, sms1krfm, sms1br, sms2br, sms1paln and sms2paln drivers.

The oddly behaviours of registers 02, 03 and 04 are implemented only for the 315-5124 VDP. I was the one that tested and implemented the changes for proper register 03 and 04 emulation, based on real hardware behavior checked with UnusedBitCheckerr, by psidum, and Enri's VDP R#03 Test Program. The commit that applied the changes in MAME is the one pointed by the following URL:

https://github.com/mamedev/mame/commit/9ed7b0967105d5a46201786c570f7dd38947f7f0[/url]

nitrofurano wrote

all of them behaved the same way on mame, about those $FF values on registers 3 and 4

so the issue after all was that you didn't set an value to those two VDP registers and assumed they were set to $FF already?

enik2 wrote

The oddly behaviours of registers 02, 03 and 04 are implemented only for the 315-5124 VDP. I was the one that tested and implemented the changes for proper register 03 and 04 emulation, based on real hardware behavior checked with UnusedBitCheckerr, by psidum, and Enri's VDP R#03 Test Program.

Wonderful, thanks for the heads up! :)

I think it’s safe to assume that on an emulator with a BIOS, the registers will be set to sensible values. On one without, the defaults still ought to be valid. The only danger should be if you actively set them to invalid values which older emulators then ignore.

Author	Message
nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	mysterious mame bug... Posted: Sun Aug 20, 2023 10:57 pm
	i don't know if more people here noticed it most (or all) of the classic sms games runs fine on mame (sms emulation), but some from the homebrew here at smspower doesn't (like all of mine ones, for example - and wing warriors as well - but some of them runs fine) - but they all run fine on emulators like mednafen, gearsystem, etc. (i didn't test on all emulators yet, sorry) and all of the game gear games, the classic ones as well as the homebrew ones, all runs fine, on mame and on other emulators and about my homebrew ones, as i can remember asking for testing on sd cartridges on real sms hardware, they all seems to run fine so, it seems weird why it seems to happen on mame only - and also it seems to be affecting on just one vdp register bit for switching between 4kb and 16kb ram mode (like on 9918), like bit 7 from register 1, but that is not affecting at all what do you all think about?

enik2 Joined: 07 Nov 2016 Posts: 11	Posted: Mon Aug 21, 2023 5:48 am
enik2 Joined: 07 Nov 2016 Posts: 11	Hi nitrofurano, For SMS emulation, MAME has implementation of some models of SMS hardware, defined by the driver you choose, each model has unique behaviors, unlike most SMS emulators, that emulates a generic SMS with a switch for PAL/NTSC. For homebrew roms, there are some common problems: 1 - Lack of header signature, that is checked by non-japanese/korean BIOS. 2 - Lack of procedure to clean RAM before use, what could become a compatibility problem with the Japanese drivers (smsj and sg1000m3), that power up with RAM filled with $F0. 3 - The homebrew rom does some changes using an exotic timing that the VDP currently does not expect. I'm currently writing and doing tests on hardware to later improve the VDP implementation and hope it will behaves correctly when a rom uses a different timing. I suggest you to try the problematic homebrew roms on the sg1000m3 driver (Sega Mark 3, no bios, RAM has $F0 pattern on startup) or on the smskr driver (korean sms2 clone, RAM has $00 pattern on startup, IIRC). I know you uses the VDP text mode with some of your homebrew roms. I am aware of one bug with the text mode: in the file src/devices/video/315_5124.cpp, method sega315_5124_device::draw_scanline_mode1, change the multiplier in the calculation of name_row_base from 32 to 40 (text mode has 40 columns).

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Tue Aug 22, 2023 11:08 am
	well, it is only affecting display mode 4, not the sg legacy display modes - and i tried on all the emulated sms variations available (sg1000m3, sms, smsj, etc.)

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Tue Aug 22, 2023 11:22 am


sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Aug 22, 2023 2:16 pm
	why the msb of the VDP register $1 is set?

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Tue Aug 22, 2023 6:14 pm
	probably because i thought that was triggering that (supposed?) bug on mame - but it's not because i changed it now and nothing changed... :S so it is indeed a mystery for me why none of the classic mode-4 sms games shows that issue, most of the homebrew ones neither, and all of mine ones does... :O (and happening on mame only)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Aug 23, 2023 8:54 am
	which other homebrew show the issue? these are the values SMSlib uses to initialize the VDP: const unsigned char VDPReg_init[11]={ 0x04, /* reg0: Mode 4 / 0x20, / reg1: display OFF - frame int (vblank) ON / 0xFF, / reg2: PNT at 0x3800 / 0xFF, / reg3: no effect (when in mode 4) / 0xFF, / reg4: no effect (when in mode 4) / 0xFF, / reg5: SAT at 0x3F00 / 0xFF, / reg6: Sprite tiles at 0x2000 / 0x00, / reg7: backdrop color (zero) / 0x00, / reg8: scroll X (zero) / 0x00, / reg9: scroll Y (zero) / 0xFF / regA: line interrupt count (offscreen) */

ichigobankai Joined: 04 Jul 2010 Posts: 542 Location: Angers, France	Posted: Wed Aug 23, 2023 1:02 pm
	$FF on reg 6? I use $FB on my side

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Aug 23, 2023 1:48 pm
	ichigobankai wrote $FF on reg 6? I use $FB on my side that's fine if you want to use the first half of VRAM for sprites

ichigobankai Joined: 04 Jul 2010 Posts: 542 Location: Angers, France	Posted: Wed Aug 23, 2023 2:31 pm
	sverx wrote why the msb of the VDP register $1 is set? On official Doc it's set to 1 by default and should be 1 (as few bits on reg 0) but i'm pretty sure you already know that ^^ PS. Why do you set frame int with/when screen is off?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Aug 23, 2023 3:20 pm
	ichigobankai wrote sverx wrote why the msb of the VDP register $1 is set? On official Doc it's set to 1 by default and should be 1 (as few bits on reg 0) but i'm pretty sure you already know that ^^ it's probably one of the very few bits where it really doesn't matter

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Aug 23, 2023 4:31 pm
	sverx wrote which other homebrew show the issue? Wing Warriors also shows the same issue (i didn't test intensively yet, might be there more homebrew around too, with the same issue)

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Aug 23, 2023 6:04 pm
	sverx wrote const unsigned char VDPReg_init[11]={ 0x04, /* reg0: Mode 4 / 0x20, / reg1: display OFF - frame int (vblank) ON / 0xFF, / reg2: PNT at 0x3800 / 0xFF, / reg3: no effect (when in mode 4) / 0xFF, / reg4: no effect (when in mode 4) / 0xFF, / reg5: SAT at 0x3F00 / 0xFF, / reg6: Sprite tiles at 0x2000 / 0x00, / reg7: backdrop color (zero) / 0x00, / reg8: scroll X (zero) / 0x00, / reg9: scroll Y (zero) / 0xFF / regA: line interrupt count (offscreen) */ i now rewrote one of the codes using this sequence, and using the values i used, and now it works - might it be some kind of "i/o synchronicity lag" only happening on mame?

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Aug 23, 2023 6:12 pm
	and when i comment out (disable) lines affecting registers 3 and 4, that garbage appears again - so we always need to set these registers to 0xFF even iif it has "no effect" in theory, at least on mame? (i have no idea about what would happen on real hardware using a everdrive cartridge...)

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Aug 23, 2023 6:24 pm
	and now i'm setting 0xFF in registers 3 and 4, and fixing everything on mame - "weird"... :O

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Aug 23, 2023 6:52 pm Last edited by nitrofurano on Thu Aug 24, 2023 3:40 pm; edited 1 time in total
	and curious that sega-e emulation on mame doesn't need it... :O (isn't it supposed to sega-e arcade games (at mamedev sources) use the same display code from sms and so on, even considering that sega-e uses a dual-layered vdp? :O )

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Aug 24, 2023 9:18 am
	From Charles' VDP doc: Quote Register $03 - Color Table Base Address D7 - No effect D6 - No effect D5 - No effect D4 - No effect D3 - No effect D2 - No effect D1 - No effect D0 - No effect For the SMS VDP only, all bits should be set. Otherwise the VDP will fetch pattern data and name table data incorrectly. Register $04 - Background Pattern Generator Base Address D7 - No effect D6 - No effect D5 - No effect D4 - No effect D3 - No effect D2 - No effect D1 - No effect D0 - No effect For the SMS VDP only, bits 2-0 should be set. Otherwise the VDP will fetch pattern data and name table data incorrectly. I also think I should change the 'no effect' description to 'must be $FF' in my code too... edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Aug 24, 2023 11:08 am
	Most emulators avoid emulating behaviour that is useless and unhelpful :) but more recently we try to emulate things that would happen on a real system. I suspect a lot of the trouble comes from my old tutorial code where I also didn’t try too hard to set the unused bits correctly.

lidnariq Joined: 24 Mar 2021 Posts: 120	Posted: Thu Aug 24, 2023 5:39 pm
lidnariq Joined: 24 Mar 2021 Posts: 120	sverx wrote edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain... MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3)

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Fri Aug 25, 2023 6:09 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Is MAME still a thing? I gave up on it more than a decade ago, there's only so much "the ROM which worked perfectly fine until yesterday doesn't work in the new release anymore" that I can take, there were a few Neo-Geo games that I had to redownload like three times.

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Fri Aug 25, 2023 7:49 pm Last edited by nitrofurano on Fri Aug 25, 2023 8:02 pm; edited 1 time in total
	lidnariq wrote sverx wrote edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain... MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3) all of them behaved the same way on mame, about those $FF values on registers 3 and 4

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Fri Aug 25, 2023 7:55 pm
	Tom wrote Is MAME still a thing? for me it is for lots of reasons: - scaling, offset and ratio flexibility (is really a must for me! indeed, i'd love seeing on other emulators such features as great as we can find on mame) - sega-e emulation (which other emulators also emulates sega-e?) - as i use to try to develop homebrew to almost all z80-based hardware (including arcade machines), mame emulates most of them (if not all of them), so it seems very relevant, so i can try everything in the same emulator in the same way - etc. Quote I gave up on it more than a decade ago, there's only so much "the ROM which worked perfectly fine until yesterday doesn't work in the new release anymore" that I can take, there were a few Neo-Geo games that I had to redownload like three times. yes, that's the worst part of mame, they are constantly renaming rom files inside the .zip ones (bios, games, etc. - specially bios, like on sms ones, also happened there) - a clue can be checking how these rom files inside these .zip files are named and rename them accordingly (as from mame error messages from terminal)

enik2 Joined: 07 Nov 2016 Posts: 11	Posted: Mon Aug 28, 2023 4:28 am
enik2 Joined: 07 Nov 2016 Posts: 11	nitrofurano wrote lidnariq wrote sverx wrote edit: maybe MAME emulates the first revision VDP while the other emulators emulate the newer one? That would explain... MAME emulates different versions of the VDP depending on which "sms" you ask it to run. (sms1, smsj, sms, sg1000m3) all of them behaved the same way on mame, about those $FF values on registers 3 and 4 MAME's sms driver emulates a Master System 2 NTSC console and sms, smspal, smsbr, smskr and smspaln drivers are all based on Master System 2 (renamed Master System 3 for smsbr, smspaln), with a 315-5246 VDP, instead of the 315-5124 VDP on sms1, sms1pal, smssdisp, smsj, sg1000m3, sms1kr, sms1krfm, sms1br, sms2br, sms1paln and sms2paln drivers. The oddly behaviours of registers 02, 03 and 04 are implemented only for the 315-5124 VDP. I was the one that tested and implemented the changes for proper register 03 and 04 emulation, based on real hardware behavior checked with UnusedBitCheckerr, by psidum, and Enri's VDP R#03 Test Program. The commit that applied the changes in MAME is the one pointed by the following URL: https://github.com/mamedev/mame/commit/9ed7b0967105d5a46201786c570f7dd38947f7f0[/url]

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Aug 28, 2023 9:39 am
	nitrofurano wrote all of them behaved the same way on mame, about those $FF values on registers 3 and 4 so the issue after all was that you didn't set an value to those two VDP registers and assumed they were set to $FF already?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Aug 28, 2023 9:40 am
	enik2 wrote The oddly behaviours of registers 02, 03 and 04 are implemented only for the 315-5124 VDP. I was the one that tested and implemented the changes for proper register 03 and 04 emulation, based on real hardware behavior checked with UnusedBitCheckerr, by psidum, and Enri's VDP R#03 Test Program. Wonderful, thanks for the heads up! :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Aug 28, 2023 12:26 pm
	I think it’s safe to assume that on an emulator with a BIOS, the registers will be set to sensible values. On one without, the defaults still ought to be valid. The only danger should be if you actively set them to invalid values which older emulators then ignore.

Forums

View topic - mysterious mame bug...