I've had a pair of ld-decode captures of a Pioneer LaserActive game converting in the background while capturing footage for an upcoming video. The stacking and conversion seemed to go nicely, and so I decided to take an evening's break and poke at some shiny instead.
It's not much, but it beats the system just hanging on a static screen.
The Labtam 3000 apparently needs a second 8086 card installed to boot CCP/M-86.
That make 3 Multibus cards in total to run this OS:
the Z80SBC handles the floppy drive and bootstraps the others
the first 8086 VDU/COMM card drives the video and serial ports (and I think keyboard)
the second 8086 CPU card runs 8086 software
The 8086 card is actually the same hardware, with DIP switches configured slightly differently and different firmware. Anyway, now that it's reporting an actual problem instead of just waiting for something which never happens, it should be possible to progress further.
We have some initial PCMCIA support in MAME, that is used by Konami/Taito systems. I'm currently looking at extending this a bit and adding it to the Amiga driver. Here's a screenshot of an SRAM PCMCIA card on the A600 driver:
Not sure this is WIP but it's a new dump I just did :-) ROMs are on their way out, had to read them at 4.9V to get consistent reads as these shitty Intel tsop flash ROMs are beginning to die now and don't read the same on multiple reads at the nominal 5 volts. Board was stickered TES3 VER.B but is actually an undumped TES3VER.A set. This is the final plain Tekken 2 version before they went to Tekken 2 VER.B on the title screen (which is TES3VER.B / tekken2ub in MAME) I plugged this in overwriting the ROMs for the tekken2a set and it fired right up :-)
Yeah, that was the one. That board was an absolute fluke I found it in the wild, I picked up that decrepit thing on eBay just so I could sit an arcade PCB in the collection with the other Tekken collectibles e.g. Pop vinyls and PS1/2 games (my cutoff is Tekken 5/DR). The eBay listing didn't even show the Ver.C sticker or mention anything about it, just that it was a Tekken 3 JAMMA PCB. When I received it and saw the TET2 VER.C label underneath it I just had to get it preserved. IIRC the some of the other stickers showed that it had been in New Zealand at one stage even though I bought it in Australia (also IIRC it was a 1997 board mashed up with a 1999 board). Took a while for me to actually send it though due to laziness followed by a Real Life™ incident a couple of months ago.
I took a number of photos of the PCB showing its layout and damaged areas (capacitor on CPU board ripped off, minor damage on ROM board over components near JAMMA connector etc.) but the camera's SD card randomly corrupted itself only a couple of days ago, not sure if I can get the photos back or if they've been overwritten or completely garbled like the filenames were (inserting it into a PC shows the 900CANON folder with a dozen or so garbage filenames and two (three counting one deleted) more recent photos I took before I noticed the others were missing, and certainly not the 600+ photos it previously had).
Edit: Just aced it in 1:57.80 with Yoshimitsu on default settings (first power on, no time release characters etc.) Ran it as tekken3b without bothering to compile MAME (used an ancient 0.152 build on my shitty second PC which can't handle Tekken 3 in anything later - I had to actually rename it tekken3ab in that version as World/Asia regions were the wrong way around). Stupid thing crashed though when I alt+tabbed back to Firefox so I lost my record! Got some screenshots in its low-res 512x240 glory before it crashed however.
Something different: Suppport for the HP8231A Basic Language Coprocessor found in HP Vectra PC's back in the 90ies (http://www.hpmuseum.net/display_item.php?hw=681) These cards emulate the HP9000/300 System to run HP BASIC programs either in foreground or in backgroud while MSDOS is running. Common usecase was controlling Test equipment. The implementation requires new68k, because it needs restartable memory accesses.
Yes, had such a card a few years ago, but never got it to work. Selftest was always failing. I'm looking for a while now for another one, but looks like they are getting rare. And it has a '030 on it, not sure whether there's some way to get it emulated with the current '030 we have in mame. Not that it would be easier with a '020 though...
Another random VME board, this time it's Tadpole Technology's TP881V.
This thing consists of a base I/O card with serial and dual SCSI controllers, and then one or two CPU boards which can have between 1 and 4 20MHz MC88100 CPU's, each with a pair of MC88200 CMMUs.
Unusual is the extensive use of Zilog Z8036 Z-CIO devices for various I/O port and interrupt control.
The main task required to get this doing something more impressive will be emulating the MC68440 DMA controller, and figuring out what prevents Plamen's real hardware SCSI from working so we can get a disk image of TPIX.
Hammy dumped Konami's "Golden Region", a combination video and mechanical pachislot game on a previously unseen board with yet another arrangement of the usual System GX suspects (56832 tilemaps, 53246 sprites, 55555 priority controller). As usual the Konami POST makes getting something out of it not too hard, but it looks like it breaks the tilemaps in an interesting way.
After building a very, very pricise 68000 core and with some invaluable help from ijor (Jorge Cwik), who reversed-engineered all the st chips from die shots (also know as our kind of person), the ST driver is slowly starting to look like how it should. Still a bunch of problems with in particular the mmu and the 68901, but it's getting somewhere.
But I hear people like screenshots? Ok, then let's have some. What I think was the first megademo on the ST was called the Union Demo, because it was done by a bunch of demomakers (also known as crackers that found more fun in writing the intros they put in front of the cracked games that actually doing the cracking) and not just one. It was also I think once of the first demos with a menu to choose between different screens, which became the norm on the atari for a while.
So here is the intro to the demo. It's moving all over the place, but it's reasonably done with raster-interrupt driven palette-changes. What one usually doesn't know is that demomakers wanted to make it a little difficult to steal their methods, and ex-crackers tend to be decent at protection. So reaching that screen requires making 14 sectors dedicated to protection be happy. So I'm happy to say that our current emulation is good enough to convince the Union demo protection. Sadly the 68901 fails at convincing the Ventura Demo or Punish your machine.
But while the idea of a menu was something new, or at least not usual at the time (we're talking 1988 here)...
... it was amusing to move "charlie" with the joystick to choose a door. You may notice there is something strange going on with the sides of the scrolltext. But one of the two things that really sealed the Union Demo's reputation is the Level 16 screen.
You'll notice that the Level 16 screen looks bigger than the others. That's because it is. It's considered the first stable overscan on the ST. Overscan has a interesting history, it's not something that's supported by the hardware of the st. But due to the fact that the circuit which decides whether to start or stop the display works with equality comparisons and the values compared to depend on the screen frequency (50, 60 or 70Hz) it is possible to mess up with them by perfectly timed changes without breaking the global screen syncs. And the interesting thing is that it was 100% experimental. They built models of how things seemed to work which were incorrect but useful, but what really happens wasn't understood until 2015 with ijor's decapping and analysis. Which ended up with the release of Sync's Closure demo which very much needed that perfect understanding. I haven't even dared trying it yet, I know where the current emulation breaks already.
Haven't bothered making layouts yet, but I'm working on Yamaha GEW7 stuff at the moment. A lot of it is based on the existing GEW8/MultiPCM stuff that I refactored into a common base class, but there are still some slightly inaccurate or totally unknown things (envelope rates, sample properties, etc.)
I fixed up segment limit checks in i386 and added an IDE card to my MCA bus (SCSI would require a controller device and junk, IDE is just an option ROM and a connector), giving the PS/2 a hard drive to boot from.
First time posting here, just wanted to share that after the recent Sega Beena breakthroughs, I've been working on the existing skeleton driver. It's at a point where one of the tile planes is being correctly rendered, this one is used in the "no cartridge found" screen:
Still has some issues compared to the real device (e.g. the synth strings around 0:24 are totally missing) but it's still a pretty clear improvement. Once I'm finished with all this GEW7 stuff I may focus on being able to get this promoted next.
That's much improved on the MU-5! And I completely feel the "god dammit yamaha" you posted on Twitter, although it's definitely not unknown for some chips to manage to read on lines where the DDR is set to output.
There tend to be three possibililties there: - h8 mode, some directions for some bits are fixed, and the ddr register just does not implement the corresponding bits which are ignored - 6522 mode, some ports are open-collector, e.g. the pin drives to 0 but it just a pull-up for 1. Allows to do easy bidirectional for things like i2c and its ancestors - crap mode, the external device drives the pins harder than the i/o device
Made some progress on the Omron Luna 88K² workstation; now it passes most of its firmware diagnostics and boots to the monitor. The keyboard is a high-level emulation with some unsatisfying gaps in the key mapping (even finding a good picture of the key tops and positions has been a challenge), but it's usable for now.
The "xp" is a HD647180X0FS6 I/O processor that drives two serial ports, a printer port, and possibly is involved with the optional floppy disk card. While the firmware for this chip hasn't been dumped yet, it might not be required as the host uploads code dynamically and it should be possible to get it working once some missing features of the CPU are emulated.
The other major outstanding area of work is the MB89352A SCSI controller; once this is up and running the next major milestone will be booting UniOS.
How accurate are the current GEW8 envelope rates meant to be, if you happen to know? (I know they're based on the values from the OPL4 manual)
I think the reason that string part is missing from the demo is just because the attack on "Strings 2" is way slower than it's supposed to be and the notes end up being too short to be audible. I'm currently fudging the GEW7 envelopes a bit for a similar reason, but I wonder if the envelope rates on both chips are actually supposed to be the same (or at least closer to each other).
GEW8 envelopes are, as you noticed, taken from OPL4 and fudged a little to make the Sega games sound good. But Sega largely used the chip as a dumb sample player with some occasional LFO so those games were far from a good test suite.
With sprites re-enabled and an additional mode bit identified - bit 12 of the matrix-vector multiply command header turns it from "Matrix * Vector + Vector" into "Matrix * Vector - Vector" - Final Furlong actually starts to look like a game.
Added support for the CuRAM-16 XMS card to the PS/2. The Model 80 isn't fully compatible with it but the IBM first-party RAM expansion cards have option ROMs and no documentation. This is enough to install and run Doom (...on a 16MHz 386.).
I have a bunch of cards emulated now. The Sound Blaster MCV's FM audio works but digital audio crashes the emulated system.
Also working on the M-ACPA DSP card. I don't have any of the analog section hooked up yet but the DSP communication works.