Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: FORTH FOR 8-bit COMMODORE
Message-ID: <1804.UUL1.3#5129@willett.pgh.pa.us>
Date: 5 Oct 90 03:27:10 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 43


 Date: 10-01-90 (15:25)              Number: 3945 (Echo)
   To: ALL                           Refer#: NONE
 From: CHARLIE HITSELBERGER            Read: (N/A)
 Subj: BLAZIN' FORTH MODS            Status: PUBLIC MESSAGE

 Yeah buddy!  I finally got the time and space both on the same astral
 plane, and was able to spend an uninterrupted (except by the pizza dude)
 weekend messing around on my C64 with Blazin' Forth.  What did I do, you
 wonder?  For some time now, I have considered it a serious shortcoming
 (travesty?) that the Blazin' compiler only supports a 4040 drive.  First
 of all, nobody has 4040 drives anymore, they all have 1541 drives. 
 Secondly, I have not one, but TWO 1541 drives, and TWO 1581 drives, not
 to mention a 512K RAM expander.  Since Forth is nothing if it isn't
 extensible, I decided to put my talent to the test, as it were, and make
 the i/o handling scheme more general.
 The heart of a block i/o system is the reserved word R/W , and luckily
 for me, it was vectored.  In Blazin' Forth, this word will invoke
 another word, T&S , to determine the starting track and sector of a
 given block.  Commodore, in their infinite wisdom, has put a variable
 number of sectors per track on their 5.25" floppy drives.  This makes
 life interesting.  Fortunately, they standardized on 40 sectors per
 track on the 3.5" drives.
 First, I put in a constant #DRV , the number of physical drives on the
 system.  Then I created a 5 * #DRV celled table, called DRVTBL.  The
 layout of each 5-cell record in DRVTBL is as follows:
 'OPEN  'R/W  DRV-DATA  LOWBLK  HIGHBLK
 Then I layered everything on top of this, and finally hooked it to the
 system R/W word by saying ' NEW-R/W  ' R/W >BODY !
 When the system goes to get, say, block 1875, first it checks to see if
 1875 resides on the currently open physical device.  If it doesn't, it
 will scan through the DRVTBL until it finds a LOWBLK and HIGHBLK that
 1875 fits between.  It then invokes the 'OPEN routine for that drive. 
 Since everything is vectored, the overhead wasn't that bad at all.  For
 my next trick, I plan to write some drivers so that I can use block
 numbers that are offsets into relative files, and a partition-based
 driver for the 1581, so I can keep my executables in a Commodore OS
 format, and store a bunch of blocks in a partition.  I'll upload the
 source to the Commodore directory here, but after I add the REU support
 routines.  All told, it was 6 screens of code.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp