View unanswered posts | View active topics It is currently Tue Mar 19, 2024 3:37 am



Reply to topic  [ 57 posts ]  Go to page 1, 2, 3, 4  Next
 FIgForth RTF6809 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I started porting FigForth to the RTF6809. I plan on making use of 32 bit addressing and data values. Some of the code should be easy to port and other portions much more difficult.
Easy:
Code:
;
;                                       EXCECUTE
;                                       SCREEN 14 LINE 11
;
L75       .BYTE $87,'EXECUT',$C5
          .WORD L35      ; link to CLIT
EXEC      .WORD *+2
          LDD   0,X
          STD   W
          LDD   2,X
          STD   W+2
          LEAX   4,X
          JMP   FAR [W]    ; to JMP (W) in z-page


More difficult to do is setting the address of Forth words because of the way that the NEXT routine will work. NEXT is discussed here: http://forum.6502.org/viewtopic.php?f=9&t=3100#p40725

_________________
Robert Finch http://www.finitron.ca


Wed Oct 07, 2015 2:44 pm
Profile WWW

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
Hey, Rob. Is there a good reason for avoiding the auto-increment address mode here, namely ,x++ ? It might not be any faster, but it would be shorter by getting rid of that leax ...

Mike B.


Wed Oct 07, 2015 3:15 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Hey, Rob. Is there a good reason for avoiding the auto-increment address mode here, namely ,x++ ? It might not be any faster, but it would be shorter by getting rid of that leax ...

Nope, there isn't a reason not to. And shorter is probably faster too on the RTF6809.
Souped up code:
Code:
;
;                                       EXCECUTE
;                                       SCREEN 14 LINE 11
;
L75       .BYTE $87,'EXECUT',$C5
          .WORD L35      ; link to CLIT
EXEC      .WORD *+2
          LDD   ,X++
          STD   W
          LDD   ,X++
          STD   W+2
          JMP   FAR [W]    ; to JMP (W) in z-page


The RTF6809 and 65c816 are actually very similar processors. The 6809 has 16 bit A,X,Y regs like the 65816, and the RTF6809 adds post indexed addressing. It's also very similar to the 65org16.

_________________
Robert Finch http://www.finitron.ca


Wed Oct 07, 2015 8:46 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
From your EXECUTE code I see you've gone 32-bit all the way. IMO 16-bit tokens (and 32-bit data) would've been adequate but there are reasons for sticking with 32 all the way.

FIG Forth has this weird -- I'm tempted to be blunt and just say dumb -- policy of using relative addressing for branches. So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency.

Maybe I shouldn't've mentioned it. Your machine is gonna be so fast that the needless extra work hardly matters.

-- Jeff

_________________
http://LaughtonElectronics.com


Wed Oct 07, 2015 9:22 pm
Profile WWW

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
Dr Jefyll wrote:
... So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency ...

... unless you happen to have a hypothetical situation in which IP is in Y, and have access to a hypothetical machine instruction like ADY ,Y+ which takes the same time and space as LDY ,Y ... but that's pure fantasy at this moment in time ... I just like speaking hypothetical!

Mike B.


Thu Oct 08, 2015 3:30 am
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Fair enough, but breaking even is the best you can do. The effort/clock count to load and add the inline parameter to IP can't be less than that to simply load the inline parameter to IP.

Hypothetically, of course! ;)

_________________
http://LaughtonElectronics.com


Thu Oct 08, 2015 3:57 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
From your EXECUTE code I see you've gone 32-bit all the way. IMO 16-bit tokens (and 32-bit data) would've been adequate but there are reasons for sticking with 32 all the way.
Yes, I'm probably going 32 bits all the way. I wanted to be able to position code anywhere in memory which really requires 32 bit links and also be able to break the 64k limit code size. There's not much hope for using 16 bit tokens without changing the basic dictionary mechanism. It could be re-worked to operate more like a BASIC interpreter. But that might make it more difficult to add keywords. The problem with Forth is that the token are mapped directly to addresses. Could have a hardware lookup table to translate tokens in addresses. I was thinking of this as a hardware component (using tokens rather than addresses) in jumps and call instructions in order to shorten instructions.
Quote:
FIG Forth has this weird -- I'm tempted to be blunt and just say dumb -- policy of using relative addressing for branches. So if 0BRANCH for instance meets its condition and needs to branch then its inline parameter is added to IP rather than replacing IP. It's a lose-lose situation, IMO -- all cost, no benefit. If you felt like optimizing, you could tweak FIG to avoid this inefficiency.
I found that bit of code and was wondering why they did that. IF it doesn't matter at a high level, I'll be sure to change it. I'm not that fond of relative branchs, I prefer offsets from a code base. Relative addressing was invented as a code compaction mechanism.

