niche 68K Mac emulation needs

black and white screenshot of Macintosh System 7 desktop showing Disk First Aid icon
It amazes me how you manage to live in anything that small“: actual size Mac Classic II screenshot

So I’m refurbishing the Mac Classic II I got in 2016 now that I’ve found that BlueSCSI is a fairly cheap way of providing large replacement storage. The 40 MB (yes, 40 MB) drive from 1992 can finally be replaced.

Hit a snag, though: DiskCopy won’t copy a disk with errors, which this drive seemed to have. DiskCopy also won’t repair the boot disk, so you have to find a bootable floppy or some other way to work around this limitation. The only readily available bootable disk image I could find was the System 7.1 Disk Tools floppy — which reported no errors on my drive! Later versions of Disk First Aid would fix it, but weren’t provided on a bootable image.

Here’s the 7.1 Disk Tools floppy with all of the apps replaced by Disk First Aid 7.2. Both of these were found on the Internet Archive’s download.info.apple.com mirror and combined:

Disk duly repaired, DiskCopy was happy, backup complete. Eventually: the Classic II is not a fast machine at all.

I love the old Mac icons, how they packed so much into so few pixels:

enlarged icon: stylized ambulance with flashing light and driver, side is a floppy disk, there are motion lines at back and the whole icon is slanted to indicate speed/rush
Disk First Aid icon

It’s a stylized ambulance with flashing light and driver, the side is a floppy disk, it’s got motion lines and the whole icon is slanted to indicate speed/rush. Nice!


Vaguely related: most old Mac software is stored as Stuffit! archives. These don’t really work too well on other systems, as they use a compression scheme all their own and are specialized to handle the forked filesystem that old Macs use. Most emulators won’t know what to do with them unless you jump through hoops in the transfer stage.

Fortunately, the ancient Linux package hfsutils knows the ways of these hoops, if only you tell it when to jump. The script below takes a Stuffit! file as its sole argument, and creates a slightly larger HFS image containing the archive, with all the attributes set for Stuffit! Expander or what-have-you to unpack it.

#!/bin/bash
# sitdsk - make an HFS image containing a properly typed sit file
# requires hfsutils
# scruss, 2021-07

