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 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 :-)
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.
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)
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.)
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.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
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:
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.
As it turns out, this has also led to some improvements to the existing GEW8 implementation.
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:
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
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
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.
All-singing, all-dancing preview of the Namco System 23 changes that currently exist in the 'gorgonzola' branch over on https://github.com/mooglyguy/mame/ -
[video:youtube][/video]
Here's hoping this is enough to motivate people to start looking into how the Namco KEYCUS might be hooked up. And, for that matter, how inputs are hooked up.
Beena driver starting to shape up. Here's the intro sequence very close to the real thing. But still need more work on the tile layers, for example one of the screens is missing text.
Beena driver starting to shape up. Here's the intro sequence very close to the real thing. But still need more work on the tile layers, for example one of the screens is missing text.
[video:youtube][/video]
this is just amazing! are all available games already bootable?
i have a package with 13 more undumped games on the way to meā¦after that we just miss ~15 games from the complete game-library (not counting any game-revisionsā¦which will be hard to get anyway, as you canāt identify them from the cartridge- or case-outsideā¦)
I've only tried a few so far, all of them get to the Beena logo (they can also boot into test mode), but some hang after that. Might be due to waiting on some status register I haven't identified yet. It also happens on some ingame screens where transitions should happen but also hang.
The good thing is that any edge cases can just be verified on hardware with a debugger if needed.
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. ... 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.
Do you already have the Psion Revo? I own a German model with all original accessories and AFAIK there is a program to dump the rom for preservation. Due to soldered batteries and flimsy construction likely not many have survived in working condition.
After years of storage (fortunately not moist) I tried to recharge mine without success; the screen flashed on/off with beeps and red LED (fast charge) was flickering red. So I dismantled it to remove the infamous soldered NiMH battery, which already leaked (white salt) and had corroded the voltage converter/IrDa PCB. After dismantling the rear case, the screen stayed dead and reset did not help. Apparently someone had superglued the battery cable plug into its connector; it needed extreme prying with small screwdrivers to get it out, which may have damaged its solder joints. (I have cutted off the leaking cells, keeping temperature sensor intact, and wired a battery box with 2x NiMH for test.) Even thoroughly cleaning and reflowing the solder on the voltage PCB with rosin flux and hot air SMD soldering station did not help, despite the infamous foil cable to the main unit (I unplugged it) measured ok. Apparently I had jammed a piece of the adhesive foil into that connector while replugging (hard to see with my lousy mole eyes). Also one of the overloaded flimsy lid spring plastic pegs was snapped (likely by design), so I superglued an u-shaped copper wire into its place to avoid loosing the spring.
So I dismantled the main case of the machine, which was another ordeal. The silicon keyboard mat is coated with weak adhesive, which may fail to stick if it gets dusty.
CAUTION: Never use force during keyboard removal - mine possibly had a superglue spill (not by me) under the "5" key, so peeling it off ripped a 6mm hole into the mat; fortunately no contact ripped out, so it still works. (I later patched the spot with adhesive film.) The main PCB (held by small screws) must be unhooked and pulled up and forward at the front rim first. Never lift at the rear edge first; it has a tiny push button switch (lid close contact) there which will snap off (I did) if lifted or pushed down at rear edge first.
After cleaning and replugging the foil cables, the screen still was dead, but made horizontal black lines etc. when holding the cable at certain angles. So I finally reflowed the solder (with rosing flux and hot air solder station) of all small components and connectors, which made the screen come back to life.
Important is that it needs 2 connected NiMH batteries and a cold reset (insert wires into both holes for 10 seconds while plugged in) to start properly. The battery charging voltage seems to be software controlled and without batteries can be anywhere between 2 and 6V when the controller starts crashed. Using only an electrolytic capacitor (I tried 2200uF) does not stabilize supply voltage to a safe enough level to run properly, so it tends to crash during beeps and the red LED (fast charge) flickers instead of staying on or off.
Currently I have no battery pack installed, but only soldered 2 thin wires to the outside to hook up an external battery pack when needed. Because I am not actively using the Psion Revo and will not regularly charge it, this is the safest way to prevent further leak damage of the hardware to preserve it.
Fixed a few low hanging fruit in Virtual Boy driver (edited to one screen simplification): - fix GFXs in Hyper Fighting, the first case where it was breaking multi-map paging (sets big and normal tilemaps in 1024x1024, others generally don't bother and use affine instead):
- fix Space Invaders missing shots (sets X Affine outside the possible range of -4095 < x < 8191)
Model 80 Type 1 and Type 2 planars are up and running, along with a bunch more MCA cards including a Sound Blaster, 3C523 NIC, and 32-bit memory expansion. Model 50 uses the same southbridge and DMA controller so that's probably next.
Hi Luigi, I posted my IBM ROMs a while ago. The dropbox links are long gone. Please let me know if you can use any of the stuff I dumped from my PS/2 machines, and I'll make them available again if they were not saved my the MAME crew at the time. I couldn't upload them myself then.
Robert
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
New Namco System 10 ROM dumps and redumps brought some more progress to the driver. This fills out most of the old bad dumps with what should be good dumps thanks to Guru and Buffi. https://github.com/mamedev/mame/pull/11092
The dumps that worked in my last PR (Mr. Driller 2, Gamshara, Kono e Tako, Uchuu Daisakusen Chocovader Contactee, Star Trigon) were already covered in this thread and other places so I will focus on the newer progress.
The redump of Gekitoride-Jong Space makes one more playable Namco System 10 game for the MAME 0.254 release.
Ball Pom Line is also a new redump which is now bootable but needs MGEXIO emulation to be playable. You'll see an error screen normally but if you make it think the I/O exists then you can see the demo roll. This was a previously unnamed dump (unks10md2) which was able to be renamed thanks to the redump actually booting (surprisingly doesn't use encryption?). Something to look forward to in the future.
There's one more game in Namco System 10 that's bootable but isn't playable due to missing I/O: NFL Classic Football (nflclsfb). It will hang at a black screen but internally it throws an EXIO error. If you patch the EXIO check it boots and the demo roll works just fine. Something else to look forward to in the future.
I've worked a bit on the Liberty Electronics Freedom 220 terminal:
Current status: Keyboard is implemented, receiving/sending data over serial works. The video emulation needs work. It uses the annoying SCN2674 display controller that can be hooked up in a million different ways, and there are no docs at all for this system.
More Namco System 10 progress (PR)! Every game that has a decrypter (and isn't a bad dump) is booting to at least the title screen now.
Kotoba no Puzzle Mojipittan got a redump so that is playable now. GAHAHA Ippatsudou and Golgo 13: Juusei no Chinkonka got the necessary I/O board emulation required for those to be fully playable now. Golgo 13 is missing BGM still because it uses MP3s instead of normal audio but is otherwise playable.
The previously mentioned patches for Ball Pom Line and NFL Classic Football are also no longer required. NFL Classic Football has all I/O except the trackball implemented, but the trackball not being implemented makes the game impossible to play still.
Peter Wilhelmsen and Samuel Neves have been working on the encryption for Namco System 10 games and have had some success, providing us with new decryption devices for GAHAHA Ippatsudou), Golgo 13: Juusei no Chinkonka, Sekai Kaseki Hakken, and Pacman BALL. The remaining games have things about them that make them tougher so research is still ongoing, but a few new playable games is very solid progress. Thank you Peter and Samuel.
I added the CD-i Golgo 13 game earlier this month (apparently it was dumped last year and... no one told me) and Vas approved the submission yesterday. The bottom of the screen is glitched but it's fully playable.
I intend to add more of the recent Redump items (and verify those dumps against the existing ones) but I need more hard drive space and an upload speed that doesn't suck. :p
I added the CD-i Golgo 13 game earlier this month (apparently it was dumped last year and... no one told me) and Vas approved the submission yesterday. The bottom of the screen is glitched but it's fully playable.
It was dumped and hoarded. A regular at Lost Media Wiki got a copy on e-bay, dumped and uploaded it earlier this month, apparently prompting the hoarder to also upload it since it was in the wild. The modification date on the file is just that ā the date the hoarder originally archived it.
I've only tried a few so far, all of them get to the Beena logo (they can also boot into test mode), but some hang after that. Might be due to waiting on some status register I haven't identified yet. It also happens on some ingame screens where transitions should happen but also hang.
Indeed there were some checks on audio registers likely used for syncing. Unblocking that and implementing some registers for a realtime clock fixed all the hangs I found so far.
In the meantime, I've also figured out the tablet input, so here's another wip for it. Still need to do the storyware input to try out most functionality in games.
40 Dreamcast games started booting after I flipped the DRDY signal to actually be true in config (pending more investigation). Too many snaps, so I'm gonna shamelessly crosspost to my Twitter: https://twitter.com/DonKaleAEX/status/1649910635197497345
ETA: Bangai-oh surprisingly playable at 99.02% on extensive playthrough on high end machines:
Last edited by Kale; 04/22/2311:56 PM. Reason: bangaio
The Omron Luna 88KĀ² is now booting and running UniOS from a hard disk image. Although the "XP" is still not working (due to unemulated CPU features), it's not really necessary to use the system. At this point, the emulation of the MC88100 CPU and MC88200 CMMU are reasonably solid (at least for single-CPU configurations), and should allow some of the other 88k systems, particularly the DG AViiON, to progress a bit further. The earlier Omron Luna 88K should also be relatively straightforward to support if firmware ever shows up because the two systems are very similar.
The emulation supports the LCD status display (although the colours are not accurate):
Here's UniOS starting up:
It can compile something (it has both a Green Hills compiler and an ancient version of gcc) and talk to the internet so I think it counts as "working":
I got an IBM PS/2 Speech Adapter in the mail a week or so ago. It's an ISA card containing both a 5220 and an MC3418 CVSD chip, an ISA clone of the PCjr's speech sidecar. Unfortunately, I only have the manual and BIOS listings for the PCjr version so finding the differences to get the ISA version to work properly (mainly its 8254 behavior) is a challenge. It can play back CVSD recordings off of a demo floppy and LPC speech from edutainment software, but there's still a problem with LPC interrupts that makes the card flip out if you switch sounds too fast. MAME also doesn't support CVSD encoding, just decoding. Here's a video of it in action: https://twitter.com/LuigiThirty/status/1650760428883005441?s=20
It's a computer that was described in a magazine (mc, we already have one other computer of them in MAME). You could build it yourself or order a pre-built kit. Available operating systems for it are CP/M-68k and OS/9. Some infos and pictures are available in this thread: https://forum.classic-computing.de/forum/index.php?thread/28014-der-mc-68000-computer/
Still don't have any disk images, so I've used a disk from another CP/M 68k system. This works, because CP/M is fully in ROM and it only expects a config file on disk. Note that the defaults specify a RAM disk that is incompatible with a 128k system, so you need to use "-ramsize 512k" or it will overwrite parts of system memory and crash.
I finally got enough emulated of the Beena for an initial pull request.
Here's a WIP showing all inputs in use, including booklet pages: [video:youtube][/video]
There's some custom stuff that might change, but the overall look and feel is what I was aiming for. You can see elements being interacted with a dot cursor on the top screen.
Nice, do you think the booklet implementation could be reused for the Sega Pico?
Although Pico emulation isn't that good in MAME (or any other emulator really), that alone would make quite a few of the working games actually playable.
Nice, do you think the booklet implementation could be reused for the Sega Pico?
Although Pico emulation isn't that good in MAME (or any other emulator really), that alone would make quite a few of the working games actually playable.
I hope so, both are using lightgun input ports for the pen, the main difference is how those values get mapped.
Yeah the Pico is fun, there's an undocumented IRQ that no emulator out there gets right (I think only Fusion even calls it at all, but some games that are more timing sensitive to it eventually crash).
I just took a quick look over the pull request. It's honestly pretty damn good, especially for a first-time contribution.
Most of my quibbles mainly revolve around using facilities that are already available, but which may not have been initially obvious. If there are any feedback points I left that don't seem easily doable, drop a line here and I'll do my best to explain things.
Don't know if it's just me, but I don't see any comments under "files changed".
Sorry about that, for some reason I seem to be completely unfamiliar with the actual review cycle on Github. Somehow I managed to go years with only leaving comments and never starting a proper review.
The rare Psion 3aR has been found and dumped, and is in for next release!
I really thought the 3aR would've been harder to find, and other language variants found sooner.
We're still looking for owners of Psion Series 3/3a/3c/3mx/etc. machines running other language variants. There are known to be German, French, Flemish, Dutch, and maybe Spanish and Italian versions produced for some models.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
The second-generation 68040 Mac systems (codenamed "Wombat") are starting to come up now. That's the Centris 610 (20 MHz), Centris 650 (25 MHz, built-in Ethernet), and Quadra 800 (33 MHz, built-in Ethernet), and the later renames of the two Centris machines to be Quadra 610 and Quadra 650. (Apple product marketing and naming was weird at that time).
If you want to merge or add the moof and cracked lists that Firehawke started, I can get them updated with all the recent 4AM releases. Firehawkeās update is still available through GitHub. Iām slowly working on the updates to the Apple II woz-a-day that were suggested.
Iāll have the MOOF software list done and MAME software updates checked in tomorrow. Just need to get through the rest of the dumps. Then Iāll work on the Mac cracks.
Iāll have the MOOF software list done and MAME software updates checked in tomorrow. Just need to get through the rest of the dumps. Then Iāll work on the Mac cracks.
A-noid
As luck would have it, itās release week again. Iāll get to it, I promise.
As luck would have it, itās release week again. Iāll get to it, I promise.
Thanks. Youāll hopefully find this list is very clean. Iāve been working the apple II lists, too. I think Iāll knock out the Mac crack list next and then get back to the Apple ii.
Much thanks to R. Belmont and MAME team. The early Mac drivers work very well.
As luck would have it, itās release week again. Iāll get to it, I promise.
Thanks. Youāll hopefully find this list is very clean. Iāve been working the apple II lists, too. I think Iāll knock out the Mac crack list next and then get back to the Apple ii.
Much thanks to R. Belmont and MAME team. The early Mac drivers work very well.
Yeah, itās not like the bad old days of MESS. When I was fixing up SuperMac and Apple video card emulation for the MacĀ II family, I was pleasantly surprised at how well the systems themselves worked for the most part.
Oops, I did it again. The third-generation 68040 machines (Quadra 605, LC/Performa 475, LC/Performa 575, codenamed "Optimus" and "Primus"), use a pair of ASICs that are mostly very similar to what was in the second-gen (and in MAME consist of a pair of subclasses of those devices). Except for some annoying cost-cutting, like the data bus to the DAFB registers being half-width so you have to write everything twice. But I can handle that.
The original Indigo (with R3000 @ 33MHz) is now able to boot and run IRIX 4.0.5 and 5.3. Networking works reasonably well, but graphics only partially working and there's no dsp/audio yet.
This work also brings the Personal IRIS 4D/35 up to the same level of functionality, because it's essentially the same core hardware.
The Indigo R4000 and R4400 models are close behind, and I hope to get them to the same state soon.
And now we venture into the land of one of the Top 10 Worst Macs ever made, the Quadra 630/LC 630/LC 580.
Gonna be a minute with this one before it's commit-able. The ATA interface is kind of crude and causes unrelated software to have a fit if I attach any ATA devices. Fortunately the SCSI that's "just like a 53C96" according to Apple works 100% with a 53C96 there so I've got nothing.
Managed to unbreak SanSan for MD. Should've read that it was moaning about SRAM not initialized. Likely MAME is the first to emulate local multiplayer here, obviously modem features still unsupported.
Some work on the Taito Data Net Station (X-55/M-88):
Though the network service has been down for years and nothing is retained on the unit, it appears software can be ran off a PCMCIA flash card so there is faint hope of finding something to run on it...
As people using MAME on macOS probably know, the PCAP backend only worked for machines with a wired Ethernet connection because ???. And while Apple's trying to make that go away entirely, at least 10.10 and later provide a supported API for emulators and VMs to have Ethernet, called "vmnet". With some assistance from Kelvin Sherlock, maker of the Ample frontend, I'm adding support to MAME. So on my MacBook Pro running on WiFi I can do stuff like this:
Looking at taito/sbmjb.cpp I realized it uses the same opto stuff as pkspirit/taito_o so added it. sbmjb & bubbroul are now playable (I guess they errors out if payout is selected). honooinv seems to require extra inputs so it keeps failing after some time:
Lots of mahjong games have characters ripped off from popular manga and anime. There are the Nichibutsu Mahjong Sailor Wars and Sphinx Bishoujo Janshi Pretty Sailor 18-kin games with characters obviously ripped off from Sailor Moon. Thereās one I canāt remember the title of where youāre rescuing girls from a demon thatās a rip-off of the character Pantyhose Taro from Ranma 1/2.
U-Boot 1.1.2.greyinnovation.EOL (Oct 25 2005 - 10:16:54)
U-Boot code: 30F80000 -> 30FA1580 BSS: -> 30FA5BB8
RAM Configuration:
Bank #0: 30000000 16 MB
FLASH Mpf id is 0x0090, ## Unknown FLASH on Bank 0: ID 0xffff, Size = 0x00000000 = 0 MB
## Found CFI FLASH on Bank 0: ID 0xffff, Size = 0x00000000 = 0 MB
Flash: 0 kB
NAND:
---------------------------------
Digiblast Nand Flash Boot - release version 1.3.3_I(Fixed_NAND_BOOT_ROM) (Grey Innovation).
---------------------------------
NanD_Command (ReadID) got 0 0
No NAND flash chips recognised.
0 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
ethaddr 00:00:00:00:00:00
Hit any key to stop autoboot: 0
NAND read: device -1 offset 180224, size 16384, cmd 5...
nand_read_ecc: Attempt read beyond end of device 2c000 4000 6
0 bytes read: ERROR
## Executing script at 30400000
Bad magic number
digiblast #
I'm not sure I agree with the comment at the top of digiblast.cpp that the NAND handling (the NANDling, if you will) should necessarily be handled by the cartridge code. It's more that the common NANDling code in ghosteo.cpp (which slots almost unmodified into digiblast.cpp) should be brought into the S3C24xx SoC code, with the ROM page size fed into the S3C24xx as an option in order to handle ROMs both with and without ECC data.
Beyond that, all the S3C24xx code needs is a region pointer. Having a custom cartridge slot device for this just seems like overkill.