ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/12/90)
Date: 09-09-90 (12:10) Number: 3738 (Echo)
To: CHARLIE HITSELBERGER Refer#: 3725
From: RANDY LAWRENCE Read: 09-10-90 (10:11)
Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE
No problem getting the C128 Blazin' to ECFB. I will have the self
extracting archives uploaded to ECFB within the week.
You should know that one of the mods I did was to remove Blazin's
original disk support (I hate blocks). I intended to make it load
from sequential files, never got around to finishing it however.
I also completely revamped the interface to the operating system. It
is very nice. I am quite happy with it.
I have found, but not fixed a bug in M/MOD.
I have defered many words and added an IRQ hook
If you have any questions, I'll be right here.
chow, 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.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/12/90)
Date: 09-10-90 (10:11) Number: 3745 (Echo) To: RANDY LAWRENCE Refer#: 3738 From: CHARLIE HITSELBERGER Read: NO Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE Excellent, Excellent! Did you base your work on the Blazin' Forth source code (both assembler code in Merlin format and all the source screens from THRU on up are available on Qlink)? Or did you tear apart the dictionary by hand (not a fun chore). I'd be interested to know what the M/MOD bug is, not because I use it all the time, but because I want to know what it is so I can either fix it, avoid it, or decide that it isn't severe enough to bother with. In the high level words, there was a bug in the paddle stuff (I think it numbered the paddles incorrectly). If you want to call my board, it's running on a C64 (not written in Forth, I'm afraid) at 703-820-2357. Sorry, 1200 baud is the highest I support. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/12/90)
Date: 09-10-90 (19:52) Number: 3747 To: RANDY LAWRENCE Refer#: 3695 From: DAVID BREEDING Read: NO Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE Believe it or not, I was just going to start this project... Hopefully you've saved me some time. I'm planning to import F83's file system to Blazin 128, which still uses blocks but uses files instead of using entire disk (I hate the MOUNT command too). I also plan to add support for 64k video ram and the 17xx REUs. I thought about doing a GEOS version, but it was SOOOoooo SLLLOOoowwww.... If you have any suggestions, or comments (I'd love your input) drop me a line. I can be reached at the ECFB or through UUNET at uunet!tnc!m0103. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/14/90)
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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/19/90)
Date: 09-16-90 (22:32) Number: 3791 (Echo) To: CHARLIE HITSELBERGER Refer#: 3754 From: DAVID BREEDING Read: NO Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE Actually F83 does allow you to switch drives, however running all of the devices together, as you suggested, is really bad. If you've ever tried to find a small program in a full disk of BForth, then you know what a pain it can be. Actually my idea is this...allow you to set up a file, like 'DavesForth.txt' and set the number of blocks you want to use. Say something like ' 5 create davesforth.txt' would create a file that is 5 blocks (1k blocks just like Starting Forth) long. You could also add to the file later like...'2 addblock' This is actually the way CP/M F83 for the C128 handles it, and it works very, very well. It also allows you to easily create and handle data files from within forth. No messy ML routines or lack of porability. I think it creates a situation where you have the best of both worlds, files and blocks. When can I see your file, and what format is it in. I have Merlin 128 so I would prefer that, however I'm flexible. Let me know, I'll be waiting... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/22/90)
Date: 09-20-90 (10:42) Number: 3809 (Echo) To: ALL Refer#: NONE From: CHARLIE HITSELBERGER Read: (N/A) Subj: BLAZIN' FORTH FOR 64/128 Status: PUBLIC MESSAGE Ok, I've gotten together all of the source for Scott Ballantyne's PD compiler for the 64 and now it is time to make a few changes. I've added in some rudimentary support for the RAM expansion and the 1581 3.5" disk drive, but it sits on top of the dictionary instead of being imbedded in where the block i/o gets done. Soon, soon.. Anyway, I was thinking of doing something major league to the dictionary. It is a linked list that traces back through the two byte pointers all the way to the last word. The bigger the dictionary gets, the longer the average search takes. This slows down compiles. What if the FIND word were to Xor together all of the bytes of the word being searched for, then Xor the two nybbles of that, to get out a four-bit hash key. Then it starts in that "thread" and searches backwards. The hashing algorithm is very simple and could be easily implemented as a code word. Anybody out there have any thoughts on this? I know it is for the lowly 64, but the technique is generally applicable. Charlie ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-21-90 (23:44) Number: 3852 (Echo)
To: PETE KOZIAR Refer#: 3796
From: JEFFERY WOOD Read: 09-26-90 (06:24)
Subj: FORTHS Status: PUBLIC MESSAGE
Ok, then I must have the second edition because I think my VIC-FORTH was
mainly FORTH-79 with a few different commands to take advantage of the
Vic's sound/graphics (well, it sounds right anyway). F83, I think I may
have that, now if only I could find the book I couud actually start
learning the language. Thanks for the help.
Jeffery
PCRelay:BLUELK -> #433 RelayNet (tm)
4.10 Blue Lake - West Linn OR - 503 655-0842 - HST
NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-21-90 (23:50) Number: 3853 (Echo)
To: ALL Refer#: NONE
From: JEFFERY WOOD Read: (N/A)
Subj: FORTH FOR THE COMMODORE Status: PUBLIC MESSAGE
I have a friend who has a Commodore Plus/4. Does anyone know if there
is a FORTH out there for it? It is compatible with the Commodore 16.
If anyone has any info like a name or service please let me know.
Thanks.
Jeffery
PCRelay:BLUELK -> #433 RelayNet (tm)
4.10 Blue Lake - West Linn OR - 503 655-0842 - HST
NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Date: 10-06-90 (10:59) Number: 3959 (Echo)
To: CHARLIE HITSELBERGER Refer#: 3745
From: RANDY LAWRENCE Read: 10-09-90 (08:44)
Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE
Sorry for the delay. A nearby lightning strike took out the modem on my
XT. I do not have Merlin, so I recoded it for TSDS. The source should
be easy to port to another standard 6502 assembler.
Check out MYBF.ARC or MYBF.ZIP in the Commodore file area (#17), or
the new files area. I could not figure out how to make a SDA, so I put
all the source in an ARC. The source will fill up a 1541, so have a
blank one handy.
|I'd be interested to know what the M/MOD bug is, not because I use it
It has been a long time since I looked at it. All I remeber is that it
does not always give the right answer. When I got BLAZIN' the source
for M/MOD was corrupted, a simple compare with an uncorupted version
should find the problem.
Chow, Randy Lawrence
---
~ EZ 1.27 ~ Direct from Hell's half hectre.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Date: 10-06-90 (10:59) Number: 3960 (Echo) To: DAVID BREEDING Refer#: 3747 From: RANDY LAWRENCE Read: 10-06-90 (23:20) Subj: 128 COMMORDORE FORTH Status: PUBLIC MESSAGE |Hopefully you've saved me some time. I'm planning to import F83's file |system to Blazin 128, which still uses blocks but uses files instead of |using entire disk (I hate the MOUNT command too). I also plan to add I did that very thing with a C128 version of FIGForth I wrote about 5 years ago. I used REL files. Each block consisted of 8 128 byte REL records. It was SLOOOW, but it worked. Let me know how it goes. chow, Randy Lawrence --- ~ EZ 1.27 ~ FORTH programmers do it with WORDS. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/05/91)
Date: 03-01-91 (19:01) Number: 1399 of 1401
To: CHARLIE HITSELBERGER Refer#: NONE
From: JAMES MEYER Read: 14-74--2 ( )
Subj: AUTO-INCREMENTING Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
CH>Another question: I'm using hardware with a 40*25 video display, and
CH>forth blocks are 64*16 by convention. Since I use the cheesy screen
CH>editor method, my code looks something like this...
CH>
CH> 9> : foo ( n m -- addr )
CH>10> bletch baz bar +! dup over
CH>11> swap rot ;
CH>
CH>disgusting an idea to even consider? Are there any 64 forthers out
CH>there, or reformed 64 forthers for that matter, who have such a beast?
CH>I'd really appreciate it!
CH>
Charlie,
This probably won't do much more than make you feel a bit
better. Be thankful that you aren't using a 22 col. wide screen
like the VIC-20 that I used to learn FORTH with.
I just lived with the limitations and *printed* the screens
when I *really* wanted to see how the looked.
Jim
---
~ EZ 1.33 ~ Psychotronic.... Ask me about it.
~ RNet 1.08D:MetroLink: Data Bit NETWork * Alexandria, VA * (703) 719-9648
PCRelay:DCINFO -> #16 MetroLink (tm) International Network
4.10 DC Info Exchange MetroLink International Hub
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp