Home Page Forums MAME MAME The Newer All-Singing, All-Dancing 2023 WIP Thread

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.

[video:youtube][/video]

SpinalFeyd dumped Konami's Pikkari Chance from 2000, which is basically Pokemon Snap as a one-button medal game.

The IBM RT PC is showing some signs of life, and can now boot the Virtual Resource Manager and its VRM/AIX installation virtual machine from floppy disk:





Work is now underway on a kind of mid-level emulation of the original IBM Fixed Disk and Diskette Drive Adapter, which is the same card used in the PC AT to control MFM hard disks and floppy disks.

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:



I'm currently looking for people owning one of those cards to dump their EEPROM (and document the PCB). The dump I'm working with came from here: https://eab.abime.net/showthread.php?p=393062.

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 :-)

An undumped Namco System 12 board arrived today.
Tekken 3 TET2 Ver.C is now dumped and preserved in MAME.

This is the one Heihachi73 sent?
For documentation, is this one SYSTEM12 MOTHER(B), or SYSTEM12 MOTHER?

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.

heihachi: board is fixed. took about 15 minutes to figure it out.
hap: SYSTEM 12 MOTHER

Please PM Heihachi with your favorite SDCard recovery recipes, do not derail this thread with them. Thanks!

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.

The 020 version is fun.
https://bitsavers.org/pdf/hp/pc/measurement_coprocessor/82324/

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...

020+ don't have the restartability property yet.

It does, but it's done by a sort of state rewind. That's sufficient to run several flavors of UNIX 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.

Fixed SUBQ stop handling in PC Engine CD, which fixes hangs in at least following games, along with other things (namely a regression with pregap BGM play/repeat).

Mad Stalker



Final Zone 2 (current SW list dumps are bad, really ought to use the redump version instead)



Where in the World is Carmen Sandiego

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.

More posts when more things work :-)

https://revenant1.net/psr150_song1_test.ogg
https://revenant1.net/psr150_song2_test.ogg
https://revenant1.net/psr150_troika_test.ogg

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.)

That sounds great already! And I think common base classes for Yamaha sample player chips will be a much bigger thing as more of them are reverse-engineered.

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.

A range of the later Psion Series 3 machines are in for 0.253, namely the Series 3a, 3c, 3mx, Siena, Workabout, and Acorn Pocket Book II.








All are quite usable at this stage and a selection of Solid State Disks of apps, games, utilities have been softlisted.


We are now able to dump internal ROM and Solid State Disks via serial link to PC, so if anyone has any Series 3 machines and Solid State Disks then get in touch to get them dumped.

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:

https://imgur.com/rX5Cj5g

A pull request will eventually follow, I still need to test the intro screens.

Nice!

I have a couple of Acorn PocketBooks and may a couple of SSDs, plus a serial link. I'll tell you if I find them around!

As it turns out, this has also led to some improvements to the existing GEW8 implementation.

Here's what the MU5 demo sounds like now:
https://revenant1.net/mu5_test.ogg

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

In way less exciting news then the Namco System 10 progress in the Shout Box or recent developments in this thread, games in funworld/supercrd.cpp start to run enough to show something:

this is very exciting news!

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.

HD647180X0FS6 is the same eprom based MCU that some of the toaplan games in mame (vimana, ghox, fire shark, teki paki) use: https://caps0ff.blogspot.com/2016/12/hd647180-19-58-102-terrific-toaplan.html
So, in theory, if we have one to sacrifice, we can get the code out... and if they never set the security bit, its even easier and requires no decapping at all.

LN

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.

I feel stupider after this, it mostly involved commenting things out rather than adding anything in.

[video:youtube][/video]

Final Furlong looks a bit better too, though it still dies immediately after the second image.

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.