if
    [ $# -ne 1 ]
then
    echo Usage: $0 file.sit
    exit 1
fi

base="${1%.sit}"
# hformat won't touch anything smaller than 800 KB,
#  so min image size will be 800 * 1.25 = 1000 KB
size=$(du -k "$1" | awk '{print ($1 >= 800)?$1:800}')
dsk="${base}.dsk"
dd status=none of="$dsk" if=/dev/zero bs=1K count=$((size * 125 / 100))
hformat -l "$base" "$dsk"
# note that hformat does an implicit 'hmount'
hcopy "$1" ':'
# and hcopy silently changes underscores to spaces
hattrib -t 'SIT!' -c 'SITx' ":$(echo ${1} | tr '_' ' ')"
hls -l
humount

What this does:

  1. creates a blank image file roughly 25% larger than the archive (or 1000 KB, whichever is the larger) using dd;
  2. ‘formats’ the image file with an HFS filesystem using hformat;
  3. copies the archive to the image using hcopy;
  4. attempts to set the file type and creator using hattrib;
  5. lists the archive contents using hls;
  6. disconnects/unmounts the image from the hfsutils system using humount.

Notice I said it “attempts” to set the file type. hfsutils does some file renaming on the fly, and all I know about is that it changes underscores to spaces. So if there are other changes made by hfsutils, this step may fail. The package also gets really confused by images smaller than 800 KB, so small archives are rounded up in size to keep hformat happy.

making Apple II cassette audio using the Epple-II emulator

Screenshot of "Epple-II" Apple II emulator running a 3D sync wav plot in purple
yes, it’s PLOTPOURRI

as requested on reddit:

  • on Linux, you’ll probably need a development system, 6502 assembler and SDL2 libraries: sudo apt install git build-essential autoconf automake libsdl2-dev libsdl2-image-dev libsdl2-ttf-dev xa65
  • download from https://github.com/cmosher01/Epple-II/releases or git clone https://github.com/cmosher01/Epple-II.git
  • similarly, download Apple II ROMs from https://github.com/cmosher01/Apple-II-Source/releases or https://github.com/cmosher01/Apple-II-Source.git
  • build Epple-II: cd Epple-II && ./bootstrap && ./configure && make
  • install Epple-II: sudo make install
  • build ROMs: cd ../Apple-II-Source/ && ./bootstrap && ./configure && make
  • install ROMs: sudo make install
  • comment out demo rom and uncomment your rom choice in /usr/local/etc/epple2/epple2.conf
  • start Epple-II: epple2
    (Don’t try epple2 &; the emulator will hang)
  • in the Epple-II console (F5), create a blank tape image: cassette blank prog.wav
  • in the main Epple-II window, paste in your BASIC source (F7) then save it: SAVE. This may take some time, and there will be a beep
  • back in the Epple-II console, write the tape image: cassette save
  • still in the Epple-II console, close the tape image: cassette eject out
  • your Apple II BASIC program is in the file prog.wav.

For example, here’s Plotpourri‘s BASIC code saved to tape:

It’s also a pretty decent Apple II emulator, too.

Installing the Versatile Commodore Emulator (VICE) on Raspberry Pi

Updated 2020-11-28: thanks, Ennio! Should now build after new Raspberry Pi OS and Vice changes

As requested on our local Commodore user group mailing list, how to install VICE on a Raspberry Pi running Raspberry Pi OS:

sudo apt install autoconf automake build-essential byacc dos2unix flex libavcodec-dev libavformat-dev libgtk2.0-cil-dev libgtkglext1-dev libmp3lame-dev libmpg123-dev libpcap-dev libpulse-dev libreadline-dev libswscale-dev libvte-dev libxaw7-dev subversion yasm libgtk3.0-cil-dev xa65 libsdl2-dev libsdl2-image-dev libgtk-3-dev libglew-dev

mkdir -p src

cd src

svn checkout https://svn.code.sf.net/p/vice-emu/code/trunk trunk

cd trunk/vice

./autogen.sh

./configure --disable-pdf-docs

make -j4

sudo make install

This was freely adapted from the build docs, Linux-Native-Howto.txt, which has more info if you get stuck.


If you’re feeling fancy and want nice GUI controls and sound recording and menu stuff, try

./configure --disable-pdf-docs  --enable-lame --with-mpg123 --enable-shared-ffmpeg --enable-x64 --enable-native-gtk3ui --enable-desktop-files

This will give you desktop icons too. I’m not sure in the apt line is quite right, though — but I’ve had my doubts about all those CIL entries, ‘cos I think they pull in Mono/.Net, and who would want to use that?

Apple II on Raspberry Pi

C’mon let’s all die of dysentery on the Oregon Trail!

Update: You probably want to use https://github.com/linappleii/linapple instead of Linapple-Pie these days.

Building and installing the linapple-pie Apple IIe emulator is relatively easy on the Raspberry Pi:

sudo apt install libcurl4-openssl-dev libzip-dev zlib1g-dev libsdl1.2-dev libsdl-gfx1.2-dev libsdl-image1.2-dev libsdl-sound1.2-dev build-essential git
git clone https://github.com/dabonetn/linapple-pie.git
cd linapple-pie/src
make
sudo make install

This also works on an x86_64 Ubuntu machine. It does also install on a PocketCHIP (even if it takes a really long time) but I can’t get the display resolution to fit correctly.

Painfully Slow Amstrad CPC Emulation on the Raspberry Pi

Yeah, you can do it, but whether you should, I don’t know. Download the latest Arnold/Linux source, then (according to this post) after installing the dependencies, you just need to change

TARGET_FMT=elf32-i386

to

TARGET_FMT=elf32-littlearm

in src/Makefile.in.

It works, for very slow values of “works”. Mind you, I was running it through a remote X session, so 2 fps is all I could have hoped for …

2D Star Dodge flies again!

There’s rather more nostalgia in this post than I’d want to deal with. If you want to just play the game, go here here and skip this blurb.

Update: the Java emulator doesn’t work in the browser any more, so here’s Arnold playing the BASIC version: http://scruss.com/cpc/6128s.html?stardoj.dsk/run%22stardoj2

About 25 years ago, I was a smallish computer nerd obsessed with programming his Amstrad CPC464. I had got a BCPL rom-based compiler for cheap and was looking for things to do with it. “Why not write a game?” I asked myself.

There were two minor hurdles. I had no imagination, and I certainly wasn’t focused enough to write anything big. Fortunately, it was still the 80s, so we knew how to rip stuff off without being called out for it. I merrily copied a game my friend Alan Cook had written for the Dragon 32, and called it 2D Star Dodge.

2D Star Dodge was the perfect rip off. Not merely had I ripped off the idea from Alan, but he had ripped off the idea in turn from a BBC Basic one-liner game called (as verified by Graeme Smith) “One Line” Asterisk Tracker. The name 2D Star Dodge was an, um, homage to Realtime Games’ 3D Starstrike, which itself was “strongly influenced” by the Star Wars arcade game. Originality? Pfft.

So I wrote the game. Well, okay, I wrote a mockup in Locomotive BASIC, which ran a bit slowly, but gave me something to work from. Here it is, if you want to play it in you (Java-enabled) browser: 2D Star Dodge – BASIC. I then meticulously translated it into BCPL, and ended up with something that looked liked this:

(if you click on that image, you can play the BCPL version in your browser.)

this is actuall screen three, hope no-one notices ...

 

The gameplay — press a key to go up, stop pressing a key to go down — is a bit like SFCave (obligatory Java version: Lab6 SFCave) or even my current favourite Tiny Wings.

Once I’d finished the BCPL version, I had bought the MAXAM assembler ROM, and got learning the Z80 opcodes. Soon, a third port was complete, now needing hardcoded delays to be playable as it would kill you off in about one screen refresh without them.

So, now I had three versions of the same game. There was only a limited number of local folks I could give it to, so I decided to send all three versions to Amstrad Computer User magazine to print as a type-in. Thankfully, it arrived on the desk of the freshly minted (yet still beardy) assistant editor Jeff Walker, who had founded the jam econo CPC magazine/club WACCI. Jeff had the idea for me to turn the simple game into a comparison of programming in three languages.

Thanks to the CPCWiki forum, you can now read the articles I wrote in Amstrad Computer User in 1988 that went with the code. Writing style best described as “typing”:

To play the game in an astonishing JavaScript emulator:

  1. Download this disc image file: stardoj
  2. Unzip it
  3. Go to CPCBox
  4. “Choose configuration …” of Boot CPC464 (or 664, or 6128)
  5. Select your downloaded stardoj.dsk as Drive A:
  6. Annoyingly, it seems to be stuck with an AZERTY keymap, so to catalogue the disc (cat) you have to type cqt
  7. To run the BASIC version, type run"stardoj2 (on my American keyboard, that becomes run@stqrdoj2; quotes are Shift+2). Hitting Escape twice will quit back to the prompt.
  8. To run the BCPL version, type run"2dstardo. The only way to quit is to reset the emulator.

The BASIC version is based on the published type-in. The BCPL version I found as a disk image (2dstardo.dsk) on a download site — it’s exactly as I submitted it to the magazine, dubious copyright message and all. I’m not sure how it got out there; I suspect either my network of, ahem, software protection experts I knew through Colin Harris of Nemesis, or it went via my CPC-owning French penpal (Hi Benoit Hébert, formerly of Le Havre).

I had to modify the BCPL binary to run on modern emulators, as the real Amstrad CPC did a thing with its keymapping that is really hard to get right on modern systems. Originally, the game used the Shift key, but I modified it to use Space, which is easier to emulate as it’s a printing character. Can I just say that I remembered how to read and modify Z80 binaries after a quarter century? Old school, literally. I used iDsk‘s disassembler/hex dumper and emacs’s hexl mode to do the deed.

I recently discovered that someone created a Flash game based on my type-in: Star Dodger. Mind = Blown.

Update, 2018: Lawks! Someone wrote a PureScript version! It doesn’t exactly work for me on Firefox, but it does on Chromium.

amiga: blank hdf images

I’m trying to get running an Amiga again, to see if I can remember what was rocking my computer world twenty years ago. I want to run that code, swim with the Fish disks, and generally muck about with what was my life back then.

Emulation is interesting. Variants of UAE (which came with an Amiga Forever CD set I bought in 1997 or so) rule the roost. Quality is variable – on Windows, WinUAE is very comprehensive, even making grink-gronk noises as the floppy spins. On Mac, E-UAE is really not worth the bother kinda okay – it doesn’t want to emulate anything above a 68000, and falls over quite often but has decent sound. On Linux, it’s plain and stable, and I happen to have an old Thinkpad going spare I can dedicate to emulation.

I would have expected all the old disk images to be readily available for download. It seems that the current owners of the Amiga name (this week, at least) still cling on to the old IP as if it has real value. The Amiga games market (which was the market) basically collapsed with Commodore in 1994. I really wonder who is buying the PowerPC based, vastly overpriced new hardware? For now, I’m relying on good old-fashioned torrent sites for my data.

I want to emulate two machines; the A500 I had for all my cringe-worthy magazine writing running Workbench 1.3, and a fast thing maxed out with all the processors and RAM I never had, probably running 3.1. While I did have Amiga[D]os 2.04 (can’t remember if they’d dropped the D by then), it wasn’t the main focus of my interest by then.

The biggest problem I have is getting hard disk image, even blank ones. UAE is picky. Here are a couple I formatted under WinUAE, both blank.

I wonder if they’ll work under 1.3?

Update: yes, they should. I formatted them FFS under AmigaDos 1.3.