On Friday, 5 May 2017 at 03:58:44 UTC+1, HAA wrote:
David Schultz wrote:
On 05/02/2017 07:43 PM, HAA wrote:
There's no bug. When referencing a disk block, BLK is 16 bits.
However as BLK and IN represent 3 contiguous bytes, a mix of
C@ C! ! @ were needed to save/restore/zero both BLK and IN.
How does that work?
If BLK is zero then input is from the terminal. This implies that the
high byte of IN is also zero. Which would be fine.
But if BLK is non-zero then IN cannot be used as is to index into the block. Something else must be done. It could be as simple as "IN 1+ C@"
but that means that the code to interpret a disk block is different from the code to interpret a line from the terminal.
QUIT suggests TIB is 80 chars in which case BLK= 16 bits, IN= 8 bits
would work without fuss. There must however be an 'other' reason IN
was defined as a 16 bit entry (Appendix A Tech Manual).
Kind of making that saving one byte of user variable storage moot.
microFORTH is like SwiftX in that target apps will likely never use
BLK IN WORD BLOCK etc (the code for these don't reside in the
nucleus). You then have an incentive to keep user area to a
minimum e.g. BASE is 1 byte.
Of course if ALL of the code were present we could see how it is done.
That or a disk dump. Addresses for the nucleus routines 00-01FF are
given in screens 51/52. Headers, interpreter and other code will be
residing elsewhere.
Now, 6 years later,
I just wonder if there is anybody here who has recently used microFORTH.
So all of the parts are there.
There seem to be conflicting views if the data on the Forth INC. website is complete or not.
The interest here is general, not for project work.
I was able to save some of the old Forth material over the last 10 years
and it is now available on amazon.
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM%3Fref=dbs_a_mng_rwt_scns_share
But this bit is missing unfortunately as part of this collection.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)