Toddy Forth - a new ZX81 forth implementation

Discussion about ZX80 / ZX81 Software
User avatar
kmurta
Posts: 147
Joined: Tue Sep 01, 2009 5:04 am
Location: Belo Horizonte - BR
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by kmurta » Wed Jan 12, 2011 2:51 pm

Moggy wrote:Hi Kmurta
I altered key repeat rate by compiling the 2@ and 2! words from the library file and using them to alter then check address 17710 ,so simple an answer and the end result works great. :D
And it worked?!

You dont need 2@ and 2! to alter a 16 bits value at memory. Indeed, 2@ and 2! manipulates 32 bits (4 bytes) and if you use it to alter value at address 17710, the contents of addresses 17712 and 17713 will be altered too, corrupting the code of next instruction:

Code: Select all

0527   452D             ST_DLY:
0528   452D 21 00 03            ld      hl,$300
0529   4530 22 7B 40            ld      ($407b),hl
0530   4533 C9                  ret
I'm glad that's been helpful to you, thanks.
1 x ZX81, 2 x TK85 , 1 TK82C, 1 TK95, 1 x Ringo R470, 1 x Alphacom 32 printer, 1 x ZXpand
ZeXtender board, Joy81 - Programmable Joystick Controller, Turbo Sound 81
http://zx81.eu5.org

Moggy
Posts: 1798
Joined: Wed Jun 18, 2008 2:00 pm

Re: Toddy Forth - a new ZX81 forth implementation

Post by Moggy » Wed Jan 12, 2011 5:49 pm

kmurta wrote:
Moggy wrote:Hi Kmurta
I altered key repeat rate by compiling the 2@ and 2! words from the library file and using them to alter then check address 17710 ,so simple an answer and the end result works great. :D
And it worked?!

You dont need 2@ and 2! to alter a 16 bits value at memory. Indeed, 2@ and 2! manipulates 32 bits (4 bytes) and if you use it to alter value at address 17710, the contents of addresses 17712 and 17713 will be altered too, corrupting the code of next instruction:

Code: Select all

0527   452D             ST_DLY:
0528   452D 21 00 03            ld      hl,$300
0529   4530 22 7B 40            ld      ($407b),hl
0530   4533 C9                  ret
I'm glad that's been helpful to you, thanks.

Hi Kmurta

First of all I only had time to do this on an emulator and it worked so far.
Is it possible that as I only 2! a 16 bit number (1000) the remaining 16 bits are left unaltered so allowing me to "get away with it"? ;)
Or are all 32 bits affected no matter what number is 2! meaning that at some time I will run into a corrupt instruction? :(

How would You have altered the contents of 17710?
Does everything have to be recompiled withTASM after altering the address in the ASM file?
I ask because the only assemblers I have used are on real 81's ( memotech or software based ZXAS) I am not really into pc based assemblers though I realise how useful they are.

Sorry to be a nuisance Kmurta, but this is a steep learning curve for me :?

Regards Moggy

User avatar
kmurta
Posts: 147
Joined: Tue Sep 01, 2009 5:04 am
Location: Belo Horizonte - BR
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by kmurta » Thu Jan 13, 2011 1:09 am

Is it possible that as I only 2! a 16 bit number (1000) the remaining 16 bits are left unaltered so allowing me to "get away with it"? ;)
Or are all 32 bits affected no matter what number is 2! meaning that at some time I will run into a corrupt instruction? :(
2! always changes 4 bytes in memory, although you has only two bytes at stack.
How would You have altered the contents of 17710?
Does everything have to be recompiled withTASM after altering the address in the ASM file?
To handle 2 bytes at memory are used the words @ and ! and to handle a single byte the words are C@ and C!. To learn more, take a look at this tutorial: http://galileo.phys.virginia.edu/classe ... primer.htm

And no need to recompile the code after changing the address.

Is no nuisance, feel free to ask.
1 x ZX81, 2 x TK85 , 1 TK82C, 1 TK95, 1 x Ringo R470, 1 x Alphacom 32 printer, 1 x ZXpand
ZeXtender board, Joy81 - Programmable Joystick Controller, Turbo Sound 81
http://zx81.eu5.org

Moggy
Posts: 1798
Joined: Wed Jun 18, 2008 2:00 pm

Re: Toddy Forth - a new ZX81 forth implementation

Post by Moggy » Thu Jan 13, 2011 6:22 pm

Thanks Kmurta

Plenty here for Me to get on with :D

Many thanks again.

Regards Moggy.

User avatar
Forthretro.new.fr
Posts: 32
Joined: Thu Nov 19, 2009 9:34 pm

Re: Toddy Forth - a new ZX81 forth implementation

Post by Forthretro.new.fr » Fri Mar 18, 2011 7:52 pm

Hello Kmura, (Hello Kelly)

Amazing !

Congrats.

BTW : Thanks a lot for giving to us the *.ASM source.

Dominique

User avatar
mrtinb
Posts: 987
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by mrtinb » Wed Apr 20, 2016 12:26 pm

Hi :)

I've looked interestingly at forth on my C64 and on the ZX81, but every time I realised that final software would be cumbersome to load.

A user would either have to install an EPROM in their computer or first load a forth envionment to run the software. This seems like a useless solution if you want to share your software.

Somehow Toddy Forth seems to have overcomed this. But there is no documentation on how to create an application from the source.

I can see it can be done, by the example software. Can anyone explain how this is done?
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube

User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by RetroTechie » Wed Apr 20, 2016 3:07 pm

mrtinb wrote:Hi :)

I've looked interestingly at forth on my C64 and on the ZX81, but every time I realised that final software would be cumbersome to load. (..) This seems like a useless solution if you want to share your software.
Compared with what? People share Windows-based software all the time. Which requires a 'runtime environment' of GB's+ harddisk space and 100's of MB RAM. This seems to be no problem in most cases. :roll: It just depends on available storage options & how well a system is organized.

Afaik there's basically 2 kinds of Forth implementations:
a) Compiled: upon starting a program, program code gets compiled in-memory into snippets of machine code that do the actual work. This happens near-instantly. Resulting program can reach machine-code like speeds, but there may be some memory overhead because source + compiled program are in memory @ the same time.
b) Interpreted: this works like most BASIC interpreters, where each statement is evaluated and executed one at a time. 100x executed = 100x read & evaluated. But do to Forths' simplicity, the "inner interpreter" loop can be very simple. And thus, quite fast. Not quite as fast as machine code or compiled Forth, but many times faster than BASIC or other interpreted languages.

No idea what type Toddy Forth is. In both cases if the Forth environment loads from tape, you have the in-memory overhead of that too.
A user would either have to install an EPROM in their computer
That would seem like a 'convenient' method in the case of a ZX81. This could come as a module to plug into the expansion port. Or perhaps an internal 'multi-ROM' with a switch to select between Forth and regular ZX81 BASIC. Again this isn't much different from other systems: iirc, for example with the Philips P2000, its BASIC came in the form of a cartridge. No cartridge, no BASIC.
or first load a forth envionment to run the software.
Inconvenient how? Depends on the size. Say you have a compiled Forth, 3K source compiles into 1K Z80 code, the runtime is 2K, this gets combined into a single 3K binary that loads directly from BASIC. Much, much better than a 10K BASIC program that does the same & runs much slower. So it all depends on the numbers... too bad ZX81 tape storage is so poor.

But if you're working in Forth, it makes sense not to produce BASIC-loadable code, but load the Forth environment first (once!), and then load Forth program(s) into that. Exactly the same as with BASIC, only now you have a Forth compiler/interpreter rather than a BASIC interpreter in memory.
Somehow Toddy Forth seems to have overcomed this.
:?: Doubtful - it will have to walk one of above paths in order to work.
But there is no documentation on how to create an application from the source.
Like explained... Probably there's some kind of editor built-in, a way to store programs on tape & load them back in, and some "execute" command. Which is all you need.

But lack of documentation is annoying indeed. So far there's only 2 Forth implementations that made it into my ZX81 library (Artic's ZX-Forth and Tree4th/H4th). Both only because I could find documentation on how to use those. Imho: no docs = no use. :cry: No matter how brilliant the piece of software in question was written.

Moggy
Posts: 1798
Joined: Wed Jun 18, 2008 2:00 pm

Re: Toddy Forth - a new ZX81 forth implementation

Post by Moggy » Wed Apr 20, 2016 5:49 pm

RetroTechie wrote:
mrtinb wrote:Hi :)


...But lack of documentation is annoying indeed. So far there's only 2 Forth implementations that made it into my ZX81 library (Artic's ZX-Forth and Tree4th/H4th). Both only because I could find documentation on how to use those. Imho: no docs = no use. :cry: No matter how brilliant the piece of software in question was written.

+1 on this.
I was originally very enthusiastic about Toddy Forth but after much time and usage sadly became very disenchanted with it which is a shame as it could have been so much better.

Kelly originally created this as an emulator project and in place of an in-program editor you have to use note/word pad to write routines and then compile from there, an on-board editor should have been the way to go.

He then created a Zxpand version which, whilst laudable, in my view had a couple of things against it, one having to still edit on a PC and then transfer to the xpands card is a bit of a run-around and also for some reason he uses his own keyboard reading routine which whilst workable on standard ZX81's with a notable key lag, is totally unusable for those of us fortunate enough to have external keyboards, the problem being one key-press results in many chrs being screen printed and more time is spent backspacing/deleting than programming and no altering of the debounce variable setting, as he once recommended to me alters this!
This is also noticeable when using the file rename function on Zxpand commander which I suspect is an adaptation of this same keyboard routine.

Another thing it lacks is a call to break during run time(something H4th possesses) if you don't think that's important then try executing something that has a multi-step DO LOOP, pulling the plug being the only way to stop it.

In conclusion.

Toddy/Camel forth.

Plus. Reasonably quick.
most primitives included.
good assembler.
Xpand compatible.
minus. No editor.
No manual.
No break facility.
No way that I can fathom to use the full 32k of the Xpand( if I'm wrong I apologise now) which is needed as around 5k is walloped by the interpreter alone.
As the interpreter is ram based it means all your routines include a 5k overhead when saving, H4th being Rom based overcomes this allowing for longer routines to be written.

Despite being based on FIG/Camel forth I found when using examples from Forth publications they either would not compile or crashed at run-time and the admittedly splendid examples that accompany Toddy forth are re-jigged Jupiter Ace programs re-written using mainly the assembler to over come the lack of comparability and give an impression of fast execution so hardly true Forth. To my way of thinking if two thirds of the routine relies on the assembler then write the rest of the routine in assembler as it hardly represents/resembles Forth.

ZX81 fig forth.
I found this to be SLOOOOW , no faster than basic, a tiresome tape loading of editor screens(one only at any one time) which I could never get to work etc mean a pass on this for me.

H4th

Plus. Fairly good if slightly bugged manual.
On board editor.
Rom based so most ram(15k) free.
Multi-tasking capabilities.
32 and 64 bit maths functions.
Break and cold start function via key-press.
Time dependent task setting ability.
Own keyboard scanning routine and repeat that actually works.

Minus. Uses own unique tape save/load which best described as barely adequate.(save everything three times)
Not Xpand compatible therefore tape only.
Claims to have Real time clock which I found to be so in-accurate as to be unusable.
Whilst possessing 32/64 bit maths there is no clear explanation in manual of how to extract a usable result.

Anyhow in my opinion H4th is the best Forth for the 81 and possesses most of what's required for a standard ZX81 based version of Forth.

User avatar
mrtinb
Posts: 987
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by mrtinb » Thu Apr 21, 2016 2:31 pm

RetroTechie wrote:But lack of documentation is annoying indeed. So far there's only 2 Forth implementations that made it into my ZX81 library (Artic's ZX-Forth and Tree4th/H4th). Both only because I could find documentation on how to use those. Imho: no docs = no use. :cry: No matter how brilliant the piece of software in question was written.
Moggy wrote:Toddy/Camel forth.

Plus.
  • Reasonably quick.
  • most primitives included.
  • good assembler.
  • Xpand compatible.
minus.
  • No editor.
  • No manual.
  • No break facility.
  • No way that I can fathom to use the full 32k of the Xpand( if I'm wrong I apologise now) which is needed as around 5k is walloped by the interpreter alone.
  • As the interpreter is ram based it means all your routines include a 5k overhead when saving, H4th being Rom based overcomes this allowing for longer routines to be written.
I've found the documentation for Micro Sistemas Forth which is the predecessor to Toddy Forth: Unfortunately it's in Portuguese (so I need Google Translate). Seems like the lack of an editor goes back to this version from the Portuguese magazine Micro Sistemas.
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube

User avatar
mrtinb
Posts: 987
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Toddy Forth - a new ZX81 forth implementation

Post by mrtinb » Sat Apr 23, 2016 10:34 pm

Moggy wrote:ZX81 fig forth.
I found this to be SLOOOOW , no faster than basic, a tiresome tape loading of editor screens(one only at any one time) which I could never get to work etc mean a pass on this for me.
Sounds like Artic Computing Forth. I've tried it and can't load the editor either. (I've tried both with EightyOne, ZXsp and ZesaruX.)

I'm thinking about typing (or load to RAM) the editor from Artic Computing into Toddy Forth (which misses an editor).

(And I think I need to find an implementation of the keyword SEE, which is missing as well.)
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube

Post Reply