Apple IIc Plus emulation - MIG implementation incorrect.

[mgcaret]

The (non-working) Apple IIc Plus ("apple2cp") emulation implements the MIG incorrectly.

Reading the source (src/mame/machine/apple2.cpp and src/mame/drivers/apple2e.cpp), I ran across the comment at line 2208:

/* there appears to be some hidden RAM that is swapped in on the Apple
 * IIc plus; I have not found any official documentation but the BIOS
 * clearly uses this area as writeable memory */

Further poking, it appears the implementation appears to be a straight 0x200 bytes of RAM mapped into the aux firmware address space at 0xCE00. This is incorrect.

The 0x200 bytes at 0xCE00 (it is also mirrored at 0xDE00 in the real machine) in the Apple IIc Plus auxiliary firmware bank memory space is allocated to the MIG chip. The MIG chip controls access to a 2K SRAM chip and some of the 3.5" disk port signalling.

The memory map of the MIG:

0xCE00-0xCE1F read/write = 32 byte paged window into the 2K SRAM. 0xCEA0 read/write = set window page to 0. Data read is floating bus. 0xCE20 read/write = increment window page, wrapping around after the 64th window. Data read is floating bus. Other addresses: unknown, but the firmware accesses several of them in the code that controls the smartport/3.5" disks. Reads as floating bus.

All of the above are also decoded at 0xDE00 in the aux firmware address space.

The MIG SRAM is used by the 3.5" disk code and the accelerator code. In the current implementation, the various bits of firmware that use it would stomp all over each other. In particular, the SRAM is initialized/re-initialized by the firmware at reset.

I believe the emulated system does not boot because the firmware is rather confused by the mis-implemented hardware.

While the 3.5" disk signalling remains a mystery, it may manage to boot if the emulation is corrected to implement the MIG as per above.

I'm not skilled enough or familiar enough with the MAME architecture, I have the real hardware to test against and I am familiar with a lot of the firmware.

[rb6502]

Thanks, that's very interesting! The IIc Plus is kind of the forgotten Apple II, and as far as I'm aware it's not very well documented officially.

As far as the disk, from what I've seen, the firmware is attempting to communicate with the 3.5" drive via SmartPort packet commands or something very similar. But the drive itself is not intelligent like the UniDisk 3.5 so the MIG chip is somehow doing the translation into IWM-style drive-control signals.

Any other insights or thoughts you have about the IIc Plus I'm all ears.

[rb6502]

Also, if your ROM 4X doesn't work in MAME, let me know. I went to some length in the new driver to make the IIc behave like a real IIc rather than just a malformed IIe, and it passes all of Apple's diagnostics. The built-in mouse works, the vblank IRQs work, AppleWorks can see the memory expansion, etc.

The machine/apple2.cpp code is deprecated; it exists right now only for the IIgs driver. All the 8-bit IIs run inside their drivers (drivers/apple2.cpp and drivers/apple2e.cpp).

[mgcaret]

Cool! I haven't tried to get MAME to execute a custom ROM yet, but that's part of the reason I submitted this... there's no working IIc Plus emulation and so working on my custom ROM for the Plus is a very tedious process. I hope what I've learned will help to fix that, bringing the machine to a basic, if not complete status for all, including myself, to enjoy.

I've been slowly working my way through disassembling the unknown bits of the IIc Plus firmware. I've got a complete commented/analyzed disassembly of the accelerator code (which is seriously buggy!) and started on the 3.5" disk code.

The 3.5" code handles both SmartPort protocol and the dumb 3.5" drives. The main SmartPort code is mostly shared with the //c. The dumb 3.5" code throws a lot of data into the MIG, I have very little of that figured out yet, though some is obvious such as the block number that was accessed and such. The bulk appears to be disk nibbles, but there are "too many"... so I suspect the firmware's strategy is to dump the raw sector data as fast as it comes in, and then reassemble it from there. It would explain why the IIc Plus's internal drive is so slow.

Here's a program I wrote that accesses the MIG RAM and displays what's in it, should serve to demonstrate the basics of how the device is used for the 2K RAM: https://gist.github.com/mgcaret/d4b68f3924bc9bc8349bdc05a4ea9545

Apple IIc Plus accelerator code, shows one way that Apple's firmware uses it: https://gist.github.com/mgcaret/022bd0bb3ee71f28429972523556416e

[rb6502]