When I started I was going to do a more or less direct port of fig forth, but now that I've looked at it far a bit I'm changing it around somewhat.
Fig uses the .X register for the data stack, I changed to using the .U register on the 6809. I then use .X as the low order word of a 32 bit accumulator (D,X).

_________________
Robert Finch http://www.finitron.ca


Thu Oct 08, 2015 7:16 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Quote:
I found that bit of code and was wondering why they did that. IF it doesn't matter at a high level, I'll be sure to change it.
It does have implications regarding the compiler. Words such as UNTIL IF ELSE are what put that inline parameter into the compiled code, so they'd need a modification to make the parameter absolute rather than relative. Might be best to leave that alteration for later.

BTW FIG has @ and ! for the native word size (16 bits) and also C@ and C! for byte operations. The native size on your "stretch" FIG will be a DWord (32 bits), so you may wanna create W@ and W! ("word fetch" & "word store") to allow 16-bit operations.

Quote:
I wanted to be able to position code anywhere in memory which really requires 32 bit links and also be able to break the 64k limit code size.
Going 32 bits all the way is a good way to shake down the FAR extensions you've made to 6809 addressing. Plus you'll get more familiar with Forth (particularly FIG Forth) while you're at it.

Quote:
There's not much hope for using 16 bit tokens without changing the basic dictionary mechanism
Depends which basic mechanisms you mean. On 6502.org I mentioned the hybrid 16-/32-bit Forth I did for Real Mode x86. There were numerous changes to the compiler, mostly to be sure I use W@ and W! when dealing with tokens! And of course all the primitives (AND OR XOR + - 0= and the rest) had to be rewritten to get 32-bit precision. But the tokens themselves and the inner interpreter -- the nuts & bolts of threading and execution -- are stock, 16-bit x86 Forth. (ITC, same as FIG.)

Quote:
Fig uses the .X register for the data stack, I changed to using the .U register on the 6809. I then use .X as the low order word of a 32 bit accumulator (D,X).
IIRC, operations on X and Y update the flags in a different manner than operations on U and S. Just a reminder to keep that in mind. Dunno if it'll affect what you're doing.

-- Jeff

_________________
http://LaughtonElectronics.com


Thu Oct 08, 2015 1:56 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Today I am not understanding how Fig Forth bootstraps. It looks to me like the ORIG area must be setup prior to running FIG Forth. IS there a template for this somewhere ?
Is there documentation on the structure of the ORIG and USER pointer areas ?

Code:
L2423     .BYTE $84,'COL',$C4
          .WORD L2406    ; link to ABORT
COLD      .WORD *+2
          LDA ORIG+$0C   ; from cold start area
          STA FORTH+6
          LDA ORIG+$0D
          STA FORTH+7
          LDY #$15
          BNE L2433
WARM      LDY #$0F
L2433     LDA ORIG+$10
          STA UP
          LDA ORIG+$11
          STA UP+1
L2437     LDA ORIG+$0C,Y
          STA (UP),Y
          DEY
          BPL  L2437
          LDA #>ABORT    ; actually #>(ABORT+2)
          STA IP+1
          LDA #<ABORT+2
          STA IP
          CLD
          LDA #$6C
          STA W-1
          JMP RPSTO+2    ; And off we go !

_________________
Robert Finch http://www.finitron.ca


