mamedev
Sega Model2(b) MIDI/Serial incorrect behavior
MAME version
0.254 (unknown) [SUSE OBS build]
System information
openSUSE Tumbleweed 20230621 x86-64, 32GB system RAM, MD Radeon RX 6750 XT (navi22, LLVM 16.0.6, DRM 3.52, 6.3.7-1-default) bgfx video output (vulkan backend)
INI configuration details
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
homepath $HOME/.mame
rompath $HOME/.mame/roms
hashpath $HOME/.mame/hash
samplepath $HOME/.mame/samples
artpath $HOME/.mame/artwork
ctrlrpath $HOME/.mame/ctrlr
inipath $HOME/.mame;.;ini
fontpath .
cheatpath $HOME/.mame/cheat
crosshairpath $HOME/.mame/crosshair
pluginspath $HOME/.mame/plugins
languagepath $HOME/.mame/language
swpath $HOME/.mame/software
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory $HOME/.mame/cfg
nvram_directory $HOME/.mame/nvram
input_directory $HOME/.mame/inp
state_directory $HOME/.mame/sta
snapshot_directory $HOME/.mame/snap
diff_directory $HOME/.mame/diff
comment_directory $HOME/.mame/comments
share_directory $HOME/.mame/share
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
rewind 0
rewind_capacity 100
playback
record
exit_after_playback 0
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview auto
snapbilinear 1
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
sleep 1
speed 1.0
refreshspeed 0
lowlatency 0
#
# CORE RENDER OPTIONS
#
keepaspect 1
unevenstretch 1
unevenstretchx 0
unevenstretchy 0
autostretchxy 0
intoverscan 0
intscalex 0
intscaley 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 0
fallback_artwork
override_artwork
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none
#
# CORE VECTOR OPTIONS
#
beam_width_min 1.0
beam_width_max 1.0
beam_dot_size 1.0
beam_intensity_weight 0
flicker 0
#
# CORE SOUND OPTIONS
#
samplerate 48000
samples 1
volume 0
compressor 1
speaker_report 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
verbose 1
log 0
oslog 0
debug 0
update_in_pause 0
debugscript
debuglog 0
#
# CORE COMM OPTIONS
#
comm_localhost 0.0.0.0
comm_localport 15112
comm_remotehost 127.0.0.1
comm_remoteport 15112
comm_framesync 0
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
drc_log_uml 0
drc_log_native 0
bios
cheat 1
skip_gameinfo 0
uifont default
ui cabinet
ramsize
confirm_quit 0
ui_mouse 1
language
nvram_save 1
#
# SCRIPTING OPTIONS
#
autoboot_command
autoboot_delay 0
autoboot_script
console 0
plugins 1
plugin
noplugin
#
# HTTP SERVER OPTIONS
#
http 0
http_port 8080
http_root web
#
# OSD KEYBOARD MAPPING OPTIONS
#
uimodekey auto
#
# OSD FONT OPTIONS
#
uifontprovider auto
#
# OSD OUTPUT OPTIONS
#
output auto
#
# OSD INPUT OPTIONS
#
keyboardprovider auto
mouseprovider auto
lightgunprovider auto
joystickprovider auto
#
# OSD DEBUGGING OPTIONS
#
debugger auto
debugger_port 23946
debugger_font auto
debugger_font_size 0
watchdog 0
#
# OSD PERFORMANCE OPTIONS
#
numprocessors auto
bench 0
#
# OSD VIDEO OPTIONS
#
video bgfx
numscreens 1
window 1
maximize 0
waitvsync 0
syncrefresh 0
monitorprovider auto
#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# OSD FULL SCREEN OPTIONS
#
switchres 0
#
# OSD ACCELERATED VIDEO OPTIONS
#
filter 1
prescale 1
#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 0
gl_glsl_filter 1
glsl_shader_mame0 none
glsl_shader_mame1 none
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
#
# OSD SOUND OPTIONS
#
sound auto
audio_latency 2
#
# PORTAUDIO OPTIONS
#
pa_api none
pa_device none
pa_latency 0
#
# BGFX POST-PROCESSING OPTIONS
#
bgfx_path $HOME/.mame/bgfx
bgfx_backend auto
bgfx_debug 0
bgfx_screen_chains default
bgfx_shadow_mask slot-mask.png
bgfx_lut lut-default.png
bgfx_avi_name auto
Emulated system/software
Sega's Model2b (model2) - Sonic the Fighters (sfight) [Possibly the entire Model2,2A,2B,2C library]
Incorrect behaviour
The MIDI (0x9C0000) and Serial (0x1C80000) do not accurately represent what is going on with the hardware. In Sonic the Fighters, both ports are initialized to 0x00850000 and at some point become 0x00840000. I say at "some point" because setting watchpoints on these values only hit when the game tries to write to these values and not when MAME changes these RAM values. When game execution writes to these values, the memory viewer shows no change to the data. This could be because the i960 IRQ_ENABLE and IRQ_REQUEST data is not setup properly in the game to actually allow these interrupts to write this data but I am not confident in that assumption. What concrete evidence I do have is a screenshot of the running game where a custom subroutine has been injected into the main loop of the game's execution. This subroutine utilizes built in debugging features which displays up to 4 bytes of data for a given address space. Here I am using the MIDI and Serial addresses and the game is reflecting identically what the memory viewer displays:
Expected behaviour
On real hardware with these same debugging routines, it is shown MIDI has all bits clear and Serial has all bits set.
These values may be different at different points in the game's execution, but because both MAME and real hardware are executing this display routine at the same time, there is a discrepancy. I understand the documentation on all this is extremely sparse, but would like to work with the MAME team in researching on how to best implement a more hardware accurate implementation of the serial protocol for the model2 machine.
Steps to reproduce
- Starting any game with
model2as the machine in debug - Open two memory viewing windows to
0x9C0000and0x1C80000 - Set two watchpoints in the debugger
wpset 0x9C0000,4,wandwpset 0x1C80000,4,w` - Begin game execution and observe
Additional details
No response
Since you apparently have a lot of insider knowledge about the hardware, would you mind sharing some of it? Like what the registers actually are at those locations? They look like an 8251 derivative but that covers a lot of ground.
I wouldn't say "insider knowledge" and I am not trying to come off as being arrogant but merely reporting my findings. I only have the ability to poke inside the machine from modified program data in line with dissembled and reassembled code in the format of burned ROMs. That being said, the research I am trying to do on hardware is conflicting with what I am seeing in MAME so I am just trying to point out an observation that there is a discrepancy in emulation. Again, this is not a "wow your implementation is bad and wrong" post but an attempt to see if we can work together to better the emulation. I'd like to believe we're all on the same team here.
That said, I can not at a hardware level tell you what registers are at those locations. The current assumption are the SCSP is generating the serial communication for both. Tracing the connector used for serial communication, leads to a SN75179B chip, which takes the signal from the 315-5649 chip and splits the 5V TTL to RX+/TX+ and RX-/TX- signals.
If the information I've provided here is just worthless, we can go ahead and close the issue now.
Actually going to close this. I have nothing to bring to the table here.
Chapter 6 of Model 2B documentation talks about serial 82c51 comms, which iirc connects to the MIDI port to the other end. Also last time I tried vstriker and eca (Model 3) had problems with comms, losing sound control. Reopening because has been acknowledged in source anyway.
https://github.com/mamedev/mame/blob/4cba9c1b6d39ea2677f9e5617894c7714f631fb5/src/mame/sega/model2.cpp#L971
https://mametesters.org/view.php?id=7429 related.
Oh? How? That issue was resolved in 0.253 with the m68000 rework. Ironically it was a m68000 rework which caused the regression.
EDIT: Oh I do think you're right. The sound code is passed via this protocol!
I have come back to share more of my "insider knowledge". Modifying a ROM to send sound codes to the serial address instead of MIDI allow sound to play in MAME. This does not work on real hardware and there is no audio nor do the subcpu lights change per sound played. The only bytes needed to change for this to occur are at 0x3F1BA. Changing from 9C 00 to C8 01.
EDIT: I forgot to specify this was for the sfight maincpu romset.
I'd like to request clarification on something: Are the address lines MAME defines as both "Serial" and "MIDI" address/communication lines to the subcpu/scsp, or are they supposed to be designated port address lines? The I/O board for the Model2b/c designates CN2 as an RS422 port and CN4 as a MIDI port. Have I been misinterpreting this nomenclature this whole time?
There's no I/O board on Model 2a/b/c. It's built into the main board.
I meant the "FIlter" board. It is still the input/output handler of the unit unless you are somehow connecting your inputs and power directly to the backplane connectors bypassing the filter caps.
The RS422 connector is populated but is not actually connected to anything.
This is simply not true. CN2 is connected to an SN75179BP chip on the main board which gets 5V TTL from the Sega 315-5649 I/O Controller. I have already gotten serial communication out of my Model2b board.
For additional verification try Elsemi's Model 2 emulator which AFAIK runs all the games pretty much perfectly
The emulator is far from perfect and handles some things such as basic timings incorrectly. It also keeps all dip switch values on at all times.
Elsemi's Model 2 emulator is just a suggestion for further testing. It is proven to run all the games well. I never said anything about accuracy.
- nobody will compile that in 2024, iirc it's MVSC 2005 or thereabouts;
- the source is full of discrepancies and it doesn't even pretend to emulate the MIDI SCSP (given it's basically an older MAME core).
- there's a Model 2B documentation but it doesn't go in great details about how it practically do some things (namely this and the gamma ramps).
This isn't dissing but just non-opinionated facts.
The CONNECTOR plugs into nothing on the outside world so even if the main board sends something to that connector the signal goes nowhere.
I don't think you understand that games like House of the Dead use the serial port?
Elsemi's Model 2 emulator is just a suggestion for further testing. It is proven to run all the games well. I never said anything about accuracy.
Okay, well here is a screenshot of the Mode2 emulator running inaccurately, giving bad test results:
The dip switches are all off because none of the dip switches are used in any Model 2 game and should be all set to off by default for standard game play.
You have misread what I posted. "It also keeps all dip switch values on at all times.", the DIP switches are all on at all times in ElSemi's emulator. I can only assume this was done at the time because one game (I think it was Zero Gunner?) added more options in the service menu when the DIPs were activated.
You seem to forget that Elsemi's emulator is not MAME and shouldn't be compared to it.
Then why are you mentioning it in a MAME issue?
Elsemi's emulator was done 15 years ago
The last update was January 2nd, 2014, which was 10 years ago, and Nebula Model2 started work more than 20 years ago. I don't know where you are pulling your information.
You really missed the point. It was simply a suggestion for another test case
If you didn't think I tried this on ElSemi's emulator I would not be doing thorough research. The serial test also fails on Sega's official Model2 emulator. You are missing the point here, we are trying to emulate hardware accurately, not "make something to run a game with all the perceivable behaviors it exhibits", and that's where MAME differs from ElSemi's emulator greatly.
FYI House Of The Dead uses a separate gun i/O board that is currently not emulated.
You are correct and I assume that's about as close as I'm going to get for you to admit you are wrong. If you have nothing to contribute to this issue except incorrect information, please ignore it and move on.
Chapter 6 of Model 2B documentation talks about serial 82c51 comms, which iirc connects to the MIDI port to the other end. Also last time I tried vstriker and eca (Model 3) had problems with comms, losing sound control. Reopening because has been acknowledged in source anyway.
https://github.com/mamedev/mame/blob/4cba9c1b6d39ea2677f9e5617894c7714f631fb5/src/mame/sega/model2.cpp#L971
Do you have a link to that documentation @angelosa? Couldn't find it.
