digiBLAST's build of Linux wants an ARM920 specifically, and it gets instantly cranky if the expected CoproID doesn't match.
Now it boots even further, but it looks like the I2S implementation leaves something to be desired. At least, that's going off of the console messages about DMA triggering an IRQ without an active buffer, and the fact that it hangs on a black screen.
Code
NAND read: device 0 offset 262144, size 65536, cmd 5...
65536 bytes read: OK
## Booting image at 30c00000 ...
Image Name:
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 825483 Bytes = 806.1 kB
Load Address: 30008000
Entry Point: 30008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Linux version 2.6.11 (shaun.adolphson@malbec.greyinnovation.com) (gcc version 3.4.1) #6 Mon Nov 14 10:18:56 EST 2005
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
CPU0: D VIVT write-back cache
CPU0: I cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
CPU0: D cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
Machine: DIGIBLAST
Memory policy: ECC disabled, Data cache writeback
CPU S3C2410A (id 0x32410002)
S3C2410: core 180.000 MHz, memory 90.000 MHz, peripheral 45.000 MHz
S3C2410 Clock control, (c) 2004 Simtec Electronics
USB Power Control, (c) 2005 Grey Innovation
Built 1 zonelists
Kernel command line: console=ttySAC0,115200 mem=16M devfs=mount panic=30 init=/linuxrc root=/dev/mtdblock/5 ro rootfstype=squashfs splash=0x30310000
PID hash table entries: 128 (order: 7, 2048 bytes)
timer tcon=00500008, tcnt 927b, tcfg 0000020c,00000000, usec 00002222
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 16MB = 16MB total
Memory: 14388KB available (1418K code, 289K data, 68K init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Linux NoNET1.0 for Linux 2.6
S3C2410: Initialising architecture
SCSI subsystem initialized
usbcore: registered new driver hub
S3C2410 DMA Driver, (c) 2003-2004 Simtec Electronics
DMA channel 0 at c1800000, irq 33
DMA channel 1 at c1800040, irq 34
DMA channel 2 at c1800080, irq 35
DMA channel 3 at c18000c0, irq 36
NetWinder Floating Point Emulator V0.97 (double precision)
Squashfs 2.2 (released 2005/07/03) (C) 2002-2005 Phillip Lougher
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Displaying splash screen at 0x30310000, stand well clear
fb0: s3c2410fb frame buffer device
s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2410
s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2410
s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2410
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
Battery Driver loaded for Digiblast
Linux video capture interface: v1.00
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c2410-nand: mapped registers at c1880000
s3c2410-nand: timing: Tacls 11ns, Twrph0 33ns, Twrph1 11ns
s3c2410-nand: timing: Tacls 1 HCLK, Twrph0 3 HCLK, Twrph1 1 HCLK with HCLK = 90000000
NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit)
Scanning device for bad blocks
Skipping bad block check
Creating 6 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x0002c000 : "u-boot"
0x0002c000-0x00030000 : "bootscript"
0x00030000-0x00040000 : "bootsplash0"
0x00040000-0x00050000 : "bootsplash1"
0x00050000-0x00170000 : "kernel"
0x00170000-0x04000000 : "rootfs"
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
cpia2: V4L-Driver for Vision CPiA2 based cameras v1.0.0
usbcore: registered new driver cpia2
s3c2410 usb gadget driver loaded. Version 1.3.6 Grey Innovation
mice: PS/2 mouse device common for all mice
Probing Grey-keypad...
s3c2410-i2c s3c2410-i2c: slave address 0x10
s3c2410-i2c s3c2410-i2c: bus frequency set to 9 KHz
s3c2410-i2c s3c2410-i2c: i2c-0: S3C I2C adapter
eeprom_24cxx module initialised
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC).
i2c/cs43l43.o : created PROC entry driver/cs43l43
cs43l43 module initialised
i2c/cs43l43.o : Adapter registered: s3c2410-i2c
probing for s3c2410-iis
s3c2410-iis s3c2410-iis: attached cs43l43 driver
s3c2410-iis s3c2410-iis: clock pclk, rate 45000000Hz
s3c2410-iis s3c2410-iis: probe called
s3c2410-iis s3c2410-iis: soundcard attached ok (c03385d0)
ALSA device list:
#0: S3C24XX CS43L43
VFS: Mounted root (squashfs filesystem) readonly.
Mounted devfs on /dev
Freeing init memory: 68K
snd_pcm_hw_params:
snd_pcm_action_single: res=0
snd_pcm_action_single: res=0
snd_pcm_drop: pcm stopping
snd_pcm_stop:
snd_pcm_action_single: res=0
snd_pcm_hw_params:
snd_pcm_drop: pcm stopping
snd_pcm_stop:
snd_pcm_action_single: res=0
snd_pcm_hw_params:
snd_pcm_action_single: res=0
dma2: IRQ with no loaded buffer?
dma2: IRQ with no loaded buffer?
snd_pcm_lib_write1: avail: 2048, threshold: 1
s3c24xx_snd_pcm_trigger: substream=c0346e20, cmd=1
snd_pcm_action_single: res=0
snd_pcm_action_single: res=0
snd_pcm_update_hw_ptr_post: avail: 8192, stop_threshold: 8192, buffer_size: 8192, hw_ptr 81920
snd_pcm_drain_done:
s3c24xx_snd_pcm_trigger: substream=c0346e20, cmd=0
snd_pcm_action_single: res=0
Average speed: 19.11% (6 seconds)
Nice. I was talking to some of the people involved with this last year, and despite it being a recent system, it's an open design and they're happy to see it emulated as emulation helps with development of new software etc.
It'll be interesting to see if MAME compatibility ends up better than the other emulators, as while we're not emulating it at an FPGA level, we are a lot more flexible and emulate more of the extra peripherals.
I would call it FPGA "translation", not emulation. Trying to use original FPGA "language" as close as possible but unfortunately have to take shortcuts sometimes. Not sure about whole varaity of peripherals - current goal is implement Next specific features whatever others Spectrums in MAME can't provide now.
yep, it's a different scene, and the NEXT is well suited to arcade conversions using the original code for game logic but which reinterpret the video / sound. In cases like that emulation helps greatly.
not a bad product, but supply issues will likely condemn the hardware to being not much more than a historical footnote.
Sega Ferie's pen calibration screen. Colors are approximations, and the crosshair char is missing its rightmost dots, but the rest looks accurate.
Probably more interesting is the CPU itself: T6A84 seems to use distinct address spaces for code, data, and stack, with ROM and RAM address range mappings configured via I/O ports. This allows it to fetch and execute instructions from code space (0x10000 bytes), while reading another range from ROM (also 0x10000 bytes), or manipulating RAM in data space (0x8000 bytes). At least this is what makes sense from disassembled code, can't really find any documentation for it...
Sega Ferie with emulated inputs. This layout is based on Beena's, but I was able to get the pen cursor to move seamlessly between screen and panel element, no need to use a input button to switch between the two cursors.
No footage yet - running the ffmpeg export now - but the numbers themselves are beautiful.
Visible dropout statistics: Disc 1, Disc 2, Disc 3, Disc 4, Stacked. X axis is frame number, Y axis is max dropout length.
Same, but zoomed full-screen for Disc 2 in particular:
Same, but zoomed full-screen for the stack:
Some wins, some losses: - Loss: Disc 5 ended up having some player issues: The capture started having issues with the player abruptly stopping at around frame 32000 and then resuming. It was enough to make the capture unusable, so this is a stack of 4 discs instead of 5. - Neutral: All four discs had heavy amounts of dropouts, nearly every frame at lengths of anywhere from 200 to 350 samples (pixels) long. - Win: Despite not being a perfect capture, the stacked output is dropout-free for tens of frames at a stretch, and has a peak dropout length of around 65 samples, closer to 40 samples or shorter for the vast majority of the stack.
I'd estimate that a completely clean stack would need roughly twice as many discs. Fortunately, I seem to recall that all four of the discs were sourced specifically from one person - I'll sniff around and see if I can track down any additional captures to add into the mix later.
Thayer's Quest, arcade, 4-disc stack: Individual dropout graphs, dropout graph of stacked, and two additional graphs for good measure (showing that the blue spike moves with the player cursor, so it's not a dropout).
From four relatively mangled discs, to zero dropouts. NONE. A PERFECT FUCKING CAPTURE.
As Kale made this coinable when work was done on some other Taito drivers I decided to revisit the video.
It's not perfect (some sprite attributes such as the sizes, and possibly priority need further investigation) but it runs with proper colours now, and you can tell it is a game (see the cards etc.)
It is currently connecting to the Telstar TCP port through the rs232/null_modem device. This is not ideal as it connects to the stream at machine start and instantly receives a welcome page that is ignored by the Tandata as it hasn't yet been told to dial a service, to initiate a connection.
Ideally I think I need a imagedev/viewdata_device that will give me more control over the connection, allowing to enable/disable RX/TX only when the dial sequence is complete and is waiting to receive data.
Last edited by Pernod; 01/24/2402:24 AM.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
Today, January 24, 2024, is the 40th anniversary of the Macintosh, and conveniently I've just gotten one of the weirder ones made to boot. This is the Macintosh TV, from late 1993, which worked either as a Mac (more or less a Color Classic architecturally, but in a black case instead of the usual Apple Platinum) or a TV with a remote control (TV was full screen and you couldn't use the computer while watching). Only about 10,000 were sold.
So excited for the next MAME release... thank you for all that you're doing here (and for everything else you've been doing since forever).
Side question... I noticed a while ago that the keyboard CPO I have for Thayer's Quest is generic... and the best real version that seems to be online is just 640x480. Any chance on asking the group that supplied the discs if any of them have the original CPO, and can take a good scan or a few hi-res photos?
(Not holding my breath... but if I don't ask, it's an automatic no).
Thanks!!!
RELAX and just have fun. Remember, it's all about the games.
While waiting for a potential dump of the Visual 50 character ROM I took a look at another Visual system available on Bitsavers, the XDS-19P:
It can enter the boot menu successfully and I've more or less implemented the keyboard:
The LANCE is also working:
However, trying to "romboot" just resets the system. I assume the ROMs needed for that are undumped (there are 4 empty sockets). Finding the software needed for network booting is probably close to impossible, the whole system is basically unknown to the internet.
I've committed the driver. It works reasonable well as far as I can test it. I've setup a virtual Debian installation to provide BOOTP and TFTP services for it, and it successfully tries to network boot:
Quite amazing actually, that a current Linux installation (I've used Debian 12) can provide software support for a terminal that is now 34 years old.
IBM 5100 is now working pretty nicely. Thanks to the good work of others (Christian Corti and Tom Stepleton), most of the firmware for this very firmware-heavy system had already been dumped. There's also copious good quality IBM documentation available, which made the work fairly straightforward.
Without repeating all the information that's better presented elsewhere, the IBM 5100 was a very early (1975) portable computer, with its own PALM (apparently "Put All Logic in Microcode") single-card CPU. The CPU and much of the logic in the system is built up from IBM gate arrays, and even the firmware is stored in IBM's own ROS (read-only storage) chips; this is not so surprising for the period, however it did present some challenges for dumping.
An interesting point is that the APL and BASIC languages were ported to this machine by emulating their original big-iron hosts (IBM System/360 Model 50 for APL and IBM System/3 Model 6 for BASIC), so the firmware contains not just the language interpreters, but system emulation code as well.
The emulation runs both languages, with configurations between 16K to 64K of RWS (read-write storage in IBM).
APL (the asterisk is the exponentiation operator):
BASIC:
What's not done: - tape drive - printer (I'm not very interested in tackling this) - communications options (also not too excited about them) - 5110, 5120 and 5130 models, including floppy disk drive
During the weekend I scanned the Visual X Display Station manual and addendum and sent it to Al for upload to bitsavers. It is online now. If anyone want the manual while playing with the Visual X terminal in MAME.
I'm in the process of upgrading the 680x0 FPU emulation to SoftFloat 3 instead of 2, and fixing some errors along the way. In current top-of-tree, the Extended Calculator shows Apple's SANE mathematics library is having trouble computing sine and cosine:
And the Mac port of Wolfenstein 3D, which uses SANE and floating-point math because it has to deal with higher screen resolutions than the PC original, put you in the middle of some decidedly weird geometry:
But on my work-in-progress code, sine looks like reality (matches the ARM Linux version of Basilisk II, which uses the GNU MPFR soft floating point library).
Further fixes to the FPU emulation have fixed what I believe is one of the longest-running bugs in MAME's Mac emulation. Reported in 2014, and verified to be present in builds back to 2012, MAMETesters bug 5411 has finally been slain.
It involved re-porting the decompression code over from Ares and including the appropriate license text in the comment block, but, Far East of Eden zero boots now:
Continuing our series of "fixing really old problems with the Mac drivers"...
...the keyboard and mouse now work on the Mac Portable and PowerBooks 100, 140, 145, 160, 170, 180, and 180c. That just means we get to find out that there's other things wrong with those systems. But it's an important start.
Having gotten ADB (keyboard and mouse) comms working through the "IOP" 65C02 coprocessor on the Mac IIfx, I went ahead and applied that knowledge to the Quadra 900 and 950, which are basically a Quadra 700 with the IOP coprocessors added and a second 53C96 SCSI controller and bus, so you can have 14 SCSI devices total if you get the termination right ;-)
Both machines boot and are usable but the floppy drive (which also runs through an IOP) isn't working yet and there are probably a few other gremlins to shake out around the IOPs.
Still a bunch of gremlins to shake loose, and the current state of things is pretty hacky. Before I even start to think about wrapping this up into a pull request, I should put the "different amount of clocks per scanline" functionality into a subclass of screen_device, among many other things.
There's also perpetual screen-tearing, as the actual screen_device is no longer synced to when scanlines are actually refreshed. That should go away once I have a screen_device that gives actually valid timings.
The Macintosh IIfx uses a custom SCSI chip that's a licensed NCR 53C80 IP block with a bunch of stuff added to allow it to DMA directly to anywhere on a 68030 bus. It also has hardware handshake "pseudo-DMA" like other 68K Macs.
However, no version of the Mac OS that runs on this model (6.0.5 through 7.6.1) actually uses the DMA mode. So I ended up spending a lot of effort writing and debugging a device that ends up not doing much. That means this machine ends up having DMA for the floppy drive but not SCSI, which strikes me as pretty funny.
In any case, maciifx now passes all of my test suite to promote a 68K Mac to working so that means every desktop 68K Mac ever shipped now works except the Quadra 660AV and 840AV. Another 13 year old loose thread finished up.
A/UX doesn't like MAME and I haven't taken a serious dive into why yet. There is code in the SuperMario tree to use the DMA with VM, but it never shipped, presumably due to bugs.
Good news: The folks in Panic Park's flower shop won't get rained on anymore. Not completely sure how the texture lookup or brightness works, but the geometry seems to be A-OK:
Spent the weekend making some improvements to PIXXIII, the Namco System 23 graphics analyzer that I've been developing off and on for a while. The hope here is that it should make debugging System 23's graphical issues easier by not having to constantly re-run games and wait through POST.
Since test cases are still a bit thin on the ground, I spent most of my time adding a model viewer - what better way to get immediate access to all static models and their render settings?
However, I also made some quality-of-life improvements: Matrix Set, Vector Set, Matrix/Matrix Multiply, and Matrix/Vector Multiply now indicate which indices are used, and the commands themselves have their own info panes. The former makes it easier to see at a glance where the matrix and vector data for a given render call comes from, and the latter makes it easier to see the data in a more presentable format.
Oh, and I realized "immediate-mode" geometry (notably different from the "direct poly" functionality retained from System Super 22) can vary in format. Triangles are used for the roof of the Vase Panic mini-game in Panic Park, but quads are used for portions of the horses in Final Furlong. Encyclopedia Brown and the Case of the Equine Limb Thief has finished. I still haven't worked out texturing, so it looks like the horses are wearing magenta underwear, but, whatever.
After a bunch of effort and a final kludge to make the main MIPS happy by returning a specific value from a specific location in the GMEN board's SH-2's shared RAM area, Gunmen Wars and Final Furlong 2 boot. Gunmen Wars makes use of some commands that hadn't been seen on any other games, namely command 0x2x and 0x3x to do a Matrix * Immediate Matrix multiplication, or a Matrix * Immediate Vector multiplication, respectively. There are still some issues with the handling of at least one of the math commands, as the characters themselves seem to be invisible.
Final Furlong 2 seems to be the first game aside from Time Crisis 2 (so far) to use the hardware's texture RAM for what it increasingly appears to be intended for: 1-bit texture alpha, as I don't think the hardware has support for variable alpha per-poly otherwise. Time Crisis 2 uses it for character names in attract mode, but Final Furlong 2 seems to use it on actual geometry.
There's also some texture warping whenever polygons extend behind the camera and need to be clipped. I suspect this has to do with the texture coordinates being clipped prior to the Z-divide, but so far I haven't had much luck in making things better by changing when Z-clipping occurs. Maybe this weekend will be my lucky break.
... which also implicitly includes Basic Master Level 2 support:
Beyond the inufuto SWs there's not much else available to test here: best thing you can otherwise do with the (infamously known as bad) Basic parser is fiddling with MUSIC commands in katakana. And not that the HW itself has all that many SWs or bus options to begin with ...
With -frameskip 10 -nothrottle -window -nomax -video d3d it takes under five hours to boot in a debug build on my Coffee Lake i7 notebook, compared to over five days on real hardware.
edit: This was a reply to a comment that was deleted.
With -frameskip 10 -nothrottle -window -nomax -video d3d it takes under five hours to boot in a debug build on my Coffee Lake i7 notebook, compared to over five days on real hardware.
edit: This was a reply to a comment that was deleted.
Apologies, I deleted my earlier comment as I saw it was already being discussed in the ShoutChat window. A very impressive technical achievement though, on top of another very impressive technical achievement
The original Task Force Harrier MCU has a manufacturer's sticker covering its label, but I believe it's probably a Mitsubishi M50747, as on the Jaleco/NMK/UPL mahjong games from the same period.
Namco helped me debug some graphical issues that were affecting 500 GP, and to a lesser extent Race On! and Gunmen Wars.
[video:youtube][/video]
For real, though: After having fixed an issue with C361 IRQs, having some of the "Unknown" DIP switches flipped when starting Race On! causes it to drop into this menu instead:
Tamura's Menu is one of the more useful ones:
...Because of its Texture Viewer page. Before/after.
If you can't beat Haze with the Plug-and-Plays, join him! Hammy dumped Chusenoh, a 1992 Konami plug-and-play mini-console with a small selection of gambling-adjacent mini games including a slot machine, a bingo randomizer, Rock-Paper-Scissors, fishing, and golf. It turns out to be lightly modified konmedal.cpp hardware (Z80 + GX tilemaps + SCC and OKI 6295 audio). If you had an EPROM emulator one of these units would be an entertaining way to run experiments on the K054156/K054157 pair, but that's a pie-in-the-sky idea.
[video:youtube][/video]
User-friendliness on this isn't the greatest - there's a dedicated button on the back that flips modes between a menu of the mini games and actually running them, plus a separate switch for a full arcade-style test menu with all the Konami favorites (even a sound test). And I have no idea what you're actually supposed to do in the fishing mini game, as you'll see in the video.
My understanding of these from what was said previously is that they weren't really designed or sold for home use, but for venues/hotels etc. to provide customers with entertainment devices if they rented out rooms for events etc. definitely a weird rabbithole.
Yes, they are "rental" systems that are available to go to party's etc. for gambling "events". There are still some places that will lease them out. There is a few others including a PSX based one, they come up for sale from time to time but shipping on them is a killer from japan due to the weight.
Nice to see you have it up and running already
It should be easy to hook it up and run test roms and stuff... but i have no workshop at the moment to do anything like that for now...
The keypad is only required to play the minigame with the treasure chests (unclear what game that actually is given the demo screen for it just plays music and the keypad isn't working yet). Setup mode is fully navigable with just the buttons on the unit as far as I can tell, but it's also 100% Japanese so I have no doubt I'm missing some things. Holding my phone up to the screen for machine translation is not optimal :-)
Modern "SCSI Emulators" like ZuluSCSI and BlueSCSI support custom SCSI commands that allow the machine to directly access files on their underlying media (usually an SD Card), rather than just seeing an HDD or CD-ROM image as an entire drive, which is how you usually use those devices. This lets you get files in and out of the machine easily, and now it can help you get files in and out of emulated systems in MAME. Software is available for the classic Mac OS, Amiga, Atari ST, MS-DOS, Windows 3.x and 9x, Windows NT 3.x and 4.x, SGI IRIX, and NeXTStep. As long as your emulated system uses nscsi for its SCSI interface you'll be able to use this.
This uses the shared folder I introduced a while back for the CH376 device. Any files you put into the share_directory you've configured in mame.ini will be visible to the software running inside the emulation and can be 'downloaded' right into the emulated system. Some clients also support uploading a file from inside the emulated machine to appear out in your share_directory.
Here's some example screens from the Mac, using an open source client called scuzEMU developed earlier this year.
The list of files in my share_directory:
Selecting one for download:
The transfer itself:
And then we un-stuff the file and hey, a new game inside the emulation in record time!
The closed source clients from BlueSCSI work fine too, because I made MAME return the ridiculous "BlueSCSI is the BEST STOLEN FROM BLUESCSI" magic string on the appropriate mode page. I think the BlueSCSI team doesn't entirely understand the F/OSS ethos given that they're a GPLv3 project that relies heavily on other GPLv3 projects, but what can you do.
Will this only be in 0.272? I've just added the share_directory option to my mame.ini file and started the Apple Mac Quadra 630 driver with System 7.6 but I don't see the folder in the emulation.
Will this only be in 0.272? I've just added the share_directory option to my mame.ini file and started the Apple Mac Quadra 630 driver with System 7.6 but I don't see the folder in the emulation.
A quick look here - https://github.com/mamedev/mame/commits/master/ - indicates that the changes have not yet been pushed. Which is fine; this is the Work In Progress (WIP) thread, after all.
The file transfer stuff landed for 0.272 (or it's in top of tree if you build yourself). It's built into the base SCSI CD-ROM device so many systems will get it automatically. This also facilitates my next trick, supporting the additional commands so that software inside the emulated system can mount CD-ROM images.
Here's some MAME-recognized CD-ROM images in my share_directory:
I've added support for the RIPPLE IDE controller for the Amiga 2000/3000/4000. It's a modern controller supporting drives up to 2 TB and also allows booting from CD-ROM. Here's a screenshot where I've hooked up a 40 GB CHD:
This is using Amiga OS 3.2.2 as the original versions from Commodore or Amiga Technologies don't support drives as large.
You can also update it's firmware from inside MAME:
Oops, I did it again: the PowerBook Duo 210. A sub-notebook that was designed to slot into a dock (with motorized insert and eject, of course). The dock adds the usual stuff: slots, video output, connectivity to a full-size keyboard and mouse, etc, etc.
These machines (and all further Mac portables until 2000) are based around the "PG&E" power manager chip, a custom 65HC05 based microcontroller with 160 pins. That's 11 8-bit GPIO ports, analog inputs, analog outputs, hardware SPI, hardware Apple Desktop Bus, a hardware quadrature decoder, a hardware keyboard matrix scanner, timers, and pretty much the kitchen sink. Due to the complexity of this thing it's still a ways from anything I wouldn't call NOT_WORKING, but at least you can boot an OS and use the quadrature decoder to move the mouse pointer.
After adding a Zorro-II sound card, why not a graphics card? I tried adding the Picasso-II card, which is a real graphics card using the CL-GD5428 VGA chip, however it seems that it exercises the chip much more than we can currently handle. Kale also had a look and he made it show at least a (slightly garbled) test screen.
So I've taken a step back and looked at something easier: A simple framebuffer. A few of those were available for the Amiga, and the Rainbow II (or FrameMaster) was quite straight forward:
This shows the "Diashow" tool. It can be controlled using ARexx to show a gallery of pictures.
This is the "RainbowPainter", a simple image editing tool.
Since we don't emulate any CPU replacement board yet, I had to cheat a bit and put a 68020 CPU with FPU into the A2000 because the software requires the FPU (probably for JPEG decoding).
So the reason we didn't have this 5 years ago is that the DRC doesn't report unhandled opcodes, it just throws an illegal instruction exception inside the emulated system. I finally figured that out, and it turns out that in spite of copious warnings from Apple not to use the leftover POWER instructions that the 601 still supported (but the 602/603/604 don't), the ROM for these first-generation PowerMacs is positively full of them. I implemented about half a dozen POWER instructions in MAME's PowerPC emulator and things started working.
I finally figured that out, and it turns out that in spite of copious warnings from Apple not to use the leftover POWER instructions that the 601 still supported (but the 602/603/604 don't), the ROM for these first-generation PowerMacs is positively full of them.
It makes sense, though. They didn’t want applications using POWER instructions or depending on the POWER MMU because they’d be incompatible with the next generation of CPUs that dropped POWER instruction support and switched to the PowerPC MMU. On the other hand, the ROM in a 601-based Mac could safely assume it was running on a 601.