Question Mark Disk
Now I’m really getting somewhere with Plus Too: it’s the “question mark disk” screen! If you ever owned a Macintosh with no hard drive, you’ll be very familiar with this screen, because it was shown whenever the computer was turned on. It’s the Mac’s way of saying “please insert a system disk.” It means everything is OK, ready to go, but it needs an operating system disk to proceed further. Here’s another photo, this time showing the entire screen:
The mouse pointer appears in the upper-left. With a bit more work, I should be able to move the mouse around while on this screen.
The green text at the bottom of the screen is my primitive on-screen debug interface. Because the pixel-doubled 512 x 342 Mac desktop is only 684 pixels tall, there’s some extra space above and below it when running at 1024 x 768 SVGA resolution, and it’s the perfect place to show debug data. The green text isn’t drawn by the Mac (which after all can only do black and white), but by the video output circuit in the FPGA. There are effectively two video sources which it combines: one from the Mac screen buffer, and one from the debug interface. The debug text shows the current CPU address, data in, data out, address strobe, data strobes, previous address, and breakpoint address. The breakpoint address can be modified by setting the positions of switches on the Altera DE1 board, and pressing a button to load the low, middle, or high byte of the address. Crude, but it’s better than nothing.
Thus far I’ve actually implemented very little Mac-specific hardware behavior, so it’s suprising that it gets to the question mark disk screen. The implemented hardware is:
- 68000 CPU (synthetic soft-CPU in the FPGA)
- 128 KB ROM from Mac Plus (in external Flash ROM)
- 512 KB RAM (in external SRAM)
- address decoder maps ROM to $400000 and RAM to $000000
- IWM floppy controller always returns $1F when read, and otherwise does nothing
- Reads from address $FFFFFx return 24 + x. This makes interrupt vectors work correctly.
- VIA is partially implemented: vblank and one second interrupts work, the interrupt enable and flags registers work, and the memory overlay bit works.
- Video circuit reads from a hard-coded frame buffer address of $3FA700, which wraps around to the correct address in the 512 KB RAM space.
That’s it. There’s nothing whatsoever for the keyboard, mouse, disk, sound, or SCC, and the VIA is only about 25% implemented. I did have to cheat a little to reach the question mark disk screen: there’s still something wrong with my interrupt flags, and I had to flip a switch a few times to manually enable and disable interrupts. Without my intervention, it stalls indefinitely on a black screen. Hopefully the interrupt problem will be simple to fix.
Reaching the question mark disk screen is great, but it’s sobering to realize that getting further will probably require an order of magnitude more work than I’ve done so far. That’s because it will require implementing the IWM behavior, as well as the behavior of the floppy drive itself, and the lowest-level bit-by-bit data representation on a floppy disk. On the other hand, once I do get past this screen, I should be most of the way to having a working Mac clone.
Read 9 comments and join the conversation
9 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
This is starting to look very promising! Any chance of this becoming something you could release a kit for? I’d be interested 😛
Everytime I see your photos all I want to do is move that pesky pen pot out of the way; hehe.
Fantastic project; I look forward to reading each update; Can’t wait till we get to see the desktop load and it’s running applications.
I’m not sure about a kit, but I’ll look into it. My fear is that anything containing the words “Mac Clone” would be pursued by Apple’s legal department, even if it were a bring-your-own-ROM board for a 25-year-old computer.
Steve, just call it a “Working Mac Replica” then.
Let rename it to McPapirovka instead of Mac-something.
Papirovka is “early paper apple” and you are now at the early paper stage. “Polish paper apple” is the other common and good name as the project needs more polishing :-).
BTW I am writing from Poland so I know what Papirovka is…was…as it is almost impossible to buy it nowadays.
They are very early apples, light-green, very sour and….mmmmmmmm…delicious.
Hi !
Just discovering your plustoo. I’ve been doing something similar during the last couple of years. I have very very little time to dedicate to it so it’s not making much progress, but feel free to take a peek and borrow bits & pieces.
Announce was:
http://www.minimig.net/viewtopic.php?f=6&t=411&sid=11d444d3ba2e56364fe1e38d761f6f24
And “code” is at:
http://git.ozlabs.org/?p=minimigmac.git
I have ps2 mouse & kbd to the macplus “stuff” working as well and SCSI via the SPI interface to the PIC.
Feel free to peek, borrow, comment, or contact me if you have questions. I have literally no time to work on this at the moment.
If you are interested, I also know how to “emulate” the IWM floppy (did some experiments in SW using an existing emulator as a basic and ripping out the fake floppy driver to do real emulation), tho I haven’t written any logic to do the same on FPGA yet.
Cheers,
Ben.
Thanks Ben, another poster pointed me to your project last week, and it’s good stuff. Very impressive! It sounds like you had the whole thing basically working? I’ve been looking at your VIA and IWM to make sure your interpretation of the docs matches mine. I want to avoid outright copying of your design modules though, since then I wouldn’t learn anything, and puzzling things out for myself is most of the fun. 🙂
I understand the feeling, this is a learning project for me too 🙂
IWM is really rough for now, but if you email me (my email should be easy to find) I’m happy to reply with the SW model I did for emulating the floppy in the PCE emulator, this can then be used as a basis to actually do it in HW which I haven’t done yet.
The thing on my side is basically working with SCSI (over SPI, the PIC does the actual SCSI command interpretation using the SD-CARD disk images), except that there’s an odd issue where sometimes, when “hot” it starts mis behaving (as early as the ROM checksum fails), either that or some bad/missing constraints causing ISE to sometimes generate something that doesn’t work.
I’m not quite good enough (it’s all self learned, I’m not a HW engineer at all) at this point to properly figure out what’s wrong, at least not easily, and have too little time to really work on it at the moment anyway.
You might still want to look at some of my comments in the address decode module tho 🙂 There’s some bits that took me a while to figure out 🙂 Like why the ROM didn’t see the SCSI controller … well, it checks of the ROM itself wraps or not. Fun stuff like that.
[…] command-option-escape Posted on 07/25/2013 by married to an alcoholic source: http://www.bigmessowires.com/2011/09/18/question-mark-disk/ […]