I've added MIG RAM windowing in commit e1f5df74b040c28a98daa2abfbc7c5c9ebba856f. Doesn't help it boot more (it still hangs waiting for something from the IWM) but I'm pretty confident it's correct.

[mgcaret]

If I can figure out how to get MAME to use a custom ROM, I will try to validate the behavior vs the real hardware.

[rb6502]

Replace the ROM it's using in the zip with a replacement with the same name. It'll complain about the hashes mismatching but it'll run.

[mgcaret]

Yeah I figured that out last night, patched around the smartport initialization and got it running in a rudimentary fashion. I’m hoping to coax it into booting a disk image, but there are several cases where the system lands in the same 3.5 code and waiting for the IWM.

It led me to wonder about some other things about the firmware, that I will need to test against the real hardware.

[mgcaret]

Ahh it looks like the MIG RAM size is still only 0x200 bytes, it should be 0x800 bytes.

[rb6502]

Ahh, OK. Will fix that.

[rb6502]

MIG RAM size is corrected in top of tree, still doesn't help it boot. I think we're going to need to disassemble the disk firmware.

[mgcaret]

That and I need to get my scope onto the MIG's pins and see what memory accesses play with which signals.

Aside from the 2K RAM, the MIG also controls internal drive selection, HDSEL and 3.5DISK, and can also selectively reset the IWM according to the schematic. The place that gets stuck in the firmware is right around several of the accesses in the MIG address space that I am all but sure do something with those outputs. The IWM reset might be particularly important.

I did get the system to the point I could get a BASIC prompt, and loaded my MIG inspector program via the debugger (I've never played much with MAME before... I'm starting to become a fan). So at least there's that.

[rb6502]

Sounds like the MIG handles some of the stuff done by loose logic in the IIgs, which also has HDSEL and 35SEL registers.

The MAME debugger is a lot of how we managed to reverse-engineer a lot of undocumented arcade PCBs over the years. It's not perfect, but it's quite handy.

One completely unexpected thing someone's been doing is driving the Apple II from a Lua script, as seen here: http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=110868#Post110868

[mgcaret]

I have noted some other behavior differences between MAME's //c and IIc Plus emulation vs the real hardware. I can open separate issues, we can discuss here, or even privately at your option.

I was motivated to scope the MIG last night. I did manage to narrow down some of (formerly) unknown accesses to specific signals, but others I did not. I suspect that the MIG detects motor on/off or some other condition of the IWM before allowing some of them to be set, as it has an input on pin 11, /EN2X that indicates a $C0nx access.

[rb6502]

Separate issues is fine.

[mgcaret]

In that case, this can probably be closed... but I do have one question before I submit anything else... the IIc emulations appear to support the Slinky memory expansion card, but it doesn't appear to be enabled by default. How do I make it work?

[rb6502]

Use the -ramsize parameter. It defaults to 128K (base IIc) but on Slinky-capable IIc drivers it also will accept 384K (128K base + 256K Slinky), 640K (512K Slinky), 896K (768K Slinky), or 1152K (1024K Slinky).

If you want to discuss non-bug issues about the Apple II emulation or things you'd prefer not appear in public, you can email me at messdrivers [at] gmail [dot] com.

[mgcaret]

Thanks!

[mgcaret]

FWIW, the following patches to the Apple IIc Plus ROM image will make it start in MAME by patching around the 3.5" disk support...

Offset 0500:A2 00 A9 C6 86 00 85 01 6C 00 00 ; make slot 5 boot go to slot 6 boot Offset 05F8:60 ; patch out 3.5" disk initialization at reset time Offset 061A:BD 89 C0 ; remove apple patch that twiddles the MIG an IWM before booting 5.25" drive.

Unfortunately, the lack of 5.25" drives in the IIc Plus emulation (or I can't figure out how to enable them) doesn't let me actually boot a disk. Also noticed that the memory expansion isn't implemented in the IIc Plus emulation.

I've also made some additional discoveries about the MIG. I've documented them here: http://apple2.guidero.us/doku.php?id=mg_notes:apple_iic:mig_chip#mig_address_space

[leonbottou]

I believe I figured the MIG out. At least well enough to make it work in a variant of the KEGS emulator. See https://github.com/leonbottou/kegs-universal

In case it helps...

• L.

[rb6502]

Thanks @mgcaret and @leonbottou, the IIc Plus can boot 3.5" disks in MAME now, and I've enabled the built-in memory expansion as well.