Open biggestsonicfan opened 1 year ago
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.
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.
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.
Do you have a link to that documentation @angelosa? Couldn't find it.
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
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 to0x00850000
and at some point become0x00840000
. 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
model2
as the machine in debug0x9C0000
and0x1C80000
wpset 0x9C0000,4,w
andwpset 0x1C80000
,4,w`Additional details
No response