Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: COMMODORE 8032 FORTH
Message-ID: <691.UUL1.3#5129@willett.UUCP>
Date: 22 Mar 90 02:43:01 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 44


 Date: 03-20-90 (15:04)              Number: 3049 (Echo)
   To: ALL                           Refer#: NONE
 From: CHARLIE HITSELBERGER            Read: (N/A)
 Subj: BLAZIN' FORTH FOR C64         Status: PUBLIC MESSAGE

 I am running a PD Forth which supports 166K of virtual memory (i.e. a
 single 1541 disk drive).  Well, my system has 2 meg on it, and I want to
 redesign the block i/o.  The coding is not a problem, the user interface
 design is.  What should the virtual memory look like to the user?
 There are two ways I have considered:
 1) have a device context switching word, and base everything off of the
 0th block of that device.  For instance, when I am using drive 8 I say
 something like " DR8 3 BLOCK " and it pulls in the 4th block of that
 drive to the memory buffer.  Drive 9, 10, and 11 would be similarly
 handled, and I'd use a >BUILDS ... DOES> construct to define the drive
 switching words.
 2) Have the entire disk drive array behave as a contiguous virtual
 memory plane.  In other words, if I have two 1541's and two 1581's
 hooked up, that makes 170+170+800+800 = 1940K.  Then I can say " 1653
 BLOCK " and get a block from somewhere out there on drive 11 (the
 highest numbered device).  This would entail maintaining a four-word per
 entry table:
    i/o handler address
    starting block
    ending block
    flags (physically mounted, virtually mounted, etc...)
 The 64's disk interface is kinda weird, it opens two channels for i/o to
 a drive when you do direct track/sector access.  Suppose I open a
 channel to a disk but there's no floppy in it?!  The drive errors out
 and I better tell the user about it.  That device should be considered
 as "virtually mounted" but not physically mounted.  Same thing happens
 when the user unexpectedly swaps disks.  Opening the drive door
 automagically closes the i/o channel to the computer, but without
 telling the computer about it (!)  Definitely a problem that will have
 to be addressed.
 3) Some hybrid of the two schemes seems to be the best solution, but
 here is where I run into the brick wall between the right and left
 halves of my cerebral cortex.  Someone please help!!

                                            Charlie Hitselberger
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'