- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Resurrecting the original IBM 1130 FORTH
- Thread starter Al Kossow
- Start date
Chuck(G)
25k Member
Wow, back in the 60's when I fooled a bit with the 1620 and 1130, I'd never heard of FORTH.
I actually heard of (and used a bit) STOIC on the 8080 before I'd heard of FORTH. Still have the STOIC disk.
I actually heard of (and used a bit) STOIC on the 8080 before I'd heard of FORTH. Still have the STOIC disk.
GeoffB17
Veteran Member
Interesting - Forth is still my preferred 'fun' language, esp with the more modern versions where you can look into the definitions and pretty much play with the language.
Never tried to do anything SERIOUS with it, mind you. So much easier with other systems.
As for STOIC - er, I've got a CP/M version on a PCW disk. I understood it was related (in some way) to Forth. I assume the version I have will be 8080 rather than Z80. My problem was that I was already into Forth when I got the STOIC, so I never really bothered with it.
Geoff
Never tried to do anything SERIOUS with it, mind you. So much easier with other systems.
As for STOIC - er, I've got a CP/M version on a PCW disk. I understood it was related (in some way) to Forth. I assume the version I have will be 8080 rather than Z80. My problem was that I was already into Forth when I got the STOIC, so I never really bothered with it.
Geoff
Dwight Elvey
Veteran Member
The article calls Forth words verbs. This is not the essence of Forth. Words are just words. They could be verbs and most are. They could be nouns, adjectives, adverbs and so on. As with most human languages, Forth is sequentially read or executed. This is what makes it so good for robotics as action are sequential. There is cause and then effect.
Finding Chuck's old first thinking of what we now call Forth is fantastic. Sequential execution and complexity hiding seem the be the essence of what his first concepts were.
I do all my home tinkering in Forth.
Dwight
Finding Chuck's old first thinking of what we now call Forth is fantastic. Sequential execution and complexity hiding seem the be the essence of what his first concepts were.
I do all my home tinkering in Forth.
Dwight
Dwight Elvey
Veteran Member
Decompiling Forth code is not the easiest thing. I'm currently doing it on the Rockwell chassis I picked up at Anchor Electronics. The code looks to be for the ICE board and also expected a video output. I only have a serial board to talk to.
The difficulty is that some of the low level operations may not have a dictionary header ( the text reference name ). This means that when nesting in, you can get garbage when looking for the header that will give you clues as to what the operation does. So, tracing is of 4 possible forms with a indirect threaded code ( the most likely used on early Forth ). It can be a pointer to the next address that is machine code, with and without a dictionary header. It can be a thread pointer that is nested like a subroutine but a string of execution addresses. Again with or possibly without a dictionary header. One can have additional types for special operations that make sense to do so. From the coding of the Forth, such things seem natural and the right way to handle the situation but to decompile the code can be tedious. You seem to be running into special operations often.
Dwight
The difficulty is that some of the low level operations may not have a dictionary header ( the text reference name ). This means that when nesting in, you can get garbage when looking for the header that will give you clues as to what the operation does. So, tracing is of 4 possible forms with a indirect threaded code ( the most likely used on early Forth ). It can be a pointer to the next address that is machine code, with and without a dictionary header. It can be a thread pointer that is nested like a subroutine but a string of execution addresses. Again with or possibly without a dictionary header. One can have additional types for special operations that make sense to do so. From the coding of the Forth, such things seem natural and the right way to handle the situation but to decompile the code can be tedious. You seem to be running into special operations often.
Dwight
clh333
Veteran Member
Fascinating to see the 1130, good as new. I have a version of Nevada FORTH (Ellis Computing) for Kaypro CP/M 2.2. I can post it on WinWorld if anyone is interested in learning more.
-CH-
-CH-
saundby
Experienced Member
The blog posts referenced above are fantastic. I'm going to have to pull the SIMH emulation of the 1130, because I'd love to dig into it, too. I only did Fortran and assembler in my time with the 1130 in the early 70s. I didn't encounter Forth till '75.
Dwight Elvey
Veteran Member
It is too bad that Carl doesn't have what was on the disk. Chuck would have things like his block editor and extensions to his simple assembler. Still, having the original source deck is fantastic.
I'm curious as to how threading is done on the 1130. These older machines had different methods of dealing with things like stacks and such. Returns were often non-re-entrant without additional code to save return addresses. This was costly in cycles if you assumed that all subroutines were re-entrant.
Dwight
I'm curious as to how threading is done on the 1130. These older machines had different methods of dealing with things like stacks and such. Returns were often non-re-entrant without additional code to save return addresses. This was costly in cycles if you assumed that all subroutines were re-entrant.
Dwight