Plus Too: a DIY Mac clone project (128k -> Plus)

[Gorgonops]

Just to note, the VIAs are still fairly readily available. (And still being made. I have two brand new ones acquired as spares for Commodores.) I was sort of picturing a hybrid approach where parts like the IWM would be replaced by bit-banging microcontrollers but the core of the system is "real".

Again, using an FPGA is more practical for a system of this scale, but it does sort of raise the question of why you need to build hardware at all, instead of "just" writing an alternative core for one of the pre-existing Amiga or Atari ST-in-an-FPGA boards.

 

[olePigeon]

I'd like to make a recommendation for a followup project: Freescale ColdFire upgrade.

 

[trag]

Right now I'm using the Spartan 3A FPGA starter kit from Xilinx. All the other "hardware" is actually synthesized inside the FPGA: a 68000 soft-CPU (TG68 core from opencores.org), 32K RAM, and 8K ROM. The synthetic RAM/ROM sizes are much too small, but are all that would fit inside the FPGA.

Heh. If you had the Spartan 3AN Starter Kit, you'd have something like 700K of ROM available on board the FPGA.

Those block RAMs really don't add up to all that much RAM, do they?

If you want to use the DDR2, I would start with the demo that Xilinx has available. I don't know how hard that is to get up and running, but it seems like the logical starting point. Programming your own DDR2 controller would be a ridiculous amount of work.

And on the Starter Kit it's 16 bits wide, so the width is just what it should be. Gonna be a lot of wasted transactions, with the DDR2 insisting on doing 4 word bursts for every transaction though...

Maybe add connectors for vintage keyboard, mouse, serial, and even floppy if I can find a source for DB-19's!

I posted a source in a new thread on this forum.

well with the JIT soft-core running on the FPGA

It's actually not a JITter, but a full-fledged 68000 realized from the "sea of gates" of the FPGA. So there's no emulation or dynamic recompliation involved. It's basically exactly the same as having a real 68000, just internal to the FPGA.

What is "JIT soft-core " and how does it differ from what you implemented.

Did someone run off with the designs from Motorola, or is the FPGA 68000 design reverse engineered from the 68000's behaviour?

 

[Gorgonops]

What is "JIT soft-core " and how does it differ from what you implemented.

JIT = Just In Time (compilation). It's a method of speeding execution of interpreted languages (and emulators, since one CPU running code for another is broadly the same thing as running an interpreted language) by compiling snippets of code into native equivalents in psuedo-real (just in) time and caching the compiled version for later use when appropriate.

In the context of emulator software the word "core" could refer to the software component that emulates *any* part of the emulated system (like a chipset) but without modifiers usually means the CPU emulator. And many emulators allow the user to choose between several. Modern builds of BasiliskII on x86, for instance, generally have a "JIT core", which itself has several performance-enhancing options that can be turned on and off, alongside a much slower interpretive core which persists as an fallback in case one encounters a bug with the JIT core. (JIT cores are "hard", and tricks like self-modifying code can break them.)

"JIT Soft-Core" is thus meaningless in the context of an FPGA because an FPGA isn't a "CPU" with a native instruction set. It's basically a huge pile of electronic tinkertoys that can be interconnected according to a "meta-code", VHDL or Verilog, that has nothing to do with the normal operation of the chip once it's programmed. (Once the FPGA is programmed it's not "emulating" the chips it's coded for, it in essence *is* the chips.) An FPGA "core" is a collection of code that describes to the FPGA how to connect its tinkertoys to make a working copy of another chip, and for a given CPU or other IC there may be multiple "cores" floating around which incorporate different trade-offs. For instance, one core might uses less gates than another, thus leaving more space on the FPGA for other things, but the tradeoff may be that it can't be clocked as high. Another case may be that for a given CPU there exists a commercially licensed version which is "guaranteed" to perfectly replicate the real thing, unlike a free reverse-engineered open-source version.

 

[Gorgonops]

Just as a random note, I don't know if it would "help" at all, but apparently you can get a preassembled "MiniMig" board with 2MB of RAM for about $180 US. (4MB is another $30.) That actually looks cheaper than a suitable starter kit and might be a good platform to develop on.

 

[bigmessowires]

Writing an alternative Mac Plus core for a pre-existing Amiga or Atari ST-in-an-FPGA board would be one way to go, but seems less fun, since I like to build stuff with my hands. Nevertheless I'm starting with this Spartan 3A board (and soon an Altera DE1 board) that's not too different from those Amiga boards, because it's the easiest way to get started. Once things are mostly working there, I plan to create a custom board that eliminates any uneeded parts, adds vintage keyboard/mouse/floppy connectors, and incorporates any daughterboards I made for a microcontroller or other stuff. At that point it would also be possible to extract the 68000 and maybe VIA out of the FPGA, and add them back as real chips for extra style points.

It's basically a huge pile of electronic tinkertoys that can be interconnected according to a "meta-code", VHDL or Verilog, that has nothing to do with the normal operation of the chip once it's programmed. (Once the FPGA is programmed it's not "emulating" the chips it's coded for, it in essence *is* the chips.)

That's a good way of putting it. The Verilog code determines the configuration of 40-bazillion internal interconnections between 20-bazillion primitive logic gates on the FPGA. The configuration data is like a tremendous number of switches, or like the plugboard configuration panel on early computers like Univac. Each switch can either connect two specific wires inside the FPGA, or leave them unconnected. After that, it's the same as if you'd soldered up all those primitive logic gates by hand, and it really *is* the chip described in the Verilog code. This stuff is fascinating, and if you're into digitial electronics, it's like sex on a stick. And to trag's question, I'm pretty certain the TG68 68000 core I got from opencores.org is reverse-engineered from the known behavior of the real 68000.

 

[Gorgonops]

This stuff is fascinating, and if you're into digitial electronics, it's like sex on a stick.

Somehow I don't think it would be a good idea to do a Google image search for "sex on a stick". ;^)

FPGAs are incredibly fascinating to me, but I'll freely admit I'm far too stupid to work with one. My eyes are starting to glaze over a little bit just trying to draw a decent schematic for an idea for a clip-on MMU/memory expansion add-on for a Commodore PET, and that would only require about eight chips.

 

[Gorgonops]

Random link:

Don't know if it'd be useful since it sounds like you're using Verilog instead of FHDL, but... here's a source for a 6522 core:

http://www.fpgaarcade.com/vic20_main.htm

 

[Bunsen]

Kind of related, the following all use a Parallax Propeller multi-core microntroller for glue logic and interfacing:

6502 laptop

pPropQL: A Sinclair QL clone. MC68008, 68020 and 68040 versions.

 

[bigmessowires]

Some more progress-- it's now booting up to the question-mark disk screen, with the mouse cursor in the corner of the screen.



http://www.bigmessowires.com/2011/09/18/question-mark-disk/ if you're interested in more details.

 

[Trash80toHP_Mini]

Very cool!

I was wondering why you're worried about about finding DB-19s and other ancient connectors? :?:

How about using whatever is available currently, whether it's the right pin count or not?

I like the notion of using an ASCII Keyboard interface for one.

I've used a CrapShack M<->F DB-25 jumper unit cut down to DB-15 as a Portrait Converter for a TPD cable, the same ought to be possible if you ever really NEED to hook up a real Mac FDD.

 

[dougg3]

That's awesome! Nice work! In a very short time, too!

FPGAs are just amazing. They are still kind of mind-boggling to me, but I really want to learn more about them! Cool stuff.

 

[techknight]

you could implement an ADB driver, and use an ADB keyboard/mouse, or use PS/2 keyboard/mouse, but of course either of these solutions requires a translator of some sort, if you implement the keyboard/mouse hardware exactly as laid out originally, unless of course you emulate the side the ROM/CPU wants to see, and the other side use the PS2/ADB protocol.

 

[LCGuy]

That is beautiful. :O

 

[bigmessowires]

