SuperForth 64 [message #204371] |
Tue, 02 March 2010 15:59 |
christianlott1
Messages: 1852 Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Heard a little about this but can't find a link to the program
anywhere.
Anyone have this?
Thanks
|
|
|
Re: SuperForth 64 [message #204373 is a reply to message #204371] |
Tue, 02 March 2010 17:03 |
|
Originally posted by: BruceMcF
On Mar 2, 3:59 pm, christianlott1 <christianlo...@yahoo.com> wrote:
> Heard a little about this but can't find a link to the program
> anywhere.
>
> Anyone have this?
>
> Thanks
Don't have it, its a Forth-79 in a cartridge. Centsible Software used
to have it, looking at their site it looks like they've gone under
five or more years back, missing links and last (c) in their site is
2003.
Several fig-Forth and Forth-79 soft versions are available, though
they often use REL files to store blocks, which can be tricky in
emulators.
I think that VolksForth was updated to the Forth-94 standard (the
formal language standard that went through ANS and ISO ... the
previous "standards" were more informal efforts).
If you are looking for an image of a cartridge based Forth, google for
64Forth, which was a fig-Forth by Tom Zimmer, who was probably the
most prolific implementer of 6502 based fig-Forth's for late 70's,
early 80's home computer systems.
Of course, fig-Forth is dead slow on the 6502 because its indirect
threaded, and direct threaded is much faster, while subroutine
threaded is faster again. SO the fastest C64 Forth was the subroutine
threaded Blazin' Forth.
|
|
|
|
|
|
|
|
|
Re: SuperForth 64 [message #204395 is a reply to message #204392] |
Wed, 03 March 2010 10:47 |
|
Originally posted by: BruceMcF
On Mar 3, 9:00 am, christianlott1 <christianlo...@yahoo.com> wrote:
> hforthx.cpm would not download as it has 0 bytes.
Good thing, too, it was buggy.
Thx, have to remember to erase that file (extending hForth for CP/M
went into the backburner ... when I get back into it, I'll probably
use Camel for CP/M instead, and give it BLOCK files ... I need more
experience with programming CP/M files in their own style before
implementing the Forth-94 FILE wordset).
|
|
|
Re: SuperForth 64 [message #204396 is a reply to message #204373] |
Wed, 03 March 2010 10:58 |
|
Originally posted by: BruceMcF
On Mar 2, 5:03 pm, BruceMcF <agil...@netscape.net> wrote:
> SO the fastest C64 Forth was the subroutine
> threaded Blazin' Forth.
Blazin' Forth is also at taygeta, thanks for the ftp address.
Only problem with a subroutine threaded forth is it compiled bigger
programs. If compact execution is wanted, a bit threaded interpreter
may be a good combination of speed and code size.
It would be built with primitives that end with "JMP NEXT", and "IP"
and "W" as two zero-page vectors (if Basic vectors are reset to run
Basic in a Box at $8000 and the Forth in $0800 to $7FFF, that would be
W=$FB and IP=$FD).
NEXT:
CLC
LDA IP
ADC #2
STA IP
BCC NEXT1
INC IP+1
NEXT1:
LDY #1
LDA (IP),Y
BEQ EXIT
BMI ENTER
STA W+1
DEY
LDA (IP),Y
STA W
JMP (W)
ENTER:
AND #$7F
STA W+1
DEY
LDA (IP),Y
|
|
|
Re: SuperForth 64 [message #204397 is a reply to message #204396] |
Wed, 03 March 2010 11:08 |
|
Originally posted by: BruceMcF
Oops, hit the wrong key
On Mar 3, 10:58 am, BruceMcF <agil...@netscape.net> wrote:
NEXT:
CLC
LDA IP
ADC #2
STA IP
BCC START
INC IP+1
START:
LDY #1
LDA (IP),Y
BEQ EXIT
BMI ENTER
STA W+1
DEY
LDA (IP),Y
STA W
JMP (W)
ENTER:
AND #$7F
STA W+1
DEY
LDA (IP),Y
TAY
LDA IP+1
PHA
PDA IP
PHA
STY IP
LDA W+1
STA IP+1
JMP START
EXIT:
CLC
PLA
ADC #2
STA IP
PLA
ADC #0
STA IP+1
JMP START
As a first start, the data stack can be X-indexed on the stack page,
starting at the top of the area the C64 uses and building up. 128
bytes is plenty for data stack and 64 bytes is plenty for return
stack, so the stack page has ample space for a single-tasking Forth.
If upgrading to a pre-emptive multi-tasking Forth, you'd switch the
data stack to two pages elsewhere in RAM, high bytes in one, low bytes
in the other. That gives four independent 128 byte data stacks just by
switching X in the task switch. A page for USER variables and
independent PAD, and you have one background task available for a
scheduler, and two background tasks available for interupt-driven I/
O.
|
|
|
Re: SuperForth 64 [message #204400 is a reply to message #204397] |
Wed, 03 March 2010 17:13 |
|
Originally posted by: BruceMcF
On Mar 3, 11:08 am, BruceMcF <agil...@netscape.net> wrote:
I just noticed that it can be made relocatable (though of course the
dictionary would not be without the "compile it again at a different
location and find the words that are offset" trick):
NEXT:
CLC
LDA IP
ADC #2
STA IP
BCC START
INC IP+1
START:
LDY #1
LDA (IP),Y
BEQ EXIT
BMI ENTER
STA W+1
DEY
LDA (IP),Y
STA W
JMP (W)
ENTER:
AND #$7F
STA W+1
DEY
LDA (IP),Y
TAY
LDA IP+1
PHA
PDA IP
PHA
STY IP
LDA W+1
STA IP+1
BPL START
BRK
EXIT:
CLC
PLA
ADC #2
STA IP
PLA
ADC #0
STA IP+1
BPL START
BRK
.... since if the top bit is not clear, in this implementation its
outside of the Forth dictionary and up in the memory for running
BASIC, I/O, the Kernal, the memory heap, the Block buffer, etc (RAM
under Kernal for graphics, RAM under BASIC rom for ALLOCATE, and
remember when launching into BASIC that nothing in ALLOCATED memory
can be passed..
|
|
|
|
|
Re: SuperForth 64 [message #204468 is a reply to message #204465] |
Sat, 06 March 2010 17:17 |
|
Originally posted by: BruceMcF
On Mar 6, 2:53 pm, christianlott1 <christianlo...@yahoo.com> wrote:
> the third is a new string-based model intended for use in a multiple-
> processor implementation of Scheme."
A string based model! But don't all the 11-dimensional arrays chew up
boatloads of RAM?
http://en.wikipedia.org/wiki/String_theory
IOW, I know what heap based and stack based mean (a language does not
have to be a variant of Forth to benefit from having data stack and
return address stack separated ... indeed, one approach to getting C
to run more rapidly is to have return addresses on the return stack,
and and heap data either contained or pointed to in a dedicated X-
indexed page in memory, with the ZP treated like a very large register
bank) ... but string based mode, no idear.
|
|
|
|
Re: SuperForth 64 [message #363960 is a reply to message #204371] |
Wed, 21 February 2018 12:07 |
|
Originally posted by: jwt0bos
On Tuesday, March 2, 2010 at 3:59:15 PM UTC-5, s1 wrote:
> Heard a little about this but can't find a link to the program
> anywhere.
>
> Anyone have this?
>
> Thanks
I still have my binder and original disks - I wanted to make a game. Still might do it.
|
|
|
|