The big win: Got hands on a WingWar twin in rather good condition for free. The problem: The unit's foot was submerged underwater for at least half a year.
The boardset, as well as power supply, amps etc. in the bottom are completely ruined.
Luckily the monitors AND the transformer still work. I've managed to hook the whole cab up to a PC using an A-PAC and a PAC-DRIVE. Some cheap car amp powers the speakers and the sub. I even hooked up the LEDs in MAME itself, which wasn't a big deal in the end.
Sadly, WingWar is rather boring while playing versus the CPU. So I am trying to emulate the comm board.
So far I dumped the ROM on the board (also took some steps into z80 disassembly) and fooled around with MAME itself. (blue screen - yahoo!)
Actually I don't really have a clue where to start right now. I can't dump the GAL/PAL on the comm board, and I don't have a working model 1 set to run trojans on.
I suppose someone with enough patience could hack up a rather simple emulation based on the v60 assembly. Sadly, that person is not me
Getting the two MAME instances to actually communicate with each other is yet another problem for some future point.
So the actual question is - Is there actualy anything I can do?
Sadly, multi-cabinet network emulation is not implemented yet in MAME. But you might have done something that could make multi-cab network emulation a reality.
> Hi folks. > > I am in some bittersweet situation right now. > > The big win: Got hands on a WingWar twin in rather good condition for free. > The problem: The unit's foot was submerged underwater for at least half a year. > > The boardset, as well as power supply, amps etc. in the bottom are completely ruined. > > Luckily the monitors AND the transformer still work. I've managed to hook the whole > cab up to a PC using an A-PAC and a PAC-DRIVE. Some cheap car amp powers the speakers > and the sub. I even hooked up the LEDs in MAME itself, which wasn't a big deal in the > end. > > Sadly, WingWar is rather boring while playing versus the CPU. > So I am trying to emulate the comm board. > > So far I dumped the ROM on the board (also took some steps into z80 disassembly) and > fooled around with MAME itself. (blue screen - yahoo!) > > Actually I don't really have a clue where to start right now. > I can't dump the GAL/PAL on the comm board, and I don't have a working model 1 set to > run trojans on. >
I'm not sure the wingwar comm board is actually dumped AT ALL in MAME right now. If you don't have the means of dumping it and the pal yourself, is there a chance you could lend the board out to someone who can?
Also check the main board to see if it has a different rom revision to the ones in MAME...
LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
If model 1 is anything like model 2 then comms may not work too well anyway as it expects 0 latency between transmitting/receiving packets which it seems is near impossible over a PC network. I tried it with model 2 emu with pretty poor results.
That said I have a feeling this was down to the refresh being borked in m2emu v1.0. Actually more the audio running too fast at 60hz while the main CPU runs at 57.5 or there abouts. I had no sound skipping so I've no doubt the CPU was skipping causing sync issues. I've not had a chance to test that theory yet. Seems the audio system in v1.0 is pretty broken in lots of ways actually.
Back to model 1 though, is the network board at all similar to model 2? I believe someone in MAMEdev had ElSemi's source to improve MAME's driver though I'd imagine the network code wasn't suitable for MAME anyway.
Did MESS gain network capabilities yet? I remember hearing that'd pave the way for similar things in MAME at some point.
Quote: I even hooked up the LEDs in MAME itself, which wasn't a big deal in the end.
Anything committable? It'd be great to see lamp outputs in Virtua Racing etc.
> If model 1 is anything like model 2 then comms may not work too well anyway as it > expects 0 latency between transmitting/receiving packets which it seems is near > impossible over a PC network. I tried it with model 2 emu with pretty poor results.
Well, m2emu works fine enough with up to 4 fast PCs and Gigabit Ethernet. Without FrameSync (i guess that's default anyway) Daytona and SegaRally work fine with 3 Units. With FrameSync enabled i got a stable link between 4 units working (more may be possible though).
"FrameSync=1" in m2network.ini does the trick. Most noticable if you kill the Master Unit - The slaves freeze.
On the Model1 Front: I guess the Model1 Comm-Board is pretty close to the original Model2 one, with only a smaller memory window. (2K/4K @ 0x00b00000 in Model1 - 32/64K @ 0x01a10000 in Model2) Also the "unknown daytona read" at 0x01c00040 (Model2) looks amazing similar to the "network ctrl" at 0x00c00040 (Model1).
Using M2emus LUA scripts, I read (and via cheat menu wrote) from/to the network boards memory and got a pretty good idea on how the board is accessed from M2 side. Then I tinkered around in MAME and can get Daytona and Sega Rally to actually think they are connected to a certain number of nodes (1 Player Link System... They even did Graphics for that!).
Then again, I've startet debuging Virtua Racing (and WingWar), and noticed a lot of unmapped memory accesses to 0x00b00000 which I believe is a 4K shared memory window for/on the network board. Also there seems to be some kind of register space at 0x00c00100 though I have yet to confirm these actually belong to the network board. I can get Virtua Racing/Formula up and waiting for communications opposed to crashing "network board not found". And I can get them ingame thinking they are linked up.
I am far from "emulating" anything though. I got several ideas on what and how it does.
Code:
offs mask data comments network_w: 0000 ff00 0100 - set "master" (0000 = relay, 0100 = master, 0200 = slave) network_w: 0800 00ff 0000 - disable linking network_w: 0000 00ff 0005 - ? network_w: 0800 00ff 0001 - enable linking network_r: 0000 00ff - check status network_r: 0001 ff00 - check total nodes network_r: 0001 00ff - check my id
> Anything committable? It'd be great to see lamp outputs in Virtua Racing etc. I've commited lamp outputs for "all other games" a while ago. Virtua Racing seems to work in a different way. The IO port is the same but the lamps are getting transmitted in blocks of like 16 bytes each XORed together get you the actual output. I have yet to find a reliable logic for that. Got two, first one works "ingame", second one works in "attract". But not both
And of course... Some pretty screenshots!
Sega Rally actually takes everything up to 15 nodes.
Virtua Racing/Formula get into attract mode, can be coined up, but keep wainting for challengers forever
WingWar at least detects the board and gets happy if I fake a link.
> Well, m2emu works fine enough with up to 4 fast PCs and Gigabit Ethernet. > Without FrameSync (i guess that's default anyway) Daytona and SegaRally work fine > with 3 Units. > With FrameSync enabled i got a stable link between 4 units working (more may be > possible though). > > "FrameSync=1" in m2network.ini does the trick. Most noticable if you kill the Master > Unit - The slaves freeze.
I had no idea there was a framesync option, I certainly didn't see it in the ini anyway. I guess that would sort that out then, Daytona/Rally worked but were pretty choppy
> I've commited lamp outputs for "all other games" a while ago. > Virtua Racing seems to work in a different way. The IO port is the same but the lamps > are getting transmitted in blocks of like 16 bytes each XORed together get you the > actual output. > I have yet to find a reliable logic for that. Got two, first one works "ingame", > second one works in "attract". But not both
This actually doesn't surprise me at all. Every model 2 game uses a single byte for lamps and that's it, yet Daytona seems to behave the same way you describe here, output values look fine in the test menu but fall silent ingame. I actually can't find any values ingame that look useful for that but then I'm probably looking for the wrong thing. XOR tables are a little beyond me. I'd assume this means Daytona's network would work at least in a very similar if not identical way to VR/Wing War though. What address are these outputs at for VR? Might help me figure out the outputs for Daytona.
I'll be following this with keen interest. It seems something cool is around the corner
If MAME doesn't have anything in place to allow network I/O maybe a helper app similar to MAME hooker could help out until it does?
> What address are these outputs at for VR? Model1 lamp data gets written to 0xC0000F
> I'll be following this with keen interest. It seems something cool is around the corner. Don't get to excited though. Most of this is to be considered a "dirty hack" at best.
I've managed to get the Model2/2A (non B, C) comm board basically working in MAME. Daytona and Sega Rally link up to itself and show a stable (haha) one player link system. I have yet to find out what "clocks" the comm board though. The other Model2A Games (ManxTT and MotoRaid don't like a 1 player linkup, and crash if the seconds unit doesn't communicate)
Currently I use writes to 0x01c00040 on Model2 to "tick" the network board. Most writes are 0x01 and I guess these to be ticks. Sometimes there is a 0x00 and a 0x03 writen here, but that only happends after changing comm settings in daytonas service menu.
On Model2A I use writes to 0x01c00010 to "tick" the network board, but that most likely is totaly wrong. (call it a dirty hack)
Each tick move the blocks in NETWORK SHARED memory up 448 bytes. Have yet to test how that look on two or three units.
Memory Map described (as far as i understand it) 0x01a10000 - 0x01a13FFF seems to be standard shared ram 0x01a14000 - 0x01a17FFF seems to be used to READ status and WRITE commands, also seems to repeat itself ever 4 bytes
That shared ram seems to be further split 0x01a10000 - 0x01a1001F seems to contain "link specific" data FOR THE LOCAL SYSTEM like number of nodes etc. 0x01a12000 - 0x01a12fbf seems to be the real NETWORK SHARED memory (9 blocks of 448 bytes each)
Detailed:
Code:
0x01a10000 - 0x01a1001F 0000: 00 xx FF FF xx xx xx xx xx xx xx xx xx xx xx xx - Link "offline", searching for nodes... 0000: 01 xx 01 01 xx xx xx xx xx xx xx xx xx xx xx xx - Link "online", myself = 1, total nodes = 1 0000: 01 xx 01 02 xx xx xx xx xx xx xx xx xx xx xx xx - Link "online", myself = 1, total nodes = 2
0010: xx xx 00 0E C0 01 xx xx xx xx xx xx xx xx xx xx - as soon as the board gets "initialized" it writes 00 0E C0 01 to the shared memory that doesn't get read by daytona and srallyc though.
Code:
READING from 0x01a14000 - 0x01a1400F 0000: xx FF xx FF ... odd bytes always read 0xFF
0000: 01 xx x1 xx ... comm board enabled 0000: 00 xx x0 xx ... comm board disabled
0000: 01 xx 81 xx ... comm board enabled, after tick 1... 0000: 01 xx 01 xx ... comm board enabled, after tick 2... 0000: 01 xx 81 xx ... comm board enabled, after tick 3... 0000: 01 xx 01 xx ... comm board enabled, after tick 4...
Code:
WRITING to 0x01a14000 - 0x01a1400F 0000: 00 xx xx xx ... reset/disable 0000: 01 xx xx xx ... init/enable
0000: xx xx 00 xx ... set slave mode 0000: xx xx 01 xx ... set master mode
> > I'll be following this with keen interest. It seems something cool is around the > corner. > Don't get to excited though. Most of this is to be considered a "dirty hack" at best.
Nevermind...
I can coin up, select a course, course gets accepted, I can drive. Works like a charm.
WingWar refuses to run on its own ( neither in 1ply nor 2ply link ) Virtua Formula hasn't been tested "indeep" yet. But I've seen the left and right half of the attract mode.
Anyway, are you going to try a LAN Emulation like Elsemi did with his M2emu? BTW, does it work with any other games like Namco racing games and System 32 with Rad Rally?
> Anyway, are you going to try a LAN Emulation like Elsemi did with his M2emu? BTW, > does it work with any other games like Namco racing games and System 32 with Rad > Rally?
Main goal for now will be a "real" link up procedure and more than 2 players. (and possible fix relay mode by the way).
As for other Hardware, well, I don't know in detail how other systems communicate, but it may be possible.
Now that I got that model1 comm board partialy working (WingWar still doesn't work ) I'll focus on bugfixing and documentating. Also, please not that I still don't run the "real" comm board ROM, I'm just interpreting the shared memory.
Okay, I have a non-racing game tidbit for Network Emulation:
The name of unused data collector named Felineki hacked the game to unlock the Tournament Battle mode in SSF2T, so I believe u can emulate this net feature on this hardware just to show that linked up battles in Turbo would function like you've never seen before.
BTW sailor, can you show me the "Waiting for your Entry" Screen on VR?
> Okay, I have a non-racing game tidbit for Network Emulation: > > > The name of unused data collector named Felineki hacked the game to unlock the > Tournament Battle mode in SSF2T, so I believe u can emulate this net feature on this > hardware just to show that linked up battles in Turbo would function like you've > never seen before.
... I'm not sure you understand.
Again, SailorSat has no plans to do Internet networking of cabinets in the short-term. He's only going to work on linked cabinet simulation of two or more MAME emulations on the same machine for now. And it's not a true emulation either, so not acceptable in MAME (for now).
If you're looking for battles over the Internet, you should use MAMEHub. http://www.mamehub.info/
If you're looking for true linked cabinets over the Internet... then you got nothin'.
So... Replaced the FILE I/O with TCP-Sockets. As MAME can only connect to other servers, I've written a small "MODEL-1 COMMUNICATION BD" server app that manages connections.
Using Sockets, my Q6600 can handle 4 VR units (incl. Virt Mc Polygon).
Netplay may be possible. The original Model-1 has a max Bandwidth of 6 MBit/s (TOTX173/TORX173).
One Board sends about 20 KByte/s.
So bandwidth CLIENTSIDE is like... 2 Boards - 20 KByte/s inbound and 20 KByte/s outbound. 3 Boards - 40 KByte/s inbound and 20 KByte/s outbound. 4 Boards - 60 KByte/s inbound and 20 KByte/s outbound. etc.
Congrats there for that progress. I am not sure what else remains yet to be done within modernizing remaining MAME core files, but here's hoping the cab link support might be possible this year for any of the games that do use side-by-side cab linking.
MameHub has been mentioned elsewhere in the thread and while it solves a different problem (sharing the same MAME session) it still might be worth your time to get in contact with the developer, DigitalGhost. MameHub is simply the GUI/meeting place for ClinetServerMAME which you might find more relevant. Unless you hope to have your work accepted into the official codebase, CSMAME might be a good home for it.
> Very exciting stuff there. > > MameHub has been mentioned elsewhere in the thread and while it solves a different > problem (sharing the same MAME session) it still might be worth your time to get in > contact with the developer, DigitalGhost. MameHub is simply the GUI/meeting place for > ClinetServerMAME which you might find more relevant. Unless you hope to have your > work accepted into the official codebase, CSMAME might be a good home for it.
For the moment I'll focus on ironing out some bugs, and documenting the network board itself. As the "Host"-side now seems to work somewhat stable, I'll try to get the "other" side (i.e. the Z80 and its ROM) working to some degree.
Maybe I'll take a peek into Sega System32/Multi32 too. Model2 Emulation in MAME also might get some network code.
> Unless you hope to have your work accepted into the official codebase, CSMAME might > be a good home for it.
Or, you know, MAME might be.
I am a bit put off at misinformation on this thread. MAME has built-in primitives for communicating over TCP/IP, named pipes (on Windows), PTTYs (on *IX-like systems), and even raw Ethernet (the PC, Mac, and X68000 MESS drivers can get on the Internet and post on this forum). So obviously we are opposed to networking :P
If SailorSat is doing the networking correctly (ie, running the CPU on the network board and letting it do its thing) he's in no questions asked.
Looks great and glad to see you got wingwar running, hope you will get a video up of your resurrected cab!
Between this and Star Wars model1/2 is getting a lot of love lately!
> How bout non-Sega hardware such as Midway board for Cruisn' games and Namco games
One step at a time. To have ANY game in MAME networked will be a pretty huge deal. If it gets to the point where it can be committed it should help pave the way for other games/systems.
> Wow someone's been busy! Indeed Got the lamps workin in VR too. Quite a no brainer though... VR writes lamp data to the I/O Board like WingWar - but unlike WingWar, VR reads back which lamps are currently lit - and a (default) result of 0xFF would suggest every single lamp is lit ^^
VFormula on the other hand has loads of extra stuff, a seperate controller for lamps (and most likely hydraulics), additional inputs (Emergency Shutdown), and various DIPs (Like CCD Monitor 1-4, Board 1-4 etc.).
I've added a "digit" output for the VR drive board commands so one could try to hook em up in mamehooker. They seem simple enough. Works fine except for the "Deluxe" cabinet setting.
> Looks great and glad to see you got wingwar running, hope you will get a video up of your resurrected cab! I'll try to get a decent video up a.s.a.p.
> How bout non-Sega hardware such as Midway board for Cruisn' games and Namco games Well... Midway uses some kind of nullmodem cable iirc. Totaly different approach
>Or, you know, MAME might be. Exactly ... which is why I said, and you even quoted, "Unless you hope to have your work accepted into the official codebase". Until his recent posts he was describing his work as a "dirty hack" and requiring custom middleware.
>I am a bit put off at misinformation on this thread ... So obviously we are opposed to networking :P Well, you were one saying there was nothing he could do. In the decade or so I've been following MAME network support has consistently been shot down by the devs as 'not going to happen'. If memory serves, some talk of quantum computing was bandied about. At best, it has been suggested that multiple machine instances might talk to each other within a single instance of MAME.
But shit, don't get me wrong. If this can be done in official MAME and work across ethernet to multiple instances of MAME then hell yea. If not, then it might make sense to work alongside ClientServerMAME versus creating a separate distro.
> But shit, don't get me wrong. If this can be done in official MAME and work across > ethernet to multiple instances of MAME then hell yea. If not, then it might make > sense to work alongside ClientServerMAME versus creating a separate distro.
CSMAME is bordering on being denounced in public by MAMEdev if they don't start posting some source. So we'll see how that goes
It looks like Virtua Formula fixes a couple of animation "bugs" that were in the original Virtua Racing revision, so that's neat to see too (the main one I notice is the dudes in the pit stop complete their standing-up animation after installing new tires).
> > Unless you hope to have your work accepted into the official codebase, CSMAME might > > > be a good home for it. > > Or, you know, MAME might be. > > I am a bit put off at misinformation on this thread. MAME has built-in primitives for > communicating over TCP/IP, named pipes (on Windows), PTTYs (on *IX-like systems), and > even raw Ethernet (the PC, Mac, and X68000 MESS drivers can get on the Internet and > post on this forum). So obviously we are opposed to networking :P > > If SailorSat is doing the networking correctly (ie, running the CPU on the network > board and letting it do its thing) he's in no questions asked.
I only suggested it in the first place because he said he wasn't doing the networking correctly and described his work as a "crude hack"
Anyways, if it becomes something beyond a crude hack, it'll definitely be worth looking at.
Quote: Okay, I have a non-racing game tidbit for Network Emulation:
The name of unused data collector named Felineki hacked the game to unlock the Tournament Battle mode in SSF2T, so I believe u can emulate this net feature on this hardware just to show that linked up battles in Turbo would function like you've never seen before.
BTW sailor, can you show me the "Waiting for your Entry" Screen on VR?
Felineki didn't discover that, I did. I can understand him editing the wiki may make you think other wise, but check the ST hacking thread on Shoryuken thread or the weird discoveries thread on tcrf the wiki where you got that picture from most of my posts predate that wiki edit.
> I only suggested it in the first place because he said he wasn't doing the networking > correctly and described his work as a "crude hack" > > Anyways, if it becomes something beyond a crude hack, it'll definitely be worth > looking at.
I'd like to see what exactly we're talking about in terms of "crude hack", because I have to admit I love the results
"crude hack" because: - linkup procedure doesn't work like the real hardware (Client/Server vs. fibre token ring) - external "server" application to distribute packets - hardcoded server hostname and ports (okay, not a big deal) - some todos and random crashes while coining up VR/VFormula - WingWar master seems to overwrite coin (and comm) settings. (had to set the nvram file to write protected on my WingWar cab)
I don't know about other link systems, but sega seems to love fibre optical ring buffers. (S32, M1, M2 etc.)
Maybe one could implement some generic "comm board" class that takes the part of the TCP (or even UDP) operation as well as link count / link id generating.
I'd like to "replace" my proof-of-concept VB application ^^
"I don't know about other link systems, but sega seems to love fibre optical ring buffers. (S32, M1, M2 etc.)"
Namco used something along the same lines for Suzuka 8 Hours 2(and presumably other similar hardware games), except instead of fiber cables they used standard 75ohm RCA/video cables. The 5th display on that setup just had an extra output going to the tower where it had a full extra System2 PCB setup to just run that. It received input only, had no network feedback to the rest of the system. Only difference on the PCB was one of the DIP switch settings to change it to tower mode. I had to fix up one of these at the arcade I used to work at.
We had a Virtua Racing quad setup, but after years of abuse and a previous tech that had no clue, I was only able to "rescue" a single twin unit from the whole thing. All 5 monitors were in various states of non-working. 4 of the boardsets had problems, and I had to mix and match CPU/video boards to make 2 working sets. It was beyond our budget to fix the whole setup, plus the previous tech had also thrown away(!?) the live race monitor cabinet portion, so I never got to see that in action.
I did ship the dead boards to Guru, and I think he dumped the surface mount TGP ROM's from those so they weren't totally wasted.
> Okay, I have a non-racing game tidbit for Network Emulation: > > > The name of unused data collector named Felineki hacked the game to unlock the > Tournament Battle mode in SSF2T, so I believe u can emulate this net feature on this > hardware just to show that linked up battles in Turbo would function like you've > never seen before. > > BTW sailor, can you show me the "Waiting for your Entry" Screen on VR? > > > Felineki didn't discover that, I did. I can understand him editing the wiki may make > you think other wise, but check the ST hacking thread on Shoryuken thread or the > weird discoveries thread on tcrf the wiki where you got that picture from most of my > posts predate that wiki edit. > > http://i.imgur.com/zmgBK.png > http://i.imgur.com/skBYk.png > http://i.imgur.com/b2Aa0.png > http://i.imgur.com/ift7P.png
ElSemis m2emu seems to work like that too. With the "model 2" logic, VR start to behave completly wrong (ghost cars etc.) With the "model 1" logic, daytona behaves strange (ghost cars) and sega rally deadlocks at a white screen after linkup.
>Is that emulation? Yes, I'm just activating the switch at different times. The thing about it is that the players move to different cabs the only data being transferred is if a match is still in progress, and who won said battles. Then the game tells you which cab to go to. It's nothing like you see with the Sega model systems.
> > MODEL3 you plan? scud race and dayto2pe? > > Sailorsat, can you help with the Supermodel project hooking up network emulation?
Consider it a "maybe"
I've tinkered together a comm board driver and tested various eeproms (F1 Final Lap, Rad Rally, WingWar, Daytona USA) and they seem to work basically the same. Sadly I've reached some kind of dead end. Gonna rip apart one of my Model-1 Comm Boards next.
Glad to hear you are still working on it! I hope the comm pcb tells you something.
BTW, have you looked at lamp outputs for daytona at all? I have a feeling it's similar to virtua racing how it works but I'm not that clear how you have done that. Is it writing it's value back to itself in the same memory space or is it offset one way or the other? These two games seem to have a lot in common and it's the only model 2 game I can't get lamp outputs for (aside from the test menu, they seem to work there?).
> Glad to hear you are still working on it! I hope the comm pcb tells you something. > > BTW, have you looked at lamp outputs for daytona at all? I have a feeling it's > similar to virtua racing how it works but I'm not that clear how you have done that. > Is it writing it's value back to itself in the same memory space or is it offset one > way or the other? These two games seem to have a lot in common and it's the only > model 2 game I can't get lamp outputs for (aside from the test menu, they seem to > work there?).
lua code is 09CF1730 With this you can create a script that left "watching" your memory and every editor ves values change signal to send out usb.
> > Glad to hear you are still working on it! I hope the comm pcb tells you something. > > > > BTW, have you looked at lamp outputs for daytona at all? I have a feeling it's > > similar to virtua racing how it works but I'm not that clear how you have done > that. > > Is it writing it's value back to itself in the same memory space or is it offset > one > > way or the other? These two games seem to have a lot in common and it's the only > > model 2 game I can't get lamp outputs for (aside from the test menu, they seem to > > work there?). > > > lua code is 09CF1730 With this you can create a script that left "watching" your > memory and every editor ves values change signal to send out usb. > > just an idea more
@RetroRepair: Virtua Racing was pretty simple after all - there are Memory writes to 0xC0000F, one bit per Lamp - we got that already. Now comes the magic - WingWar (and other Model-1 games) just write there, but Virtua Racing reads from there too. However we didn't handle those reads and returned 0xFF so VR though all lamps are lit.
That memory location for Daytona seems basically right, but I doubt is actually is.
Sega Rally writes its Lamp state to 0x01c0000a, but that can't be mapped in M2Emus LUA engine
> > Glad to hear you are still working on it! I hope the comm pcb tells you something. > > > > BTW, have you looked at lamp outputs for daytona at all? I have a feeling it's > > similar to virtua racing how it works but I'm not that clear how you have done > that. > > Is it writing it's value back to itself in the same memory space or is it offset > one > > way or the other? These two games seem to have a lot in common and it's the only > > model 2 game I can't get lamp outputs for (aside from the test menu, they seem to > > work there?). > > > lua code is 09CF1730 With this you can create a script that left "watching" your > memory and every editor ves values change signal to send out usb. > > just an idea more
What version of artmoney are you using because that address isn't valid for model2emu. The latest versions allow you to display constant values for model2emu. When you search you just select "address range" and then "emulator".
That doesn't look like lamp data anyway but I'd still be interested to see what it was as it doesn't much look like game state data either.
> @RetroRepair: > Virtua Racing was pretty simple after all - there are Memory writes to 0xC0000F, one > bit per Lamp - we got that already. > Now comes the magic - WingWar (and other Model-1 games) just write there, but Virtua > Racing reads from there too. However we didn't handle those reads and returned 0xFF > so VR though all lamps are lit. > > That memory location for Daytona seems basically right, but I doubt is actually is. > > Sega Rally writes its Lamp state to 0x01c0000a, but that can't be mapped in M2Emus > LUA engine
No but I have the address you can call from Lua, I'm using it too For Sega Rally it's 0x20204C
I have some lua and autohotkey scripts I was going to post over on BYOAC later today that controls a pacdrive directly from every driving game on model2emu, except daytona. I don't have an ledwiz nor do I know how to call DDE from AHK so it is what it is! All the addresses for lamp output data (each one different) are in the Lua scripts.
There are other outputs available to Lua as well such as solenoid for gunblade and I believe piston data for railchase.
Just a shame that the best model2 game can't benefit from this. It's probably in there but if you have to write someplace first I wouldn't know where to look as they all seem to have different addresses for lamp outputs.
> No but I have the address you can call from Lua, I'm using it too For Sega Rally it's > 0x20204C > > I have some lua and autohotkey scripts I was going to post over on BYOAC later today > that controls a pacdrive directly from every driving game on model2emu, except > daytona. I don't have an ledwiz nor do I know how to call DDE from AHK so it is what > it is! All the addresses for lamp output data (each one different) are in the Lua > scripts. > > There are other outputs available to Lua as well such as solenoid for gunblade and I > believe piston data for railchase. > > Just a shame that the best model2 game can't benefit from this. It's probably in > there but if you have to write someplace first I wouldn't know where to look as they > all seem to have different addresses for lamp outputs.
Well... Reading the VR Views and GameState from the CPUs memory isn't the same as the real outputs though.
Just go to service mode and try the output test.
Unfortunately without the m2emu source we can't do anything about it.
It is the real lamp output data. You can test them in test mode and everything
Try the attachment. I overlayed the value in the top left in the emu.
It seems both Desert Tank and Daytona use the same output system and cannot be located in M2Emu. Virtua Cop however can even though it's on the same revision hardware.
> > > Glad to hear you are still working on it! I hope the comm pcb tells you > something. > > > > > > BTW, have you looked at lamp outputs for daytona at all? I have a feeling it's > > > similar to virtua racing how it works but I'm not that clear how you have done > > that. > > > Is it writing it's value back to itself in the same memory space or is it offset > > one > > > way or the other? These two games seem to have a lot in common and it's the only > > > model 2 game I can't get lamp outputs for (aside from the test menu, they seem to > > > work there?). > > > > > > lua code is 09CF1730 With this you can create a script that left "watching" your > > memory and every editor ves values change signal to send out usb. > > > > just an idea more > > What version of artmoney are you using because that address isn't valid for > model2emu. The latest versions allow you to display constant values for model2emu. > When you search you just select "address range" and then "emulator". > > That doesn't look like lamp data anyway but I'd still be interested to see what it > was as it doesn't much look like game state data either.
The version used is v7.40 here I leave the table, select the address right button see "memory editor" and see how it changes value when changing lamps. then with ahk script can do the right thing.
> Actually it's not gamestate driven > > It is the real lamp output data. You can test them in test mode and everything > > Try the attachment. I overlayed the value in the top left in the emu. > > It seems both Desert Tank and Daytona use the same output system and cannot be > located in M2Emu. Virtua Cop however can even though it's on the same revision > hardware.
Wow, typed in the wrong address... oops That looks like it, AND works like a disco in 4 Player Linkup! *thumbs up*
Looks like it's programmable, though hopefully not internally unless that's not a huge problem. Not sure if these can be read out or if it's even necessary.
> > Now the REALLY interesting stuff begins > > > > Apparently the DMA controller is an equivalent of the Intel 8237A DMA controller > > according to this: > > > > http://www.datasheetarchive.com/shortform-datasheet/MB89237AP.html > > > > and the datasheet for that is here: > > > > http://www.datasheetarchive.com/Intel%208237A-datasheet.html > > > > Looks like it's programmable, though hopefully not internally unless that's not a > > huge problem. Not sure if these can be read out or if it's even necessary. > > Now you got me! > Holy Sh!t > This IS getting somewhere
> Another hour of reading docs later... > So the DLC sends out data using the HDLC Protocol - Should be pretty straigt forward > then. > > Need to get a doc for the DMA controller though
Also, pretty sure I got the actual datasheet around here somewhere. Me and Fujitsu part numbers MB86*, MB87*, MB88* and MB89* go a ways back. ICMiner.com claims to have it but is having trouble loading it right now. I think it's the same page, though: Chipdocs.com also has it: http://www.chipdocs.com/pndecoder/datasheets/FJTSU/MB89237AP.html?ReR=GG
But as you say (and according to the Fujitsu databook): you don't need it if you understand the Intel 8237A.
> There's a 1-sheet here on page 816. > http://bitsavers.informatik.uni-stuttgar...Peripherals.pdf > > Also, pretty sure I got the actual datasheet around here somewhere. Me and Fujitsu > part numbers MB86*, MB87*, MB88* and MB89* go a ways back. ICMiner.com claims to have > it but is having trouble loading it right now. > > But as you say (and according to the Fujitsu databook): you don't need it if you > understand the Intel 8237A. > > - Stiletto
Thanks for the input Got a copy of the 8237A datasheet already.
Seems the Comm Boards IO space is actually addressed by the lower 8 bits only I know that is some undocumented "feature" but how do I map these in MAME
some init stuff (leaving 0x60 in A) 1st io read (from 0x08) from IO 0x6008 to A some calculations (leaving previous read in A) 2nd io read (from 0x08) from IO 0x0008 to A
Anyway the Registers seem to map like this: IO **00 - **1F - DLC Registers IO **20 - **2F - DMA Registers
There are some elusive writes to **40 and **60 too, but I don't have a clue what they actually are. The value also gets written to internal memory. I'll check the board layout later.
Also, I noticed last night that the uncommon "System H"/coolridr.c uses a MB89237A on its communication board, may be similar (though the game is maybe a long way from playable)
MAME has a very complete, cycle-accurate 8237A DMA device under the AMD part number: am9517a.c/.h.
There's also an older i8237 emulation that isn't as good; it couldn't support e.g. SoundBlaster and other ISA DMA in the MESS PC driver so am9517a.c was born. But some drivers haven't been converted to the better implementation yet.
> MAME has a very complete, cycle-accurate 8237A DMA device under the AMD part number: > am9517a.c/.h. > > There's also an older i8237 emulation that isn't as good; it couldn't support e.g. > SoundBlaster and other ISA DMA in the MESS PC driver so am9517a.c was born. But some > drivers haven't been converted to the better implementation yet.
We'll see
Some mystery solved: JP2 selects A15 on the EEPROM JP3 selects A16 on the EEPROM
Amazing work on the linkups. Wingwar and Virtual Formula look great.
I had a go at using shared memory and two instances of Mame running on the same PC to get two virtual GPRider pcbs hooked up together a while back. It uses a dual port sram chip between two System X boards to handle the comms.
Unfortunately my PC wasn't fast enough and the emulations lost sync quickly.
You might like to try it on your system.
The shared memory is at 0x2f0000-0x2f3fff. All I did was add a memory handler that mapped the memory to shared memory (look in the SMGP init for how to add that handler, its in the same place).
If I recall correctly, GPRider only actually used 32 bytes. (but it has been a while)
> Amazing work on the linkups. Wingwar and Virtual Formula look great. > > I had a go at using shared memory and two instances of Mame running on the same PC to > get two virtual GPRider pcbs hooked up together a while back. It uses a dual port > sram chip between two System X boards to handle the comms. > > Unfortunately my PC wasn't fast enough and the emulations lost sync quickly. > > You might like to try it on your system. > > The shared memory is at 0x2f0000-0x2f3fff. All I did was add a memory handler that > mapped the memory to shared memory (look in the SMGP init for how to add that > handler, its in the same place). > > If I recall correctly, GPRider only actually used 32 bytes. (but it has been a while) > > Good luck!
That System X setup looks familiar The "direct comm" variant looks the same as the one they later used on System32 (F1 Exhaust Note, Air Rescue)
I have yet to figure out some way to do the shared ram "correctly" (currently I use file i/o with FULL shared access, which only works on the local machine).
But hey... That SMGP Comm Board... I guess that MB89372P-SH will be fun too.
As the code seems to wait forever for something to happen I guess (and checked) those writes to 0x40. A write with value 0x00 seems to "cut" a line from the model1 host to one of the PALs - I think this is some IRQ line. (once per frame?). A value of 0x02 "joins" the line, so the IRQ reaches the PALs.
As there is also a link from Z80 IRQ pin to that very PAL I assume the Z80 can tie/untie itself to/from the vblank IRQ.
There is a endless loop reading from 0x8000 (internal) and if it is non zero, it decreases some counter (starting at 0x78 -- 120) which with a framerate of (close to) 60 would cause a 2 sec delay.
If I decrease that counter by hand (either by writing some bogus data to 0x8000 or) by editing the counter itself, the loop ends, another time 0x00 gets written to IO 0x40 (disabling vblank irq again) and some magic with the (not yet hooked up) DMA is starting.
---
On another front there is some logic madness seemingly connected to host writes to the memory area above the shared memory and databus bit0 that seems to control the RESET lines on the comm board.
As we know the Model1 keeps spamming 1s to 0xc00040 after posting, most likely this enables/disables the comm board.
> Things seem to be moving along very nicely > > I hope you don't mind but I posted a custom build of groovymame with your lamp > outputs hooked up in model1.c: > http://forum.arcadecontrols.com/index.php/topic,129720.0.html > > Also has a hi/lo shifter mod for those games which use them for cabs with real > shifters or 4 ways. > > Also included the diff for those interested.
Hooked up the VBlank-IRQ done.
Now I guess I need the MC89374 user manual datasheet alone seems like a dead end for now.
> > Things seem to be moving along very nicely > > > > I hope you don't mind but I posted a custom build of groovymame with your lamp > > outputs hooked up in model1.c: > > http://forum.arcadecontrols.com/index.php/topic,129720.0.html > > > > Also has a hi/lo shifter mod for those games which use them for cabs with real > > shifters or 4 ways. > > > > Also included the diff for those interested. > > Hooked up the VBlank-IRQ done. > > Now I guess I need the MC89374 user manual datasheet alone seems like a dead end for > now.
MB89374 user manual? good to know. I'll keep an eye out.
> > Things seem to be moving along very nicely > > > > I hope you don't mind but I posted a custom build of groovymame with your lamp > > outputs hooked up in model1.c: > > http://forum.arcadecontrols.com/index.php/topic,129720.0.html > > > > Also has a hi/lo shifter mod for those games which use them for cabs with real > > shifters or 4 ways. > > > > Also included the diff for those interested. > > Hooked up the VBlank-IRQ done. > > Now I guess I need the MC89374 user manual datasheet alone seems like a dead end for > now.
Do you have a blog/twitter/fb? I'd like to subscribe.
be warned though - this is a proof of concept build use this for model1 only - model2 and system32 won't work.
*EDIT* If you "map" some local harddrive or directory to "S:\" you can give F1EN and AirRescue a try Note: One Machine needs the "direct comm" dip switch set to master, the other one to slave
*EDIT #2* Plans for the near future: - get highres pictures of the system32 and multi32 comm boards to document the differences. - update the "mame internal" documentation on the comm board jumpers and ics - convert the "real" comm board into a device. - convert the "fake" comm board into a device. - hook up the new devices to model1 driver. - possibly start another shitstorm by trying to submit that stuff ^^
> Hi SailorSat, I must congratulate you on an awesome accomplishment > > Just curious if a Mame.ini is required, if so where could I find the one specific to > this with those configurable options you speak of? > > Thanks > Gene
I can boot each VR game on each machine fine with the bat file. I then press F2 and set Master to car 1 red and link to master, then save and exit, the game then looks for network and goes no further, same with slave 02 blue, save and it looks for network but will not connect.
Esc key no longer works and I have to ctrl-alt-del to exit, then when I load the bat file again the vf settings have defaulted back to no network.
I have tried 64 and 32 bit versions.
Please help.
Currently I have M2 running a link fine on these units. On gigabit local network and can ping fine.
> Thanks. > > I have placed cabmame64 including vf rom in a folder on each desktop of linked > machines. I have a cab file on each to load cabmame > > Master: > @echo offstart /b cabmame64.exe vformula -nvram_directory nvram1 -localport 15112 > -remoteport 15113 > > Slave: > start /b cabmame64.exe vformula -nvram_directory nvram2 -localport 15113 -remoteport > 15112 > > I created mame.ini for each master and slave install, configured like this: > > Master: > localhost 192.168.0.2 > localport 15112 > remotehost 192.168.0.3 > remoteport 15113 > > Slave: > localhost 192.168.0.3 > localport 15113 > remotehost 192.168.0.2 > remoteport 15112 > > I can boot each VR game on each machine fine with the bat file. I then press F2 and > set Master to car 1 red and link to master, then save and exit, the game then looks > for network and goes no further, same with slave 02 blue, save and it looks for > network but will not connect. > > Esc key no longer works and I have to ctrl-alt-del to exit, then when I load the bat > file again the vf settings have defaulted back to no network. > > I have tried 64 and 32 bit versions. > > Please help. > > Currently I have M2 running a link fine on these units. On gigabit local network and > can ping fine. > > Thanks > Gene
Hi, dont worry, got it working. I had my ports around the wrong way.
Thanks for all the hard work making this possible Regards Gene
I'm trying to compile with the above source but it's not liking it:
Code:
src/mame/drivers/model1.c:2079:112: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2080:111: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2081:112: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2082:130: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2083:107: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2084:104: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c:2085:107: error: macro "GAME" requires 11 arguments, but only 10 given src/mame/drivers/model1.c: In function 'void comm_tick(running_machine&)': src/mame/drivers/model1.c:754:51: error: 'class emu_options' has no member named 'comm_localhost' src/mame/drivers/model1.c:754:92: error: 'class emu_options' has no member named 'comm_localport' src/mame/drivers/model1.c:760:51: error: 'class emu_options' has no member named 'comm_remotehost' src/mame/drivers/model1.c:760:93: error: 'class emu_options' has no member named 'comm_remoteport' src/mame/drivers/model1.c: In function 'void irq_raise(running_machine&, int)': src/mame/drivers/model1.c:934:56: error: 'cputag_set_input_line' was not declared in this scope src/mame/drivers/model1.c: In function 'void irq_init(running_machine&)': src/mame/drivers/model1.c:958:57: error: 'cputag_set_input_line' was not declared in this scope src/mame/drivers/model1.c:959:65: error: 'device_set_irq_callback' was not declared in this scope src/mame/drivers/model1.c: In function 'void model1_interrupt(device_t*, timer_device&, void*, INT32)': src/mame/drivers/model1.c:983:67: error: 'cputag_set_input_line' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::md1_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1268:99: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::md0_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1277:99: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::p_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1285:100: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::mr_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1292:104: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::mr2_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1312:91: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c:1314:91: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c:1316:91: error: 'cpu_get_pc' was not declared in this scope src/mame/drivers/model1.c: In member function 'UINT16 model1_state::snd_68k_ready_r(address_space&, offs_t, UINT16)': src/mame/drivers/model1.c:1321:60: error: 'cpu_get_reg' was not declared in this scope src/mame/drivers/model1.c:1325:66: error: 'device_spin_until_time' was not declared in this scope src/mame/drivers/model1.c: In member function 'void model1_state::snd_latch_to_68k_w(address_space&, offs_t, UINT16, UINT16)': src/mame/drivers/model1.c:1344:59: error: 'cputag_set_input_line' was not declared in this scope src/mame/drivers/model1.c:1346:65: error: 'device_spin_until_time' was not declared in this scope src/mame/drivers/model1.c: At global scope: src/mame/drivers/model1.c:2079:1: error: 'GAME' does not name a type src/mame/drivers/model1.c:1494:1: warning: 'void construct_ioport_vf(device_t&, ioport_list&, astring&)' defined but not used [-Wunused-function] src/mame/drivers/model1.c:1529:1: warning: 'void construct_ioport_vr(device_t&, ioport_list&, astring&)' defined but not used [-Wunused-function] src/mame/drivers/model1.c:1566:1: warning: 'void construct_ioport_wingwar(device_t&, ioport_list&, astring&)' defined but not used [-Wunused-function] src/mame/drivers/model1.c:1603:1: warning: 'void construct_ioport_swa(device_t&, ioport_list&, astring&)' defined but not used [-Wunused-function] src/mame/drivers/model1.c:2030:1: warning: 'device_t* construct_machine_config_swa(machine_config&, device_t*)' defined but not used [-Wunused-function] src/mame/drivers/model1.c:2034:1: warning: 'device_t* construct_machine_config_model1_vr(machine_config&, device_t*)' defined but not used [-Wunused-function] make: *** [obj/windows64/mame/drivers/model1.o] Error 1 make: *** Waiting for unfinished jobs....
Any idea what I'm missing? Seems like maybe you forgot to add a file to the source?
> Awesome!! I can't wait to have a go at this > > I'm trying to compile with the above source but it's not liking it: > > Any idea what I'm missing? Seems like maybe you forgot to add a file to the source?
Hm... Try it with MAME 0.146 But yes, the additional emu options are missing.
src/mame/drivers/model1.c: In function 'void comm_tick(running_machine&)': src/mame/drivers/model1.c:754:51: error: 'class emu_options' has no member named 'comm_localhost' src/mame/drivers/model1.c:754:92: error: 'class emu_options' has no member named 'comm_localport' src/mame/drivers/model1.c:760:51: error: 'class emu_options' has no member named 'comm_remotehost' src/mame/drivers/model1.c:760:93: error: 'class emu_options' has no member named 'comm_remoteport' make: *** [obj/windows64/mame/drivers/model1.o] Error 1 make: *** Waiting for unfinished jobs....
Actually the reason I was compiling was to hopefully add this to groovymame 147u3. Might it be because I'm using a newer toolchain?
> Ok, on vanilla 146 I get this: > > src/mame/drivers/model1.c: In function 'void comm_tick(running_machine&)': > src/mame/drivers/model1.c51: error: 'class emu_options' has no member named > 'comm_localhost' > src/mame/drivers/model1.c92: error: 'class emu_options' has no member named > 'comm_localport' > src/mame/drivers/model1.c51: error: 'class emu_options' has no member named > 'comm_remotehost' > src/mame/drivers/model1.c93: error: 'class emu_options' has no member named > 'comm_remoteport' > make: *** [obj/windows64/mame/drivers/model1.o] Error 1 > make: *** Waiting for unfinished jobs.... > > Actually the reason I was compiling was to hopefully add this to groovymame 147u3. > Might it be because I'm using a newer toolchain?
Like I said, the emu_opts.* is missing from the source
*EDIT*
emuopts.c [CODE]
// comm options { NULL, NULL, OPTION_HEADER, "CORE COMM OPTIONS" }, { OPTION_COMM_LOCAL_HOST, "0.0.0.0", OPTION_STRING, "local address to bind to" }, { OPTION_COMM_LOCAL_PORT, "15112", OPTION_STRING, "local port to bind to" }, { OPTION_COMM_REMOTE_HOST, "127.0.0.1", OPTION_STRING, "remote address to connect to" }, { OPTION_COMM_REMOTE_PORT, "15112", OPTION_STRING, "remote port to connect to" },