A Forth for Gigatron?
Forum rules
Be nice. No drama.
Be nice. No drama.
A Forth for Gigatron?
Forth is a programming language and computing environment developed by Charles H. Moore throughout the 1960s.
It is ideal for resource limited computers and a means of being able to work directly on the machine without having to have be reliant on layers of unknown operating systems.
In the 1970s it became a popular choice for minicomputers and then microcomputers by 1980.
This post is really to sound out interest amongst other forum members and Gigatron Users whether we should work towards a Forth implementation for Gigatron - possibly by 2020?
I believe that there are two possible practical routes to implementation: it could be written to run directly on the vCPU or it could be written in 6502 assembly language to run on the v6502.
Directly implementing on the vCPU would give a faster running Forth - but it would take a lot of work to achieve.
Piggybacking Forth on the back of v6502 would give a slower Forth (but acceptable), and we could use one of several of the the already available 6502 implementations - possibly figForth that was released in 1980 by the Forth Interest Group.
figForth is well documented in C.H. Ting's Book http://forth.org/OffeteStore/1010_Syste ... gForth.pdf
The 6502 figForth listings are available from a number of sources including here: https://ksquiggle.neocities.org/ff6502.htm
There are far more modern implementations of Forth on the 6502 such as TaliForth 2 https://github.com/scotws/TaliForth2
There's a comprehensive User Manual for TaliForth here: https://github.com/scotws/TaliForth2/bl ... manual.pdf
Personally, I favour the 6502 route, because I believe that it is achievable, whilst the vCPU approach not only needs a knowledge of Forth implementation but also a lot of experience of working with the the vCPU itself.
If after implementing via the 6502, we may be more knowledgeable to tackle a direct vCPU implementation.
Please let me know if you are interested in Forth on the Gigatron - and what would be your preferred route. I'd like to think that we could set up a shared project.
It is ideal for resource limited computers and a means of being able to work directly on the machine without having to have be reliant on layers of unknown operating systems.
In the 1970s it became a popular choice for minicomputers and then microcomputers by 1980.
This post is really to sound out interest amongst other forum members and Gigatron Users whether we should work towards a Forth implementation for Gigatron - possibly by 2020?
I believe that there are two possible practical routes to implementation: it could be written to run directly on the vCPU or it could be written in 6502 assembly language to run on the v6502.
Directly implementing on the vCPU would give a faster running Forth - but it would take a lot of work to achieve.
Piggybacking Forth on the back of v6502 would give a slower Forth (but acceptable), and we could use one of several of the the already available 6502 implementations - possibly figForth that was released in 1980 by the Forth Interest Group.
figForth is well documented in C.H. Ting's Book http://forth.org/OffeteStore/1010_Syste ... gForth.pdf
The 6502 figForth listings are available from a number of sources including here: https://ksquiggle.neocities.org/ff6502.htm
There are far more modern implementations of Forth on the 6502 such as TaliForth 2 https://github.com/scotws/TaliForth2
There's a comprehensive User Manual for TaliForth here: https://github.com/scotws/TaliForth2/bl ... manual.pdf
Personally, I favour the 6502 route, because I believe that it is achievable, whilst the vCPU approach not only needs a knowledge of Forth implementation but also a lot of experience of working with the the vCPU itself.
If after implementing via the 6502, we may be more knowledgeable to tackle a direct vCPU implementation.
Please let me know if you are interested in Forth on the Gigatron - and what would be your preferred route. I'd like to think that we could set up a shared project.
Re: A Forth for Gigatron?
Forth is an old dream for this machine (together with LISP). v6502 is the safe route indeed. I wouldn't worry about speed. Chances are that once it works, nobody cares too much about a bit of extra performance. So better spare the frustration of optimisations that only few will know how to appreciate. Go for coolness
You can get guidance from our recent v6502 ports: Apps/{Apple1|Microchess|VTL02|MSBASIC}/. They all have some vCPU code to handle the video terminal. So you need a practical way to combine v6502 and vCPU in a single GT1 file. Each does it in a slightly different way (ideas continue to evolve): you can (manually) include a 6502 hexdump in a GCL file. Or you can include a vCPU hexdump in an ASM file that spits out a GT1. You can even enter 6502 opcodes in GCL as inline constants.
You can get guidance from our recent v6502 ports: Apps/{Apple1|Microchess|VTL02|MSBASIC}/. They all have some vCPU code to handle the video terminal. So you need a practical way to combine v6502 and vCPU in a single GT1 file. Each does it in a slightly different way (ideas continue to evolve): you can (manually) include a 6502 hexdump in a GCL file. Or you can include a vCPU hexdump in an ASM file that spits out a GT1. You can even enter 6502 opcodes in GCL as inline constants.
Re: A Forth for Gigatron?
Hi Marcel,
Thanks for the encouragement and useful advice.
I have found a modern Forth for 6502 in Tali Forth which might be a suitable candidate.
I'll be posting on the 6502.org forum to see if the project gains any traction.
Like I said elsewhere, I'm going to be taking a couple of Gigatrons with me when I present my Gigatron talk at Forth Day in Stanford next month.
There may be a few 6502 Forth old-timers over there that might be stirred into action.
Thanks for the encouragement and useful advice.
I have found a modern Forth for 6502 in Tali Forth which might be a suitable candidate.
I'll be posting on the 6502.org forum to see if the project gains any traction.
Like I said elsewhere, I'm going to be taking a couple of Gigatrons with me when I present my Gigatron talk at Forth Day in Stanford next month.
There may be a few 6502 Forth old-timers over there that might be stirred into action.
-
- Posts: 68
- Joined: 16 Jul 2019, 09:19
- Location: UK
Re: A Forth for Gigatron?
Surely the more interesting hack would be to target the real Gigatron CPU, making the FORTH "runtime" effectively a third virtual CPU.
I've never written a Forth before, but I've been thinking about doing it a lot recently. The Harvard architecture presents some challenges (although no doubt it's been handled before). I haven't thought all of this in detail, and there may be insurmountable problems, but here's some thoughts:
I've never written a Forth before, but I've been thinking about doing it a lot recently. The Harvard architecture presents some challenges (although no doubt it's been handled before). I haven't thought all of this in detail, and there may be insurmountable problems, but here's some thoughts:
- Words written in ASM would be in ROM, and probably there would also be kernel words that were written in Forth, which are also in ROM. Obviously any words written by the user would be in RAM. Therefore a thread could contain a mixture of ROM and RAM addresses - perhaps you could have some sort of 'switch' word which you compile into the threads which change how following addresses are interpreted.
- We cannot use a Direct Threaded Code model, at least not for the threads that are in RAM, because we can't execute code in RAM. So perhaps we use Indirect Threaded Code, where each thread starts with the address in ROM of the operation. Presumably jumping to a ROM address that has been loaded from RAM is not too hard, because that's what the vCPU SYS operation does. Perhaps the 'switch' word could also switch to direct threaded code, making Forth code in ROM smaller and faster.
- I wonder if there's any possibility of sharing some of the vCPU or v6502 code to save space on the ROM. vCPU would already have much of the 16-bit arithmetic etc. that we would need, but whether it's a worthwhile saving I do not know. It probably wouldn't be possible because each instruction ends with a jump back to the top of the instruction dispatch loop.
- I wonder if you could have a facility to jump into v6502 or vCPU code from FORTH code - and whether that would be useful.
Re: A Forth for Gigatron?
That sounds like it would be a bit more than a casual hack
I would try to leave the ROM alone and that would keep things a lot simpler.
From an awkward 8-bit Harvard machine, that has to handle video timing with careful instruction timing, you come up a level to vCPU, which is already a 16-bit machine and can execute out of RAM.
Several of the vCPU instructions such as ADDW, SUBW, ANDW, ORW, XORW could be used directly within the Forth kernel.
You would have to implement data stack and parameter stack structures, and find an efficient solution for the inner interpreter and for manipulating the stack data.
A compact Forth (on a 16 bit machine) could be as little as 4K bytes leaving about 8K for the users source code. (Assuming standard 32K RAM).
I would try to leave the ROM alone and that would keep things a lot simpler.
From an awkward 8-bit Harvard machine, that has to handle video timing with careful instruction timing, you come up a level to vCPU, which is already a 16-bit machine and can execute out of RAM.
Several of the vCPU instructions such as ADDW, SUBW, ANDW, ORW, XORW could be used directly within the Forth kernel.
You would have to implement data stack and parameter stack structures, and find an efficient solution for the inner interpreter and for manipulating the stack data.
A compact Forth (on a 16 bit machine) could be as little as 4K bytes leaving about 8K for the users source code. (Assuming standard 32K RAM).
Last edited by monsonite on 26 Oct 2019, 06:49, edited 1 time in total.
Re: A Forth for Gigatron?
A vCPU implementation may not be too hard. Some primitives for direct threaded code:
Zero page variables: IP, RSP, W, Next, DoColon
IP = Instruction Pointer
RSP = Return Stack Pointer
W = Work Register
Next
vCPU function to dispatch the next threaded instruction
vSP is then the data stack pointer. We can use ALLOC, LDLW, STLW on it.
For example, '+' and 'DUP' can be implemented as vCPU code:
Plus
DUP
DUP works similar:
DoColon
vCPU function to enter threaded code:
Zero page variables: IP, RSP, W, Next, DoColon
IP = Instruction Pointer
RSP = Return Stack Pointer
W = Work Register
Next
vCPU function to dispatch the next threaded instruction
Code: Select all
0202 99 30 ADDW $30 vAC = IP + vAC
0204 2b 30 STW $30 IP = vAC
0206 f6 DEEK Read word
0207 cf 18 CALL vAC Jump
For example, '+' and 'DUP' can be implemented as vCPU code:
Plus
Code: Select all
0519 ee 00 LDLW 0 Load top of stack
051b 2b 38 STW $38 Park in W
051d df 02 ALLOC 2 vSP += 2
051f ee 00 LDLW 0 Load top of stack
0521 99 38 ADDW $38 Add W
0523 ec 00 STLW 0 Store top of stack
0525 59 02 LDI 2
0527 cf 32 CALL $32 Next
DUP works similar:
Code: Select all
053a ee 00 LDLW 0 Load top of stack
053c df fe ALLOC $fe vSP -= 2
053e ec 00 STLW 0 Store top of stack
0540 59 02 LDI 2
0542 cf 32 CALL $32 Next
DoColon
vCPU function to enter threaded code:
Code: Select all
020d 21 34 LDW $34 RSP -= 2
020f e6 02 SUBI 2
0211 2b 34 STW $34
0213 21 30 LDW $30 Save old IP
0215 f3 34 DOKE $34
0217 21 1a LDW vLR vCPU return address
0219 2b 30 STW $30 becomes new IP
021b f6 DEEK Fetch first instruction
021c cf 18 CALL vAC Direct threading
-
- Posts: 68
- Joined: 16 Jul 2019, 09:19
- Location: UK
Re: A Forth for Gigatron?
Well to answer the original question, is there interest in Forth on the Gigatron, it seems clear that the answer is 'yes'. I must admit that I've been well and truly "nerd sniped".
Of the three paths of v6502, vCPU , and the 8 bit Gigatron CPU, it seems clear that the v6502 is the path of least resistance. TaliForth2 is explicitly designed to be easy to port to homemade computers, so it should not be too hard to bring up. The only problems that I can foresee is that it's written for the 65c02, and so may make use of instructions that the Gigatron doesn't support (I believe that v6502 is emulating the NMOS chip?).
The vCPU is also clearly viable, based on the code that Marcel posted.
For me, I still think that the native code approach sounds like the most fun. I may be underestimating the effort involved, but I can't imagine that it's insurmountable. Any instruction that can be run on the vCPU has already been written once, and I think I've designed a NEXT routine that handles the decision whether to run another word or abort. I want to calculate the timings to see if it's viable before sharing it. I'm not sure how hard it will be to get to the point where I can stop writing assembly, and start writing Forth. Looking through Jonesforth.S, the biggest challenge I see is dictionary lookup.
I'm inclined to continue looking at a native implementation, but please don't consider this as me licking the Gigatron Forth cookie: to say that I often don't finish what I start would be an understatement!
Of the three paths of v6502, vCPU , and the 8 bit Gigatron CPU, it seems clear that the v6502 is the path of least resistance. TaliForth2 is explicitly designed to be easy to port to homemade computers, so it should not be too hard to bring up. The only problems that I can foresee is that it's written for the 65c02, and so may make use of instructions that the Gigatron doesn't support (I believe that v6502 is emulating the NMOS chip?).
The vCPU is also clearly viable, based on the code that Marcel posted.
For me, I still think that the native code approach sounds like the most fun. I may be underestimating the effort involved, but I can't imagine that it's insurmountable. Any instruction that can be run on the vCPU has already been written once, and I think I've designed a NEXT routine that handles the decision whether to run another word or abort. I want to calculate the timings to see if it's viable before sharing it. I'm not sure how hard it will be to get to the point where I can stop writing assembly, and start writing Forth. Looking through Jonesforth.S, the biggest challenge I see is dictionary lookup.
I'm inclined to continue looking at a native implementation, but please don't consider this as me licking the Gigatron Forth cookie: to say that I often don't finish what I start would be an understatement!
Re: A Forth for Gigatron?
All approaches will work:
- The native 8-bit approach is certainly most impressive. I believe it will be a big undertaking, especially as a first project.
- The vCPU approach will get quick initial results, but it will then drag on towards completion.
- The v6502 approach will have a full Forth fastest, but with a bit of a slow start. 65C02 instructions must be replaced in the reference implementation, or added to v6502. It's easy to add instructions to v6502, but very hard to add new addressing modes.
- Attachments
-
- Screenshot 2019-10-29 at 14.19.51.png (365.6 KiB) Viewed 10209 times
-
- Posts: 68
- Joined: 16 Jul 2019, 09:19
- Location: UK
Re: A Forth for Gigatron?
You weren't kidding when you said that writing Forth in native code "will be a big undertaking, especially as a first project"!
I thought I should just post to say that I'm still trying, and making steady if unimpressive progress. I think I have the timing sensitive code done (at least for now - it really wants throwing out and starting over, as it's really high overhead), so I hope that things will speed up a bit.
Following Marcel's advice on another thread, I've been blogging some of my progress on a Hackaday.io project, and I'm committing my code to a fork of the gigatron-rom repository in Contrib/psr.
The only things I think worth discussing here at this point (especially in light of the other thread on native code), is that I've made a Python extension out of gtemu.c, and a wrapper object which allows me to unit-test my code from Python. By dropping into PDB from my tests I can single-step my code in the emulator observing what is going on. This has been helpful to me, so anyone who is doing native-code might want to examine it - even though it's currently full of hacks.
I intend to post here again if and when I reach parity with the vCPU code that Marcel posted.
I thought I should just post to say that I'm still trying, and making steady if unimpressive progress. I think I have the timing sensitive code done (at least for now - it really wants throwing out and starting over, as it's really high overhead), so I hope that things will speed up a bit.
Following Marcel's advice on another thread, I've been blogging some of my progress on a Hackaday.io project, and I'm committing my code to a fork of the gigatron-rom repository in Contrib/psr.
The only things I think worth discussing here at this point (especially in light of the other thread on native code), is that I've made a Python extension out of gtemu.c, and a wrapper object which allows me to unit-test my code from Python. By dropping into PDB from my tests I can single-step my code in the emulator observing what is going on. This has been helpful to me, so anyone who is doing native-code might want to examine it - even though it's currently full of hacks.
I intend to post here again if and when I reach parity with the vCPU code that Marcel posted.
Re: A Forth for Gigatron?
Your HaD logs and GitHub commit messages are super enjoyable to read. You made fantastic progress and it looks well under control. Actually, I believe you've cleared the biggest obstacles already. The ability to fetch threads from ROM is super cool. I struggle to achieve the same for vCPU. Very impressive already!