wrm

Fortune 32:16 and the longevity of floppies

Way back when, back in 1987, I was studying engineering over at the University of Stellenbosch, and I read about this thing called BIX, the Byte (magazine) Information eXchange.

So I went over to Professor Krezinski at the Computer Science department and asked him nicely to let an engineer play with their toys and to my surprise he agreed. Gave me access to the building and organised an account on the DG, which was connected to some magic elf (X.25?) boxes which in turn connected to… BIX. Where I spent some time (not a whole lot, my father’s credit card was paying for my time) chatting to some very bright people. This was when smileys still looked like ^_^ and {^_^} (Hello jdow, wherever you are)

But there were other interesting computers in the lab (on the third floor, ISTR). Specifically, an AT&T 3B2 and a Fortune 32:16.  And since I was designing a 68000-based computer at the time, I copied all the Fortune disks, thinking maybe, some day,  I can make some of this stuff run on my machine.

That day has not yet come :-)

But I recently found those floppies again, and copied them using Dave Dunfield’s ImageDisk 1.18. And they were all still 100% readable (OK, on one floppy the jacket had warped, I had to remove the disk and stick it in a cleaning disk jacket to read it).

Bitsavers have some documentation online, and from this it’s clear that Fortune Systems never intended the user to poke around under the hood. Apart from the 68000 processor, I can’t find any details online about the chips used, the amount of ROM on the motherboard, or anything like that (Unleashing a hex editor at the diagnostics software shows mention of a Z-80 processor, as well as “CTC” and “SIO” and “dual port RAM” — sounds like an I/O device.  There was apparently also some kind of an MMU).

Anyway, here are my disk images. Disks are 80 track, with five sectors of 1024 bytes each per side.

I’m not too sure how useful these will be, since this 2005 posting to ClassicCmp states that

They also had a reasonably effective copy-protection scheme.
Uninstalled Fortune software on distribution media was encrypted using
a key known to Fortune and to Fortune's installation program.  When
you installed software from the distribution media, the software would
be decrypted and then re-encrypted using a key based on the
motherboard serial number for storage on the hard disk (so you
couldn't just copy the executables from your system to some other
system: installed software only ran on the system on which it had been
installed); and of course the installer marked the distribution medium
as "installed" so you couldn't just go install it again somewhere
else.

Warbots

The archive-diving continues (I’m checking all my old floppies and archiving everything that looks interesting).

Found a ZIP file WARBOTS.ZIP. This is yet another Robot War type program, this one written by Chris Busch in 1990. Unlike Robot War (which has a vagely BASIC-like syntax) or Arena (x86 assembler, urgh) the syntax is very Pascal-like (which figures, since Chris wrote Warbots in Turbo Pascal).

Now, for some reason Chris decided to encrypt the robot sources supplied as examples. But, Tyler Akins tells us that it’s a simple XOR “encryption”, and some fiddling with ICY Hexplorer armed with the hunch that “vitiex” is most likely “repeat” gives us the hex key 040c for the first line of scanbot.war. After that it gets tricky, “Ehh | 5” translates to “Add y 1” using a key of 040c0c — so the key changes by some rule. I really don’t have the time to figure it out but it’s obviously not that tricky.

This at least gives an idea of the syntax.

Warbots doesn’t run in a DOS box under Windows (2000 and 7 tested) so that’s all I have for now.

 

 

 

 

 

Whatever happened to Anthony Rose?

Back in the eighties, when the Cape Computer Club were homebuilding or just playing around with computers based on the 6502, 6800, 6809, 68000, z-80 and the like, Anthony Rose was one of the Names. Like me, he had an Apple II, unlike me, he made that thing sit up and dance. Using Forth, most of the time.

He also wrote a test suite for the Apple which I still have on disk somewhere — thinking about it, this might be one of the last copies in existence so at some stage I should look at backing it up.

Anyway, I was sorting through my collection of MSDOS floppies, and came across a disk labelled “ARTFORTH.68K”. Yes, I remember getting that from my friend Barney, never did anything with it.

Problem is, the disk has errors. Not that I can complain, it’s a disk I used with my Apple before reformatting it to MSDOS, it’s only certified single-sided, and it’s still mostly readable after being in storage since about 1990.

So this was an opportunity to revisit the dreaded FAT12. I used ANADISK to copy the readable bits of the floppy to hard drive (yes, I still have a DOS box with 5 1/2″ and 3 1/4″ floppies. It even runs Windows 3.1) and the HxD hex editor to analyze things. This web site was extremely useful to help me find my way around FAT12.

