1. Changed the Win32 code to use _O_U8TEXT()
2. Reordered system #includes
3. Changed a number of 'std::wcout << ...' to use util::stream_format()
I'm getting massive code compilation issues, and it isn't clear to me what the problem is. I'm committing my WIP right now, with the intention of reviewing the specifics soon.
I really don't like the prevalence of '#ifdef WIN32' in this change, both the _setmode() and bypassing codecvt. I strongly suspect that the latter is the consequence of some mistake that in practice doesn't cause problems in MSVC. I welcome all eyes.
Rewritten Namco C139 device (SCI) [Angelo Salese]
Fixed POS interrupt generation for Winning Run/Winning Run '91/Winning Run Suzuka GP [Angelo Salese]
Fixed trail tachometer drawing in Winning Run [Angelo Salese]
* Identify cabinet type DIP switch
* Run the MCUs faster to get it back to same state as with simulation
* Remove now-unnecessary MCU simulation
(nw) I still don't want to drop the NOT_WORKING flag as the game's
clearly still not quite right, but it's as playable as it was previously
now, but using original MCU code for CPU comms. The clocks are still
guesses, just better guesses.
* Split out gsword and josvolly functionalit from base driver class
* Hooked up josvolly MCUs for communication between CPUs
* Added DIP locations to josvolly based on test mode
* Named unknown DIP settings after the location they control in main RAM
* Hooked up josvolly MCUs for communication, still preliminary
* Marked josvolly NOT_WORKING, simulation still present for reference
(nw) The MCU code only makes sense if there are a pair of them hooked up
together. There are effectively two programs, selected by whether P27
is tied high (master) or low (slave) at reset. Master and slave have
all corresponding P1 lines connected, master P20 connects to slave
TEST0, and master P21 connects to slave TEST1. You can see commands
and responses pass between the master and slave, it's very chatty. Test
mode seems to work, but game mode fails a check after a couple of
seconds and dumps status codes on the screen. There's still something
missing in the MCU hookup, and I'd guess there's something attached to
the AY output ports, too.
