Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!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: <1726.UUL1.3#5129@willett.pgh.pa.us>
Date: 14 Sep 90 03:39:11 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 21


 Date: 09-11-90 (09:11)              Number: 3754 (Echo)
   To: DAVID BREEDING                Refer#: 3747
 From: CHARLIE HITSELBERGER            Read: NO
 Subj: 128 COMMORDORE FORTH          Status: PUBLIC MESSAGE

 I've thought about how I'd like the REU support words to be implemented,
 and I think I like blocks the best.  In my ideal Blazin' Forth, there
 would be a device table with all the disk drives, their block sizes, and
 a DEFER-vector to point to a handler for that particular device.  That
 way, you could shuffle your drives around and view the entire disk farm
 as one contiguous chain of blocks (drive 8 = 1541, blocks 0-163; drive 9
 = REU, blocks 164-675; drive 10 = 1581, blocks 676-1435...) or you could
 rearrange them any old way.
 Why are files better than blocks?  Or, if you are on the other side, why
 are blocks better than files?  Personally, I prefer blocks because it is
 traditional Forth.  No other reason, really.  But then, I still use the
 Starting Forth editor to handle my source.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us