Fortunately the Mac Plus doesn't use ADB, so the mouse is pretty simple. My plan is to start by simulating mouse interrupts with buttons on the board, just to make sure it's behaving as expected. Then I'll make a PS/2 mouse module in the FPGA that receives mouse data and creates fake mouse interrupts. When I make a custom board later, I'll put a DB-9 on it so you can also connect a real M0100 mouse.

 

[Trash80toHP_Mini]

There are two versions of the Plus, the Beige version with classic Macintosh Peripherals and the Platinum version, using ADB peripherals, a larger ROM and the 800k FDD, IIRC.

The later version was manufactured and documented along with the SE/Mac II generation.

 

[LCGuy]

The Beige and Platinum Plus's were completely identical as far as hardware is concerned. All Plus's had the 128k ROM (allowing for use of 800k floppies, with a built in 800k FDD) No Plus ever had ADB - they all had the RJ-12 keyboard and DB-9 mouse.

 

[PowerPup]

That's awesome bigmessowires. And what a coincidence, my classic II is showing that screen again. (It does that occasionally, I think the 230MB Drive is dying.)

Watching your progress on the Plus Too is so inspiring. Makes me think about the kind of things I could try when I learn enough. (As if there's such a thing!)

I'm very excited about college this quarter because I'm taking my first programming course, "Programming Fundamentals." This will be the course's textbook. The only thing I've done with programming so far is read some programming books and maybe compile their examples. But I've never really gotten further than that because for me I need an actual project with a personal goal. (The way I taught myself HTML, JavaScript and currently PHP.) And I haven't come up with any ideas that can work with just the console. (Eg, an APNG editor.)

That's also why I'm eager to teach myself programming on the Classic Macs. You learn to program the interface instantly. No "learn the console, then find a GUI library you like and learn that." I still kinda need to find myself a goal to get started, but I'm researching one idea that looks promising. (Making a basic Stunnel clone, kind of like this.)

Anyway, I'll probably stick to software as my career. But I definitely want to dabble with hardware in the future, like some of the stuff you do.

Keep up the awesome work!

 

[Trash80toHP_Mini]

The Beige and Platinum Plus's were completely identical as far as hardware is concerned. All Plus's had the 128k ROM (allowing for use of 800k floppies, with a built in 800k FDD) No Plus ever had ADB - they all had the RJ-12 keyboard and DB-9 mouse.

OOPSiE! :I I was going by 11 year old memories, I would have sworn that the Plus a friend loaned me for a project had ADB.

Thanks for correcting that error! :-x

 

[Gorgonops]

Kind of related, the following all use a Parallax Propeller multi-core microntroller for glue logic and interfacing:

Just as an aside, I've been looking at those projects very seriously because of an idea I've had for a homebrew 6502-based computer, and unfortunately the conclusion I've come to is that while the Propeller works as a glue/peripheral chip like that it's non-trivial to achieve "cycle-accuracy" with it. (A link to add to yours would be the "Propeddle", which is essentially an enhanced version of the 6502 laptop design targeting Commodore PET emulation:

http://www.savagecircuits.com/forums/showthread.php?677-Propeddle-Software-Defined-6502-Computer

) Anyway, if you dig into the "pPropQL" design theory you'll see that, for instance, interfacing the Prop to a 68000 as "memory" requires the insertion of a substantial amount of wait states. The Macintosh OS as written is so timing dependent I don't know if you could really get away with it. (At least if you're attempting to do things like use "real" floppy drives or the serial controller. If you're emulating those devices then dealing with the "clock skew" would probably be doable.)

On the subject of emulating the IWM I'd probably suggest it's sort of pointless to include a 19 pin floppy connector, if only because the original drives are getting so rare. (And troublesome in their old age.) Is the ultimate target of the design to produce a board that's physically compatible with the original PCB, with all the same ports in the same places and allowing the use of all the original parts and peripherals? (Of course, that would either require the ports be carried on a daughterboard or that multiple versions be produced to fit either the 128k/512k and Plus cases, respectively.) I'd worry about the ultimate cost of something like that, as when I last checked the commercial version of the Atari-ST-in-an-FPGA board that includes legacy ports was nearly $600.