Among this crowd, it’s safe to say that the original 68000 Macintosh computers need no introduction, but it’s possible some of you aren’t familiar with Chip8. It was an interpreted virtual machine originally created for the COSMAC VIP microcomputer by [Joe Weisbecker] way back in 1977. It enabled coding simple games on the COSMAC VIP without getting into machine code on the VIP’s CDP1802 processor. For the obvious reason of “Why not?” [KenDesigns] decided to put the two together with Chip4Mac68000, a Chip8 emulator for the original Macintosh.
Chip4Mac68000 is not actually a Macintosh program; it doesn’t run in the System Software. Instead, it is a bootdisk that runs bare-metal on the 68000 processor, bypassing Apple’s ROM completely. Doing that is probably more impressive than emulating Chip8 — anyone who wants to get into writing emulators starts with Chip8. That’s not to knock on anyone who goes to the effort of writing an emulator, it’s just that given its origins in a 1970s micro, it’s understandably a very simple system. Not many people do bare-metal coding on this sort of hardware anymore; it’s not like there’s an SDK you can go grab.
Or there wasn’t, anyway, because in order to get this emulator to work, [KenDesigns] wrote a bare-metal SDK for 68000-based Macs. Note that when he says 68000, he does mean 68000 — anything newer than a Macintosh Classic is out. It’s 68000, not 680xx. It was not a trivial endeavour. In the demo video embedded below, you can see his 512k Macintosh in pieces because he’s been poking at it with a logic analyzer to verify the hardware does what he thinks it’s being told.
If you want to try it out, apparently you don’t need real hardware: [KenDesigns] says MAME is accurate enough to make it all work, but miniVmac is not. No word if it would work on the RP2040-based PicoMac; if you try it, let us know how it works out.
This isn’t the first time we’ve seen people writing new software for old Macs of late. If you’re working new magic on very old machines, drop us a line. We’d love to hear about it.
Hmpf. By-passing firmware and accessing hardware directly used to be “bad practice” according to programming guidelines.
That’s why the Amiga couldn’t evolve and why advancedd MS-DOS compatibles didn’t took off.
Programmers were too lazy to implement two code paths:
a) clean or official way via BIOS/OS that still works on future hardware
b) direct access for a temporary speed boost on underpowered period hardware (optional)
Instead, they just hard-coded routines with standard settings for IBM PC or Amiga A1000 or Mac 128k.
That’s same reason why x87 unit on PC platform was rarely used prior 486DX.
Programmers were too cheap to offer another, separate binary with x87 instructions.
So they merely cared once the majority had the hardware (chicken-egg situation).
That sort of thinking also caused why some old code failed on Pentiums (Xenix etc).
Developers of the time had used the forbidden test registers of 386/486 and other specific things.
Because, after all, they both were popular among everyone.
In some way that was smart, in another way just shortsighted and dumb.
I’m not entirely convinced the author was concerned with historically accurate “good practice” of any sorts. It’s just hacking – hence the name of this site. And I find the results as impressive as they are useless. I think that’s called a “hobby” ;-)
Hi, good point. And this is a hacking site, after all.
The reason I commented was because the author of the video was joking a bit about Mini vMac being high-level in terms of emulation.
It is, because the Macintosh Toolbox used to serve as hardware abstraction.
If it is patched to work, most well-written Mac software can run.
The same “high-level” approach was used by Macintosh emulators of the 80s that ran on Amiga/Atari ST. Aladin, Spectre GCR, Magic Sac etc.
They basically made the Macintosh ROM work through patching in memory rather emulating the Macintosh hardware.
As a side effect, routines for graphics and disk access could be sped up.
So this kind of emulation has some tradition to it we could say.
I second that.
Some routines are far easier to implement by flipping the registers’ bits directly (say, loops, or when bit-banging esoteric/unorthodox peripherals).
Abstraction layer is good when one focuses on the forest, but sometimes there is a simpler need to rearrange one particular tree’s branches. Whether it is “bad practice” or not is the moral philosophy professors’ dilemma – if it gets the job done with fewer coding, than it is the best tool for the job.
To say programmers were “too cheap” or “too lazy” to implement two code paths or abstraction layers suggests to me that you likely were not a developer during that era. Developing code that code run fast enough to be useful, would run on a Mac or even a 64k-640k PC with very few support libraries and could be delivered on floppy disks was a huge challenge. Today’s environment is a completely different thing.
What Dave W. said. Show your ignorance when you say we were “too lazy.” Unnecessarily duplicating effort, or premature optimization is not how an engineer is trained to work.
This is really brilliant! Great sleuthing on the classic Mac hardware; superb presentation; scary to see that CRT powered up and exposed, but he survived, so that’s a win! Looking forward to seeing the SDK. I think one implication is that it doesn’t rely on the low-memory layout used by the Mac ROM and means you could run an ‘OS’ in User mode instead of Supervisor mode (making preemptive multitasking easier which also implies one could port a Sinclair QL ROM to it, which I would find fun).
358 / 5.000
If you call a 9″ black and white CRT “scary” – it was perfectly normal back then to work on large-format color TVs and displays with the housings open. There were much (!) higher voltages and energies at play, and yet most TV mechanics survived. The bottom line: You should always know what you’re doing. And yes, of course, this knowledge of CRTs is gradually being lost.
I think same. The really dangerous CRTs were those that were powered directly from the AC mains.
Old TV sets from before the 1970s, for example.
By contrast, these little CRTs were often found in portable TVs
or video monitors and could be run from 12v or 13.8v DC (car battery),
so they had to have a power supply.
That being said, high voltage should never be underestimated.
Ideally, another person should be around to call an ambulance in an emergency.
Generally speaking, I mean. Some people are more sensitive to electro shocks, have heart problems etc.
Better safe than sorry.
Gosh. Well, I’ve spent a bit of time repairing a Mac SE fairly recently. The flyback had burned out in 2000, but I managed to get a replacement. Once it was done I powered it up (not open, but with everything back in place); found that it didn’t fully boot and there were artefacts on the display (sad Mac and a Hex code). I thought it might be a memory issue so I performed multiple tests with various memory configurations (including building a small jumper board so I could flip the expected memory configuration). Between each test I left the Mac SE off for an entire day!
Chip8 is a programming language; why would this be called an “emulator”? Last I checked we don’t call, e.g., the JVM running on Linux or Windows “running an emulator.”
Running SNES software on a PC is a simulator; why would that be called an “emulator”? Last I checked an emulator was something you plug into a CPU socket in order to debug a system in-circuit.
Or maybe you could just not be an annoying pedant and understand that words are descrpitive, not prescriptive, and nobody actually cares about where the exact line happens to be, especially for things as trivial and unimportant as what in particular gets called an “emulator”.
Just admit it, you knew exactly what Tyler was talking about, you weren’t confused at any point when reading the article. You just decided that you would take the onus upon yourself to be That Guy™, the one around the office that everyone hates, who’s constantly getting into needless conflicts with everyone else over petty grammatical pedantry. The sort of person who, when Bob and Alice are chatting about the latest TV show around the water cooler and ask Chuck what he thinks of it as he wanders by, trying to be sociable and inclusive, Chuck dramatically sighs and goes “Oh, I don’t WATCH television, it’s SOOOO beneath me,” as if that’s going to get him a medal.
The only alternative explanation is that you’re so cripplingly unaware of how language works that when someone – assuming anyone can put up with you enough to deign to interact with you in real life – tells you that they’re about to hit the hay, you stare at them in abject confusion and go, “But what does punching grass have to do with anything?” Or if someone tells you it’s raining cats and dogs, you start screaming in terror at the unfortunate animals who are falling from the sky.
Basically, and hopefully this uses words that you can understand as well as anyone else: Give it a rest.
Curt made a good point, you’ve made a load of insults. I know who I’d rather talk to.
He raised a question, his point was based on a misunderstanding of what a JVM or simulator is
Emulator behaves like a thing, simulators appear to behave like a thing.
So a flight simulator isn’t actually flying. A SNES simulator would require you to write your own copy of the snes games that ran on a PC.
But a SNES emulator has simulations of the chips. And this does not change much if you use an FPGA either, it’s just got better latency
In circuit emulators do emulate the bus signals, which cpu and FPGA based emulators might not do.
Whether something is something, whether it tries to behave like something or if it gives the illusion of behaving like something is rather fluid and philosophical
I suggest you start with ship of Theseus and work up from there
CHIP 8 is a fixed function system that you could build. Java is a programming language that contains libraries for accessing functionality, that might be optional
Emulating something that doesn’t exist in physical form is not that unusual
I think it’s because “Java Byte code” that’s being used internally by the Java VM.
CHIP8 uses an fictional byte code, too, making it sort of an ancestor to Java VM.
Visual Basic Classic by default had used P-Code (pseudo code), too, which was processed by VB runtime (vbrun300.dll, msvbvm60.dll etc).
Emulator, Virtual machine: Tōmätō, Tōmātō
They’re related, indeed. The devil lies within the detail.
Because ordinary VMs as we use them to contain bits of emulation, too.
If you have an VM of an x86 PC, the processor is being virtualized (passed- through) but the mainboard chipset and things like serial port (16C550 FiFo)/centronics port must still be emulated in software inside the VM software.
The graphics card is a special case, basic VGA registers must be emulated, the VBE/VGA BIOS can use high-level approach.
Likewise, OpenGL commands can be passed through the VM’s communication channel.
Emulated sound card used to be OPL3/Sound Blaster 16, then AC97/HDA.
Example of emulated hardware specs: https://en.wikipedia.org/wiki/Virtual_PC#Emulated_environment
Also, the bits about the virtualized processor is merely half-true.
In some cases, the CPU inna VM is being emulated.
For example, when Real-Mode code is being executed.
If you load EMM386 (MemMaker!) in a DOS VM, then V86 mode is being used.
Which means that no nasty Real-Mode environment must be provided from point-of-view of the VM software.
This even increases performance! ;)
Wow! Chip-8 on the RCA COSMAC VIP was my first introduction to microprocessors in 1977. Also my first digital hardware design of a 12k(!) RAM expansion board. The 1802 was an elegant, and simple (and slow) processor that helped me get a deep understanding of how computers work.
I vaguely recall a 68000 LISP environment that booted “raw” on the early Macintoshes.
I wrote a chip8 emulator many moons ago for my Exidy Sorcerer (Z80 4Mhz clock). The biggest problem is to get the timing right. Even at 4Mhz, games played way, way, way, too fast. I had to add delays so it matched the CPU on the VIP II.
Chip8 is an interesting language, it was pretty much a table of pointers to 1802 routines to shove in the program counter directly, no pushing or popping registers so it had almost no overhead to do the interpretation.
I cut my teeth with the 1802 and struggled for days trying to get my first Z80 program to run. I was spoiled that the 1802 automatically set the accumulator flags, while the Z80 required you to do an operation. For example, to test if the accumulator was a zero, you could do an xor with itself to set the flags.