History of Forth on 6502

BigEd · Post by **BigEd** » Sat Dec 03, 2011 3:18 pm

I've been trying to trace out the early history of Forth implementations on the 6502.

From this brief overview and other sources, it seems that Robert Selzer and Bill Ragsdale might have been first, with a commercial Forth, for the Jolt kit machine.

Bill tells the story here that he got the very first Jolt in 1976.

In a much later interview here (pdf, page 20) Bill tells how he tidied up version 3.6 of that commercial Forth and released it into the public domain to form the basis of FIG Forth. Sounds like that would be '79. This was in response to two things: FORTH Inc saying that they wouldn't be doing a Forth for personal computers, and there being a PET Forth which was "terrible".

Based on that 6502 version, and with enhancements from the University of Utrecht, FIG organised a set of pairs of programmers to write versions of Forth for several processors, using the same spec and the same labels (in the same order). That was to be a "Rosetta stone" for FIG Forth.

Comments and corrections welcome!

Cheers
Ed

Edit to add: Forth Inc's history says it was in 1978 that Ragsdale and Seltzer wrote their Forth for Jolt, subsequently to asking Forth Inc to write one for 6502.

I think it's interesting that Seltzer had previously written for 6800. People in that position might be able to comment on the differences - perhaps, advantages and improvements - of the 6502.

Dr Jefyll · Post by **Dr Jefyll** » Sat Dec 03, 2011 4:35 pm

Thanks, Ed. Here are a few dates from printed documents in my possession.

June, 1980 - 6809 Fig-Forth Assembly Source listing release 1 v1.0
Sept, 1980 - Fig-Forth 6502 Assembly Source listing release 1.1
Nov, 1980 - Fig-Forth Installation Manual; Glossary; Model; Editor. Release 1
Oct, 1983 - Fig-Forth 68000 Assembly Source listing release 1.1

In addition to 6502 Fig-Forth, I also used Bill Ragsdale's RPN style 6502 assembler (which is written in Forth, of course). The contribution he and his colleagues made is enormous.

-- Jeff

BigEd · Post by **BigEd** » Sat Dec 03, 2011 4:45 pm

Thanks Jeff!

I notice our own chitselb has written a new Forth for PET and was previously casting around on comp.sys.cbm for an earlier PET forth - perhaps the "terrible" one. That thread contains a similar history to what I found - hopefully coherent with my findings.

Cheers
Ed

GARTHWILSON · Post by **GARTHWILSON** » Sat Dec 03, 2011 8:29 pm

Quote:

I think it's interesting that Seltzer had previously written for 6800. People in that position might be able to comment on the differences - perhaps, advantages and improvements - of the 6502.

When I was researching it just over 20 years ago at work, the small performance difference I came up with was that the 6502 FIG Forth ran about 25% faster than the 6800 FIG Forth at a given clock speed.

BigEd · Post by **BigEd** » Sat Dec 03, 2011 8:55 pm

Thanks for the datapoint!

Edit to add: Found a quote from back in 2001, when you said:

Quote:

I'd like to see Ragsdale's 6800 Forth kernel to compare the 6502 one, because Forth requires a constant stream of instructions using these addressing modes. If I remember correctly, his 6800 kernel was about 80% as fast at a given clock rate (20,000 primitives per second at 2MHz versus 25,000 for 6502), but I don't know any details.

along with other interesting commentary

chitselb · Post by **chitselb** » Sat Aug 04, 2012 4:29 am

What I really want to know is how did early 6502 Forth implement virtual memory on cassette tape? My approach is to use the PET sequential file (192-byte blocks) and simply copy from one deck to the other. Slow, cumbersome. It would probably be easier to use the file system and load/save chunks of source code as text files, but less Forth-like

BigEd · Post by **BigEd** » Sat Aug 04, 2012 5:38 am

I would imagine people were hooking up floppy drives, although I could be wrong. In the UK floppies were very late to arrive. I was reminded of the Hobbit tape drive which uses microcassettes and crucially can be controlled by the host. I don't know if it was UK only or when it appeared. Here's a feature from 1983 (pdf)
http://acorn.chriswhy.co.uk/docs/Mags/A ... Hobbit.pdf
but I would have said it dates from the 70s.
Cheers
Ed

