Kitchen counter revisited

Back in 2008 we knocked out the wall between the kitchen and the living area. The idea has always been to put a counter surface on there, it’s just that I wasn’t quite sure how to do it so… I didn’t.

Until a few weeks ago, when Tanya mentioned that with Jessica’s 18th birthday (cocktail) party coming up, it would be nice to have a counter…

So I got my arse in gear.

Started with a couple of templates, ordered MDF mostly-cut-to-size and with the appropriate edges rounded. Not that they got it right, but it was close enough.

Then I carefully marked the boards and routed them to size against a straight edge and… it didn’t work out right. No idea why. Out by about two mm on the outside edge. FSCK.

So I routed it back further and glued in a false piece and repeated the operation, but starting about 5mm oversize and coming in via router and then belt sander, half a mm at a time.

That’s probably as good as it gets.

Covered the two pieces in wrapping paper for the party (I didn’t want stains on the wood before I seal it, and staining and sealing will be a slow process since I need to try to match the postform kitchen counter colour).

And that’s what it looks like at the moment.

I’ll tie the two pieces together with dowels or biscuits, maybe a screw underneath to hold things together. The polyurethane wood glue dries to almost the right colour so that should be OK… I hope.

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