ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/15/90)
Date: 03-13-90 (11:44) Number: 3023 (Echo)
To: ALL Refer#: NONE
From: CHARLIE HITSELBERGER Read: HAS REPLIES
Subj: BLAZIN' FORTH FOR C-64 Status: PUBLIC MESSAGE
I have Blazin' Forth for the C-64, and the source code for the screens,
as well as the source code for the core kernal. Ballantyne has put in
enough drive support to accomodate a single 1541 drive or a 4040 drive.
If you have 1581, RAM expanders, multiple drives, etc... you are in for
a rude shock. You *STILL* only get 166 blocks of virtual storage. My
mission, should I choose to accept it, is to make it support any type
of drive configuration, including Creative Micro Designs Hard drive if
I should ever get one of those. My questions:
1) Has this been done already? I find it hard to believe that I am the
only one who ever wanted more virtual blocks on Blazin' Forth.
2) What is a good way to set it up? Obviously, I need a device table
of sorts. I was thinking four bytes per element, with one word pointing
to the CFA of the I/O handler of that device and a starting block number
and number of blocks. Oops. I meant four WORDS, not bytes. The 4th
word would be flags, i.e. Is the device mounted, etc... Any suggestions
would be *GREATLY* appreciated, as my experience in designing Forth
systems is very limited.
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'leff2@unix.cis.pitt.edu (Louis Leff) (03/17/90)
I and many others would be very interested in obtaining a copy of the BLAZIN' FORTH kernal code--I already got the system source screens with the package from that other commercial service (qlink) but I have no access to GENIE. Is there code available anywhere?? If not, can you send or post?? LL
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/22/90)
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/22/90)
Date: 03-20-90 (23:06) Number: 3053 (Echo) To: CHARLIE HITSELBERGER Refer#: 3049 From: JERRY SHIFRIN Read: NO Subj: BLAZIN' FORTH FOR C64 Status: PUBLIC MESSAGE CH>0th block of that device. For instance, when I am using drive 8 I sa CH>something like " DR8 3 BLOCK " and it pulls in the 4th block of that CH>drive to the memory buffer. Drive 9, 10, and 11 would be similarly This is how I've seen it implemented on other Forths, but as you know, it's Forth, so you can do whatever appeals to you <grin>! One advantage to specifying the device is that it should trigger the need to do things like FLUSH, EMPTY-BUFFERS, etc. Four drives on a C64??? Sheesh! --- ~ EZ 1.26 ~ ----- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/23/90)
Category 1, Topic 16 Message 17 Wed Mar 21, 1990 R.BERKEY [Robert] at 23:00 PST Re: BLOCK and BUFFER Charlie Hitselberger writes, 900320: > 2) Have the entire disk drive array behave as a contiguous virtual > memory plane. This has been the conventional Forth approach in polyFORTH, and also fig- FORTH. Then they include a user variable OFFSET , a value that is added to any block# input to BLOCK or BUFFER . Such a combination is sufficient to define DR8 in higher level. A block and buffer driver I did had a table of drives with each record containing: starting Forth block number ending Forth block number + 1 read-block routine (uses a device-relative block number) write-block routine (ditto) Another word DRIVE indexed that table. Then, defining DR8 would become: : DR8 ( -- ) 8 DRIVE @ OFFSET ! ; This setup was sufficient to handle a couple of floppies with various capacities, sector sizes, and formats; a small battery-backed-up ram disk, and one large hard disk. Robert ----- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (04/07/90)
Date: 04-06-90 (07:10) Number: 3099 (Echo)
To: DAVID MEYERS Refer#: 3085
From: PETE KOZIAR Read: NO
Subj: >64K FORTHS Status: PUBLIC MESSAGE
I am most familiar with F-PC for the MS-DOS world. Here's how F-PC
gets around the segmentation limits:
Code Segment = Data Segment = Variables and CODE words
Extra Segment = Each colon definition starts on a
paragraph boundary, and NEST sets
ES to the start of the current
word.
Other = The names for the words are kept
in a separate segment that isn't
dedicated to any particular
segmentation register.
Stack Segment = In plain-vanilla F-PC, it's set to
the same as the Code and Data
segments. It's relatively easy to
separate out as another segment;
usually, there aren't that many
tasks, and the stacks are small,
but I run many multiple threads
under DESQview, and DESQview
seems to require huge stacks.
Hope this gives you some ideas!
---
* Via Qwikmail 2.01 The Baltimore Sun
-----
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (04/07/90)
Date: 04-06-90 (10:14) Number: 3100 (Echo)
To: RANDY LAWRENCE Refer#: 3092
From: CHARLIE HITSELBERGER Read: NO
Subj: BLAZIN' FORTH FOR C64 Status: PUBLIC MESSAGE
Thanks a million, that's how I am going to do it. It might slow things
down a bit, and I might change it later, but right now I want to get the
darned thing up. My next problem is 1541 specific. Given a block
offset number, in the range 0...169, I need to return a track/sector
pair. For instance, 0 yields 1/0, 1 yields 1/4, etc...
There will be exactly 3 leftover sectors, so I was intending to reserver
18/0, 18/1, and 17/20 as unused sectors. Then I could write a word that
would fill those blocks with a pre-allocated BAM and a couple of files
named "DON'T VALIDATE", "THIS DISK, IT", "CONTAINS BFORTH", "BLOCKS!!"
or something along those lines. 17/20 just makes the math work out
right in zone 1 of the disk (tracks 1-17 of 21 sectors each).
I had written a semi-elegant (if such a thing can be imagined) routine
in BASIC with an eye toward a direct assembler translation, but my
assembled routine exhibits an "off-by-one" fencepost problem when
crossing between zones 2 and 3, zones 3 and 4. Lately I haven't had
much time to work on it.
I suppose I could always go with Ballantyne's approach, but it seems
like such a waste to not use track 18 in its entirety. Come to think of
it, I'd have to give the new and improved 170K format a different name
so that guys who want to read it using an unmodified BFORTH kernal
wouldn't tear their hair out. Since most BFORTH files are transferred
using FPORT, this is not as big a problem as it would seem, however.
Again, thanks for the idea, and if you have any suggestions on this
problem, please reply.
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'ForthNet@willett.UUCP (ForthNet articles from GEnie) (04/14/90)
Date: 04-12-90 (05:54) Number: 3113 (Echo) To: CHARLIE HITSELBERGER Refer#: 3100 From: RANDY LAWRENCE Read: NO Subj: BLAZIN' FORTH FOR C64 Status: PUBLIC MESSAGE |offset number, in the range 0...169, I need to return a track/sector |pair. For instance, 0 yields 1/0, 1 yields 1/4, etc... you might try converting blocks to virtual sectors: 4 CONSTANT SECTORS/BLOCK : >VIRTUAL // BLOCKS TO VIRTUAL SECTORS SECTORS/BLOCK * ; I calculate that block 90 starts at track 17 sector 20, which is the start of the 3 sectors you would like to skip. What I would do is add 3 to the virtual sector number if we are above block 89; : CORRECT // virtual-sectors -- corrected-virtual-sectors DUP [ 89 >VIRTUAL ] LITERAL > IF 3 + THEN ; Then convert the virtual sectors to pysical tracks and sectors. Your final track and sector mapping word might look something like this: : >T&S // -- track sector BLK @ >VIRTUAL CORRECT >PYSICAL ; I hope this gives you an idea or two. BCNU, Randy Lawrence KA7WAG --- ~ EZ 1.27 ~ blah! blah! blah! ----- 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'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/11/90)
Date: 07-09-90 (00:01) Number: 3476 (Echo) To: ALL Refer#: NONE From: MATTHIAS GIWER Read: (N/A) Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE I am looking for friend a 128 Comm Forth. Can anyone help? ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/03/90)
Date: 08-01-90 (19:01) Number: 3595 (Echo) To: MATTHIAS GIWER Refer#: 3476 From: DAVID BREEDING Read: NO Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE There are a couple of options available on the C128. The first (and I think the best) is to use F83 CPM. This is a full featured FORTH with 'Standard' files and structure. If you are just learning FORTH this forth, and it's extensive shadow screens, is a MUST!!! The second option is to go into C64 mode and use Blazin Forth. This is a very good F83 Forth that runs in 64 mode. There is not presently, as far as I know, a FORTH that runs in native C128 mode. I have toyed with the idea of writing my own...but have never gotten around to it... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Date: 09-01-90 (11:35) Number: 3695 (Echo)
To: MATTHIS GIWER Refer#: 3595
From: RANDY LAWRENCE Read: NO
Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE
I have a Forth written for the C128. It is a very hacked up
version of Blazin' Forth. However, it is not finished. It lacks
a file interface, so you cannot load source files from a disk.
It also lacks a resident editor and assembler. And of course, it
has no docs.
If there is interest, I will put the (TSDS) assembly source into
a self extracting archive and post it on ECFB.
Randy
---
~ EZ 1.27 ~ AARGH!
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us