A Forth for Gigatron?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

A Forth for Gigatron?

Post by monsonite »

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.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: A Forth for Gigatron?

Post by marcelk »

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.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: A Forth for Gigatron?

Post by monsonite »

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.
qwertyface
Posts: 68
Joined: 16 Jul 2019, 09:19
Location: UK

Re: A Forth for Gigatron?

Post by qwertyface »

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:
  • 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.
monsonite
Posts: 101
Joined: 17 May 2018, 07:17

Re: A Forth for Gigatron?

Post by monsonite »

That sounds like it would be a bit more than a casual hack :D

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.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: A Forth for Gigatron?

Post by marcelk »

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

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
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

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

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
qwertyface
Posts: 68
Joined: 16 Jul 2019, 09:19
Location: UK

Re: A Forth for Gigatron?

Post by qwertyface »

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!
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: A Forth for Gigatron?

Post by marcelk »

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.
In the meantime I've embedded the vCPU-based inner interpreter in a little test program and put it in GitHub as Contrib/kervinck/Forth.gcl. Despite the name, it's not a Forth yet but just the inner interpreter bundled with some hand-compiled words for testing. It already has CR, EMIT, KEY, "dot" (.) and TYPE. On startup it prints (1) some text, (2) a number and (3) the dictionary. After that it enters a command line. There's no outer interpreter. Anything the user types is simply echoed. That's it, just an empty shell, 1K in size. But I believe this can be expanded into a true Forth, one word at a time. Feel free to fork, because I don't plan to take it much further any time soon.
Attachments
Screenshot 2019-10-29 at 14.19.51.png
Screenshot 2019-10-29 at 14.19.51.png (365.6 KiB) Viewed 9732 times
qwertyface
Posts: 68
Joined: 16 Jul 2019, 09:19
Location: UK

Re: A Forth for Gigatron?

Post by qwertyface »

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.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: A Forth for Gigatron?

Post by marcelk »

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!
Post Reply