The first file on the disk, “ARTFORTH.68K” survived intact. It’s 149 FORTH screens of  64 characters x 32 lines of FORTH code written by Anthony in 1986 for what looks to be some kind of 68008-based platform.

The second file, “FORTH.COM” was not so lucky. Or maybe it was, the directory is corrupted so I don’t know whether I have the whole file or not. It’s definitely 68000 code, disassembly yields constructs like:

201E                     MOVE.L   (A6)+,D0
221E                     MOVE.L   (A6)+,D1
241E                     MOVE.L   (A6)+,D2
2D01                     MOVE.L   D1,-(A6)
2D00                     MOVE.L   D0,-(A6)
2D02                     MOVE.L   D2,-(A6)
4E75                     RTS
201E                     MOVE.L   (A6)+,D0
221E                     MOVE.L   (A6)+,D1
241E                     MOVE.L   (A6)+,D2
2D00                     MOVE.L   D0,-(A6)
2D02                     MOVE.L   D2,-(A6)
2D01                     MOVE.L   D1,-(A6)
4E75                     RTS

Which is clearly an implementation of ROT and -ROT. There’s also a copyright string “ART-Forth 1.0  (c) 1987 A.R.T.” at $2DD9 so we know what we’re dealing with.

Of course, before trying to scrape these files off the floppy, I searched the web, because if someone else has it online my work is done. But no. Anthony Rose the Forth guru seems to have disappeared (he might have surfaced as one of the many Anthony Roses on the ‘net, but none of them own up to a love of Forth). About the only relevant thing I could find is his 1986 paper Design of a fast 68000-based subroutine threaded Forth with inline code & an optimiser which mentions the HP9816 (which used a 68000 and not a 68008 — the mystery continues).

Three years

Change is a constant.  For the young, without a frame of reference, change is the normal state and is readily accepted as such — whatever is new is inherently better than whatever is old — new things and new ideas, at least new to youth, are quickly adopted by the young as their reality. But after we’ve lived for a time — once we’ve established a frame of reference — we begin to see that many changes are not new things but merely old things wearing a new coat of paint — someone keeps stirring the pot, the same old potatoes come to the top and sink again. Old potatoes are always “New!” or “Improved!” according to the people who sell them, and eagerly gobbled up by the kiddies because of it.

In time, we come to realize another constant in our lives is people trying to sell us old potatoes. Discovering we’ve been duped often leaves us bitter. When we reach that point we begin to view new things — and all forms of change — with suspicion. We cleave to what we know. What was shining and new and instantly embraced in our youth becomes the good, old-fashioned stuff of middle-age. It is our security blanket, a bulletproof vest against the missiles of a changing world. It is also the seed from which grows the tree of ignorance.

The wiser course is to test new things against our store of experience, adopting what is good, discarding what is bad but always with tolerance. Some bad things will always be wildly popular among our youth simply because they lack the frame of reference defining those particular evils. Merely telling them something is bad does little good — it lumps us with the sellers of old potatoes. There are some lessons each generation must learn on their own, a Rite of Passage between childish play and adult responsibility. Each generation must eat its share of old potatoes.

— Bob Hoover, 1939 – 2010

Slow cooker eland chili

Being the second of two completely coincidentally very similar recipes.

Still the same eland shin, defrosted in water.

The recipe is from Perry’s Plate. For this one I used some stock I made a while ago, using quite a lot of green and yellow bell peppers. And I used cocoa powder instead of chocolate chips.

Again, I had to reduce the sauce at the end. I’m still a bit nervous about the slow cooker boiling dry (which I’m pretty sure it won’t) so I add too much liquid as a rule.

Slow cooker eland tomato bredie

Being the first of two completely coincidentally very similar recipes.

The basis for all of this is some eland shin (skenkel), off the bone. I bought half an eland cow from a friend, and while having a freezer full of eland is a Good Thing (TM), we also have to eat most of it before I can fit some gemsbok in there.

To defrost the meat, I soaked in in water (with a bit of vinegar added) for 24 hours. This draws out the blood, makes the meat less “wild” apparently. Then I basically followed the standard recipe,  i.e. dusted the cubed meat in flour, browned it in the black pot, stuck it in the slow cooker along with tomatoes and a bit of chili and spices and Worcestershire and so forth, and let it go all day on low.

Got home, diced some potatoes quite small, separated the sauce with a slotty spoon and boiled the potatoes in the sauce until done, then recombined the whole lot. I might have added some Maizena too.