Sun Oct 11, 2015 6:55 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Do you have the FIG "Installation Manual and Glossary"? It pertains to the FIG model in general (isn't CPU-specific). You can download it, or borrow my (pencil-annotated) printed copy if you like.

_________________
http://LaughtonElectronics.com


Sun Oct 11, 2015 7:04 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Do you have the FIG "Installation Manual and Glossary"?

I found one on the web but it's not very extensive. I think I need information more specific to the 6502 Fig Forth.
But, I have to get the 6809 system working before I can test any code. Unless I write an emulator.

Currently the system just clears the screen and then hangs.

I'm running the 6809 core at 66MHz! (Could be why it hangs).

_________________
Robert Finch http://www.finitron.ca


Sun Oct 11, 2015 7:51 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Try running it slower, then! Or patch in the TRACE routines so you can see what's going on. (I assume these routines exist in the 6809 version as they do in 6502.) IIRC there's a trace that can be patched into NEXT, and another for DOCOL.

Sounds like you found a machine-readable copy of the 6809 assembly source for FIG. Can you send me that, pls, or a link?

Thinking of non-machine-readable source code reminds me of my first Forth -- FIG for 6502, running on my KIM-1 circa 1980. I manually entered about 8KB of hex (!) so obviously there were some typos. The debugging was... interesting (I knew almost nothing about Forth).

_________________
http://LaughtonElectronics.com


Sun Oct 11, 2015 8:21 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Sounds like you found a machine-readable copy of the 6809 assembly source for FIG. Can you send me that, pls, or a link?

Oops, I sidetracked on the topic a little bit. The clearscreen routines is a separate part of simple monitor routines I was trying to boot; not a part of the forth system.
I didn't manage to find a machine-readable copy, I've only found an optically scanned copy of the fig forth fro the 6809. I decided not to use that and instead am
just porting the 6502 version since I've got a lot of changes to convert to a 32 bit forth. I've got to change the forth memory map for the rtf6809 since bank zero space is valuable like zero page memory is on the 6502. It's the only place there can be indirect pointers, and also the stacks must be located in bank 0, just like the 65c816.

Quote:
Thinking of non-machine-readable source code reminds me of my first Forth -- FIG for 6502, running on my KIM-1 circa 1980. I manually entered about 8KB of hex (!) so obviously there were some typos. The debugging was... interesting (I knew almost nothing about Forth).

I hope you had a way to save your work part way through. Yes, there's lot of debugging to do. I'm hoping to learn some Forth that way.

_________________
Robert Finch http://www.finitron.ca


Mon Oct 12, 2015 12:38 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Quote:
am just porting the 6502 version since I've got a lot of changes to convert to a 32 bit forth
Maybe a bit roundabout, but if that's the way you wanna do it then alright. FWIW, I expect it's possible to find a machine-readable version of the FIG 6809 source. It's probably on the net somewhere; I just never tried doing a proper search. Might be useful to you as a reference to have some known-good 6809 code, albeit 16-bit.

Quote:
I hope you had a way to save your work part way through
Yes -- audio cassette tape! At the time, tape was my only mass storage (although later I built a floppy-disk subsystem). All of this predated my first DOS machine. There was no ubiquitous PC host that could just squirt out whatever you need on demand.

I don't miss cassette-tape storage! Getting that floppy working was a liberating experience.

_________________
http://LaughtonElectronics.com


Mon Oct 12, 2015 3:15 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I figured out why the SoC hangs, I ported the code for a Spartan6 version to Artix7, but left out the DDR ram controller. I didn't think it was in use, but it was. Thus a hang when the cpu tried to access an unsupported memory address. It'll take some work to fix. Either re-writing the BIOS or incorporating a DDR controller.

Quote:
Might be useful to you as a reference to have some known-good 6809 code, albeit 16-bit.
Last time I left the system I was trying to get the Flex9 OS working on it. So I do have some good 16-bit 6809 code available. One problem is the RTF6809 always stores a 32 bit program counter address during an interrupt. IIRC, I believe this may have created a problem for some OS code which does a PULS PC to return from interrupt rather than an RTI. The PULS PC only pulls a 16 bit value from the stack (working like the 6809). However if prefixed with the FAR keyword it'll then pull a 32 bit value.

Quote:
Yes -- audio cassette tape! At the time, tape was my only mass storage (although later I built a floppy-disk subsystem). All of this predated my first DOS machine. There was no ubiquitous PC host that could just squirt out whatever you need on demand.
The good ole days. I spent a couple of years myself using a VIC-20 with "dataset" (basically tape recorder). I kept all the audio cassettes up until a couple of years ago although I hadn't used them for years. I wonder what it would take to get an modern audio recorder interfaced to the system. It might be simpler than trying to interface an SD-Card controller.

_________________
Robert Finch http://www.finitron.ca


Mon Oct 12, 2015 3:50 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 57 posts ]  Go to page 1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software