BigDumbDinosaur · Post by **BigDumbDinosaur** » Sat Aug 04, 2012 7:17 pm

BigEd wrote:

I would imagine people were hooking up floppy drives, although I could be wrong. In the UK floppies were very late to arrive. I was reminded of the Hobbit tape drive which uses microcassettes and crucially can be controlled by the host. I don't know if it was UK only or when it appeared. Here's a feature from 1983 (pdf)
http://acorn.chriswhy.co.uk/docs/Mags/A ... Hobbit.pdf
but I would have said it dates from the 70s.
Cheers
Ed

I vaguely remember the Hobbit tape system. There was something like it that was developed for the Commodore 64 as an alternative to the datasette—mostly to get better performance—but I don't think it used a microcassette. In any case, once the cost of the 1541 floppy drive came down and Commodore fixed its reliability issues, few US buyers went with tape. I never used a datasette with my C-64, so you've just read the extent of my knowledge about it.

GARTHWILSON · Post by **GARTHWILSON** » Sat Aug 04, 2012 8:15 pm

I suppose this is getting off the Forth topic, but the Hobbit sounds like the Hewlett-Packard HP82161A HPIL microcassette drive, which I have two of for my HP hand-held computers.

The picture shows it approximately actual size on my monitor. It was tiny compared to the separate disc drives of the day. The microcassette being used is under the door on the right, and the door on the left holds two more microcassettes side by side. Data transfer speed was about 400 bytes per second, going in 256-byte start-stop bursts. There is no capstan. It is my understanding that the spooling motors were direct-drive (no belts or gears) and had coreless armatures to reduce mass so it could spin up instantly and stop on a dime, which is rather impressive to watch when it searches the FAT and then spins out to the desired file, reads or records data, and spins back. Other than fast-forwarding or rewinding, the only time it runs at an even, continuous speed is when it's formatting a tape. Otherwise it goes in those bursts. A $10 tape holds about 128KB IIRC! I had data arrays bigger than that, but my typical file size meant that dozens of files fit on one tape.

BigEd · Post by **BigEd** » Sat Aug 04, 2012 8:52 pm

Ah, here we go: the Hobbit for the NASCOM - aka UltraDrive, but same manufacturer (Ikon)

Hmm, but also same year - 1983/1984 (seems a bit late for a NASCOM) - I would have said I saw advertisements in the late 70s for some kind of automated-transport tape-based data storage system.

(Not to confuse these systems with tape-loop systems.)

Interesting point about the lack of capstan. Also, I see the HP unit is also 1980's vintage: see this PDF
http://www.hpmuseum.net/pdf/KeyNotes_19 ... es_OCR.pdf

Edit: replaced links to broken site with links to a different site.

legacy · Post by **legacy** » Sun Dec 16, 2012 11:35 pm

anyone has schematic of this kind of storage things ?

BigEd · Post by **BigEd** » Tue Dec 18, 2012 12:20 pm

You might need to ask very widely to find someone with a schematic: the cctalk mailing list would be one additional place to ask. There are very active forums for Atari and Commodore machines, but neither of those machines would be likely to need a drive like this - even so, some of the people there might have an idea. (Similarly the cbm-hackers mailing list, and any number of retro-machine Usenet groups.) Another possibility is to mail as many computer museums as you can find.
Good luck!
Ed

whartung · Post by **whartung** » Tue Dec 18, 2012 5:54 pm

BITD, working on Alpha Micros, they backed up to VHS tapes using VCRs much like we used to use cassette tapes. Later, they were early adopters of Exabyte drives, which used Betamax tapes.

The games with these micro-cassette drives (or similar things) is fast tape speed and a sensor to capture partitions on the tape (file start/stop, etc.).

One of the devices mentioned above talked about 30sec rewind times and "average" file seek time of 13 second (which is suspiciously close to half the time to rewind the tape). With an adequate driver that "knows" where it is on the tape, the system can know whether to go forward or back to find a specific entry.

