Cool hacks on the 1616

Just a few things from a rapidly fading memory.  Most of them are mine - I'd like to add some balance. Help me out here, guys - what else did we do...
 

Greyham Stoney's floppy driver

Written in Z80 assembler and uploaded to the disk controller at boot time.

This driver had track reads, readahead, writebehind, and LRU caching. People loved it.

Forks in Minix

With no hardware memory management, Colin still got fork() to work.  This involved copying in and out the BSS, heap and stack of the child and parent processes prior to scheduling each one.  Needless to say, an exec() was welcome...

Andrew McNamara's 1616 filesystem for GNU/Linux

Andrew had a mountain of stuff on his 1616 SCSI disk.  Any normal person would have used floppies....

The SNOOZE() system call

SNOOZE() allows a task to register a callback with the operating system scheduler.  When that callback returns non-zero the task is placed on the run queue.  Very simple, but it was very useful for rescheduling processes which were waiting on their own interrupt handler.

The MGR-mode video PAL

A hack to the video PAL and colour pallette which allowed it to produce a 15MHz, 1 bit-per-pixel output.

The wait state generator on the SCSI card

The /DACK pin on the NCR5380 on the memory card could be programmed to pull a wait state on the 68000 during programmed I/O (the 1616 didn't use DMA).  This allows the driver to read or write the 5380 data register without polling the 'data ready' bit in a register.

Also, the memory mapping of the 5380 was designed so that each register appeared at four successive long word boundaries.  This allowed me to pull four bytes off the SCSI bus with a single movep.l instruction.  The driver did this four times in succession and then spat four long words into main memory in a single movem.l instruction.

Here's the code to read a 512 byte sector from the SCSI bus:

        moveq.l #7,d0           ;Pull in 64 bytes eight times
4:
        movep.l 0(a1),d4        ; 24
        movep.l 0(a1),d5
        movep.l 0(a1),d6
        movep.l 0(a1),d7
        movem.l d4/d5/d6/d7,(a0)    ; 40
        movep.l 0(a1),d4
        movep.l 0(a1),d5
        movep.l 0(a1),d6
        movep.l 0(a1),d7
        movem.l d4/d5/d6/d7,16(a0)  ; 44
        movep.l 0(a1),d4
        movep.l 0(a1),d5
        movep.l 0(a1),d6
        movep.l 0(a1),d7
        movem.l d4/d5/d6/d7,32(a0)
        movep.l 0(a1),d4
        movep.l 0(a1),d5
        movep.l 0(a1),d6
        movep.l 0(a1),d7
        movem.l d4/d5/d6/d7,48(a0)

        lea 64(a0),a0       ; 8

        dbf d0,4b           ; 10

This driver had a theoretical throughput of 1.5 MBytes/sec.  The disks could only sustain half of this.

chop

chop was an execution profiler.  It used the ENT1INTS() system call to generate a 30kHz interrupt stream.  If the 68k's program counter was within the text segment of the process being profiled, chop incremented a histogram bucket for a later profile report.

Nothing at all smart about this, but it worked very, very well.

NCR Tower binaries

I had access to a 68010-based SVR3 Unix NCR Tower.  Happily, the Tower's executables were linked to execute at 0x8000, which is usually free under 1616/OS.  And the Tower used trap #0 for system calls (1616/OS uses trap #7)

A little daemon intercepted the trap #0 vector and dispatched to a 1616/OS system call, allowing Tower binaries to run under 1616/OS.  This got me lex and yacc for the Pascal compiler.  I wonder what happened to that?  I'm sure it's the only Pascal which has a native printf()....

A curiosity

The CHDIR() system call takes two arguments.  The first is the PID of the process whose working directory is to be changed.  Surprisingly, this proved quite useful for things like editors - change their working directory whenever you feel like it so that working files are always in ".".  Change MGR's working directory so that new shell windows pop up where you want them to.

The GCC port

After many nights' hacking, it was obvious that the Hitech compiler wasn't going to compile GCC.  Fortunately I had earlier ported GCC to run under the Macintosh's MPW environment using MPW C as an embedded system cross-compiler.

So a simple port of the GNU C libaries to the MPW compiler allowed me to create a 1616/OS binary of GCC.  Took it across on many floppies and bootstrapped the 1616 that way.

TUNE3

TUNE3 was a three-voice music synthesiser.  I developed a set of SSASM assembler macros which allow you to enter the musical score by macro expansion.  Musical repeats could be implemented by macro expansion as well.

Here's the start of a polyphonic lute piece by Roncalli:

        include musicdefs.mac
        include compose2.mac

        startup
        volume  1,110
        volume  2,200
        volume  3,255

        tempo   1200

        decay   1,2
        decay   2,1
        decay   3,1

* Line 1, measure 1
        chord   8,34,30,15
        chord   4,34,30,15
        chord   4,34,30,15

* Line 1, measure 2
        chord   4,37,29,22
        chord   4,36,29,21
        chord   4,29,25,22
        chord   4,29,22,1

A tarball for TUNE3 and Roncalli is here.

Cameron Hutchison transcribed "Yellow Submarine" for TUNE3.  I think he went overboard with the macros - it went on for ever.
 



AKPM Home

Andrew Morton, 8 March 1999