FIF. Another FORTH.

Discussion about ZX80 / ZX81 Software
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: FIF. Another FORTH.

Post by Moggy »

Understood Alan.

I remember when Sir Morris asked me to beta test his MIDI jobbies for the 81 (This being my bag) after 10 minutes of techno spiel of what pours out of the spand all I could think to say was "do you know I keep thinking it's Tuesday" :oops:
roganjosh
Posts: 100
Joined: Thu Jun 14, 2018 12:59 pm

Re: FIF. Another FORTH.

Post by roganjosh »

mrtinb wrote: Wed May 26, 2021 10:35 pm Had a little play with the UDG version tonight. The UDG4ZXpand is below the keyboard controller.

A little question though. If I want to add new words with machine code, could you describe how to pass arguments. Are you just using the stack, or is top of stack a register, and which registers should be preserved?
I love the monitor.

You ask a difficult question as you'd usually use an integrated Forth Assembler (which I've no real wish to write). One way of doing it would be to devise a defining word. I can think about that. A simple alternative, though, if the code is short enough, would be to add it byte by byte. So, if you wanted to do

Code: Select all

ld hl,$6000
ld (hl),$77
which has the bytes: $21, $00, $60, $36, $77 you might type

Code: Select all

HEX
CREATE AAA HERE DUP 2- ! 21 C, 00 C, 60 C, 36 C, 77 C, NEXT
Then typing

Code: Select all

AAA
6000 C@ .
should display 77.

You can always load in a block of precompiled machine code and use CALL, so avoiding the problem.

In short things are not set up to make it really easy at the moment. The same could be said of BASIC though.


As far as registers are concerned, don't touch the usual suspects (IX, IY and those precluded in the alternative set). For FIF you must preserve BC (very rarely DE too if you're messing about with Forth internals).


Alan
roganjosh
Posts: 100
Joined: Thu Jun 14, 2018 12:59 pm

Re: FIF. Another FORTH.

Post by roganjosh »

FIF 1.01 is now available.

This corrects a bug in the Chroma 81 version whereby the LIST word would never stop listing. I also took the opportunity to correct a couple of typos in Chroma 81.txt (thanks to Paul Farrow) and to document the 'various author' words in screens 8 & 9, except for the ones related to SQRT which I'll need to study.
There is an example of the ROOT use elsewhere in this thread.

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

Re: FIF. Another FORTH.

Post by Moggy »

My day just got better. :D

The PDF for SQRT is on page 4 of the thread for anyone interested.
roganjosh
Posts: 100
Joined: Thu Jun 14, 2018 12:59 pm

Re: FIF. Another FORTH.

Post by roganjosh »

mrtinb wrote: Wed May 26, 2021 10:35 pm A little question though. If I want to add new words with machine code, could you describe how to pass arguments. Are you just using the stack, or is top of stack a register, and which registers should be preserved?
I fear I may have misunderstood you on re-reading the question. Yes, function arguments are always passed on the computation stack. However, the FIF stack is implemented differently from some other Forths i.e. the computation stack is not the machine stack.

So, if you were to write a machine code word that needs to pop a number off the stack you need to make a call to PopOne which is at address 40DB in all versions using a ZXpand. That function pops the top of the stack into HL. There is another function which pushes HL to the stack called, unsurprisingly, PushOne which is at address 40e9.

I doubt their locations will change but, just to be sure, I'll add a jump vector table to the next release.

And yes, you still have to preserve BC but those two functions don't alter BC.

Alan
roganjosh
Posts: 100
Joined: Thu Jun 14, 2018 12:59 pm

Re: FIF. Another FORTH.

Post by roganjosh »

FIF 1.02 is now available.

This fixes a bug with CLRATT, a couple of minor bugs/features in SETPOS and a rewrite of the DO/LOOP/+LOOP comparisons (negative steps were prone to error). ZXpand versions now have a jump table at location $441A. Two calls and one jump are provided:

$441A = PopOne (calling this will pop hl from the computation stack)
$441D = PushOne (calling this will push hl to the computation stack)
$4420 = NEXT (jumping here will terminate a FORTH primitive [a word written in machine code])

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

Re: FIF. Another FORTH.

Post by mrtinb »

I’m glad you reread my question, because this was exactly an answer to my question.

The “monitor” is a cheap B/W TV with no composite input, the signal is via the antenna socket. (Currently I’m working on building a ZX81 into a small French Minitel terminal. You can read a little about it on another thread in the forum.)
Martin
https://zx.rtin.be
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: FIF. Another FORTH.

Post by Moggy »

Hi Alan.

Just a few thoughts regarding FIF81 and the editor.

Firstly this is a no-knowledge end user observation not a criticism, complaint of any kind or demand for change, just a desire to understand why.

The editor in FIF is called to and or part of the main program unlike TF79 which has the editor as a separate standalone program. IE load editor do what ever save screens load TF79 load said screens. Does FIF's method of combing editor and vocab' leave less memory for program use?

Also I find the editor screens a bit fragile in use on real kit insofar as I can type a screen full of whatever words for loading and compilation that are perfect in Forth grammar, correctly spaced no faults etc which will happily respond to SAVE-BUFFERS but when it comes to loading said screen the ? gets thrown up with no clue about what's wrong even though (please trust me on this) the grammar and spacing is correct and not reliant on a previous screens loading that contains words needed in this new screen.

Sometimes after the saving, the screen shows corruption on certain lines when listed. When this is corrected and saved, upon resetting FIF and loading the screen if I do manage to get the ok all I get for any action performed is the ok prompt with no output from any operations in the vocabulary.

The end result is I have at least three screens I cannot load without a lockup and the ones I do need/value I have had to type again in other screens.
Even if I erase the contents of those faulty screens and start again the same thing happens, almost as if there is an HIDDEN corruption in the screen space itself. To my simple mind it's almost as if loading the editor on top of the main program plus doing whatever with the screens is causing the zeddy to do too much memory shuffling and things are corrupting as a result.

When I retype these words exactly as before into another screen then no problem. (anal enough to take screen pics for comparison)
It's almost as if once corrupted then these screens are now unusable even if re-edited.

Either way all my sessions are becoming frustratingly time consuming with more time spent on retyping screens hoping they will load and run rather than much practical work.

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

Re: FIF. Another FORTH.

Post by mrtinb »

Maybe if it's always page $15, that is giving the error, you can post SCR15.F, and Alan can see what gets corrupted?
Martin
https://zx.rtin.be
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
roganjosh
Posts: 100
Joined: Thu Jun 14, 2018 12:59 pm

Re: FIF. Another FORTH.

Post by roganjosh »

Hi Moggy,

> Does FIF's method of combing editor and vocab' leave less memory for program use?

Only as long as the editor is loaded. You can restart without the editor and load in your saved screens without the editor there. loading is independent of the editor.

My intention at some stage was to write a standalone editor but I did want to have FIF supporting a traditional line editor by default.

As for the corruption. It sounds like there's a bug either in the editor or with the ZXpand. Do you get the same problem using the editor in EO?

Martin's suggestion is what I was also going to suggest. It would help me to see one of the screens you can't load (remembering that they have hexadecimal numbering in the filenames). I'll PM you.

Alan
Post Reply