But the dark side is how to write data to the tape and not overwrite other chunks. I've heard of systems that would "format" tapes, and I guess in the end it's not much different from a floppy disk, just with sequential access. I don't know if there was much need for tolerances based on tape speed or stretch. I assume you can position the tape with reasonable precision.

GARTHWILSON · Post by **GARTHWILSON** » Tue Dec 18, 2012 7:40 pm

The Hewlett-Packard microcassette drive I showed above does format the tape, and even when it is spinning out to a file, the head is in contact with the tape and the machine is reading its position on the tape so it doesn't have to count spindle revolutions or something like that. It will never get lost. It keeps a FAT just as on a disc, and it will never accidentally overwrite a previous file. (It does not allow fragmentation though. New files must fit all in one space, whether it's at the end or a space left available by the deletion of previous files.) All the tapes were the same length, but I'm not sure it would matter much since the formatting process would find the end anyway and put the info at the beginning of the tape how many "sectors" are available before the end. If you wanted to store another file that was too long for any remaining available parts of the tape, it would give that error message. It really was intelligent.

chitselb · Post by **chitselb** » Fri Mar 07, 2014 9:43 am

BigEd wrote:

Thanks Jeff!

I notice our own chitselb has written a new Forth for PET and was previously casting around on comp.sys.cbm for an earlier PET forth - perhaps the "terrible" one. That thread contains a similar history to what I found - hopefully coherent with my findings.

Cheers
Ed

Eureka! I have found it! There were hints on the volksForth pages about it also running on a PET, but I haven't been able to find a binary copy of volksForth for PET. Most of my experience comes from Blazin' Forth on a C=64 and MMSForth on a TRS-80 Model 4. However, now I do have this Fig Forth 1.0, and in fact, this is the first running Forth I have ever used on a PET. Cassette support is definitely a thing here.

It comes up and says "FIG FORTH 1.0" and it even uses the Commodore zeropage CHRGET routine at $0070-$0087, as well as making a copy of stuff that BASIC wants to have around (as part of the cold start routine.) Hopping in and out of Forth/TIM/BASIC works. I haven't yet figured out the setup steps required for using BLOCK with the disk ('2 BLOCK' returns $C9FD, an address in ROM. '3 BLOCK' hangs the machine).

So I'm in there digging around trying to figure out what does what. Here are tick ( ' ) addresses of a few words I'm interested in and some early findings. To get around the problem of the Commodore tape i/o routines failing out to a BASIC READY prompt, it seems that the authors of this Forth could have just restored BASIC pointers prior to doing any *dangerous* operations. But it is late, I am lazy, and manually decompiling secondaries is tedious, so I do not know this for sure. It is pretty clear that this Forth doesn't use BLOCK with the tapes, and probably no commie Forth ever did, but it does provide words for save/load operations.

Someone on the cbm-hackers list wrote:

Although I never even tried to used it, fig-forth 1.0 survived on my old disks.
There is a 16k and a 32k version.
I placed a .d82 image at http://www.idealine.info/CBM/forth.d82

Code: Select all

*** commodore basic 4.0 ***

 31743 bytes free

ready.
load"forth32k.4",8

searching for *
loading
ready.
run

fig-forth  1.0
2 block hex .
-3603
mon

b*
     pc  irq  sr ac xr yr sp
.;  1cba e455 b0 00 ff 00 fd
.x
ready.
list

 10 sys1037
ready.

word    address  notes
device# 1e3f     variable, contains '8'
-c->    1e4a     no idea what this is yet
dim()   1e8a
namset  1f69    looks like a secondary
setdevice# 2004
cassload 201d
memset  204a
cassave 2068
verify  20cd
cass1   20e7    : cass1   ( -- )  1 device# ! ;
cass2   20f9    : cass2   ( -- )  2 device# ! ;
syssize 210d

device# ?
1
cass2 device# ? 
2
device# ?
2
cass1
device# ?
1
cold

fig-forth  1.0
device# ?
1
bye

ready.
run

fig-forth  1.0
device# ?
1

History of Forth on 6502

History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: History of Forth on 6502

Re: