6502.org Forum Projects Code Documents Tools Forum
It is currently Mon May 06, 2024 4:47 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Forth

All times are UTC




Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next
  Previous topic | Next topic 
Author Message
asmlang_6
 Post subject: Gforth on 6502
PostPosted: Thu Jul 21, 2005 5:49 pm 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
I managed to hack Gforth 0.6.2 to generate a .fi file for a 6502 kernel.
Can anyone figure out how to make that run on the 6502?

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
kc5tja
 Post subject: Re: Gforth on 6502
PostPosted: Fri Jul 22, 2005 2:55 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
asmlang_6 wrote:
I managed to hack Gforth 0.6.2 to generate a .fi file for a 6502 kernel.
Can anyone figure out how to make that run on the 6502?


And it actually FIT? I'm impressed. I suspect it would be a matter of just loading it into memory, taking care of whatever relocations it provides, and then proceeding to execute it. Is the .fi format not documented in the gforth info files?
Top
 Profile  
Reply with quote  
asmlang_6
 Post subject: Re: Gforth on 6502
PostPosted: Fri Jul 22, 2005 10:46 pm 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
kc5tja wrote:
Is the .fi format not documented in the gforth info files?


Not in the info files, but if you look in the file engine/main.c, in a comment in the image loading routine you will find terse (IMO) documentation of the format. I couldn't figure it out.
Oh, and what do you mean by "FIT"?

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
kc5tja
 Post subject: Re: Gforth on 6502
PostPosted: Sun Jul 24, 2005 6:14 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
asmlang_6 wrote:
kc5tja wrote:
Is the .fi format not documented in the gforth info files?


Not in the info files, but if you look in the file engine/main.c, in a comment in the image loading routine you will find terse (IMO) documentation of the format. I couldn't figure it out.
Oh, and what do you mean by "FIT"?


Well, the .fi files on my box are about 128K to 256K in size. That's larger than the 6502's address space, let alone having enough room for the user dictionary.
Top
 Profile  
Reply with quote  
asmlang_6
 Post subject:
PostPosted: Sun Jul 24, 2005 7:54 am 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
It was 20K. Oh, and I think this isn't a normal .fi file. It's a flat-binary 6502 file.

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
kc5tja
 Post subject:
PostPosted: Mon Jul 25, 2005 5:44 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
asmlang_6 wrote:
It was 20K. Oh, and I think this isn't a normal .fi file. It's a flat-binary 6502 file.


Gotcha. I'll have to check it out! I wonder how easy it would be to make it run in a 65816 environment.
Top
 Profile  
Reply with quote  
asmlang_6
 Post subject:
PostPosted: Tue Jul 26, 2005 1:42 am 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
kc5tja wrote:
Gotcha. I'll have to check it out!


It won't work on Gforth out of the box. I had to modify it to generate the kernel. Here's a patch generated with GNU diff (diff -Naur gforth-0.6.2 gforth-0.6.2.~1~):

Code:
diff -Naur gforth-0.6.2/arch/6502/prim.fs gforth-0.6.2.~1~/arch/6502/prim.fs
--- gforth-0.6.2/arch/6502/prim.fs      2005-07-25 15:25:59.000000000 -1000
+++ gforth-0.6.2.~1~/arch/6502/prim.fs  2005-07-25 15:34:10.000000000 -1000
@@ -1062,6 +1062,23 @@
 5 $:   >IN             STY,
                        Next,
 end-code
+
+\ 16jun05sl  make this resolved
+code (bye) ( -- )
+1 $:                   NOP,
+       1 #.            LDA,
+       1 #.            CMP,
+       1 $             BEQ,    \ loop back to 1 $
+                       Next,   \ not reached
+end-code
+
+: sgn ( n -- -1/0/1 )
+ dup 0= IF EXIT THEN  0< 2* 1+ ;
+
+: -text ( c_addr1 u c_addr2 -- n )
+ swap bounds
+ ?DO  dup c@ I c@ = WHILE  1+  LOOP  drop 0
+ ELSE  c@ I c@ - unloop  THEN  sgn ;
 
 \ load high level primitives
 UNDEF-WORDS    include kernel/prim.fs  ALL-WORDS
diff -Naur gforth-0.6.2/cross.fs gforth-0.6.2.~1~/cross.fs
--- gforth-0.6.2/cross.fs       2005-07-25 15:27:44.000000000 -1000
+++ gforth-0.6.2.~1~/cross.fs   2005-07-25 15:34:01.000000000 -1000
@@ -1956,9 +1956,9 @@
    \ definition with the same name
    over undefined? 0= IF  exists EXIT THEN
    (resolve)
-   IF cr ." No forward references allowed on: " .ghost cr
-      -1 ABORT" Illegal forward reference"
-   THEN
+\   IF cr ." No forward references allowed on: " .ghost cr
+\      -1 ABORT" Illegal forward reference"
+\   THEN
    drop ;
 
 \ gexecute ghost,                                      01nov92py


Apply that patch to Gforth 0.6.2, type `make kernl-6502.fi', and you should have a 6502 kernel.

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
asmlang_6
 Post subject:
PostPosted: Sun Jul 31, 2005 12:47 am 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
I don't know if the `kernl-6502.fi' is a regular 6502 flat-binary file. The beginning of the file disassembles to:

BRK
BRK

But it isn't a Gforth image. Anybody know what it might be?

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
dclxvi
 Post subject:
PostPosted: Mon Aug 01, 2005 5:49 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
It is kind of ironic that GNU complains about things like the Word file format not being openly documented, and then their own file formats and other internals (elisp byte code comes to mind) are rather lightly documented. Anyway, if you have a utility that can deal with raw data files (the DOS utility DEBUG will do), you can look for the start of the object code that prim.fs generates, which along with the GForth source code, may be helpful when trying to decipher the header / relocation information. On the other hand, it might be easier to generate a hex/ASCII dump (e.g. with a perl script) and use a text editor.

I'm not sure how it handles relocating absolute addresses, but I would guess that zero page addresses are probably not relocated. So, the IP 1+ STA, 6C #. LDA, W 1- STA, just before LABEL "Next" should be (in hex) 85 11 A9 6C 85 12, since IP is EQU'd to $10 and W is EQU'd to $13 (I haven't used GForth in a long time, so I'm looking at Gforth 5.0 here). Or you could look for a sequence that doesn't depend on absolute or zero page addressing like E8 E8 E8 E8 (C! is one of the primitives that has four consecutive INX instructions).

Once you figure out where the primitives are, you can look at how it handles absolute addresses like the 1 $ JMP, in CMOVE. Then you can look at a couple of short colon definitions that were cross-compiled to see what those addresses look like. From all that you may be able to get some idea of the format of whatever header/relocation information there might be and what sort of relocation is needed.

I realize this is quite a bit of detective work, so good luck.
Top
 Profile  
Reply with quote  
kc5tja
 Post subject:
PostPosted: Mon Aug 01, 2005 3:29 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
As I understand it, the GForth for x86 platforms handle relocation by including *two copies* of the same binary image, which are loaded at "different" addresses. The idea is that constants will be the same in both images, but absolute addresses in each will differ. So by stepping through the image and comparing every byte, you can find offsets to relocate.

I am pretty confident that this only works well if you have a constant-sized offset field to relocate, and with both zero-page and absolute addresses needing relocation, I'm not sure how valid this technique would be.
Top
 Profile  
Reply with quote  
dclxvi
 Post subject:
PostPosted: Wed Aug 03, 2005 5:14 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
It actually relocates zero page references? Based on a quick look at prim.fs, things like the data stack, N, W, etc. are on the zero page. It doesn't seem unreasonable to have to make a new image if the zero page usage is changed. Okay, so it's not quite the same thing, but I would say it is somewhat analogous to (processor) register usage in that it's not necessarily something that a relocator would be expected to handle.
Top
 Profile  
Reply with quote  
asmlang_6
 Post subject:
PostPosted: Thu Aug 04, 2005 2:03 am 
Offline

Joined: Wed Jul 20, 2005 11:08 pm
Posts: 53
Location: Hawaii
dclxvi wrote:
It is kind of ironic that GNU complains about things like the Word file format not being openly documented, and then their own file formats and other internals (elisp byte code comes to mind) are rather lightly documented. Anyway, if you have a utility that can deal with raw data files (the DOS utility DEBUG will do), you can look for the start of the object code that prim.fs generates, which along with the GForth source code, may be helpful when trying to decipher the header / relocation information. On the other hand, it might be easier to generate a hex/ASCII dump (e.g. with a perl script) and use a text editor.


Only problem is that this isn't a Gforth image file. It dosen't have the Gforth magic number.

_________________
Sam

---
"OK, let's see, A0 on the 6502 goes to the ROM. Now where was that reset vector?"
Top
 Profile  
Reply with quote  
cas
 Post subject:
PostPosted: Fri Aug 05, 2005 6:17 pm 
Offline

Joined: Wed May 21, 2003 1:08 pm
Posts: 27
Location: Germany
Hi,

I've also played with GForth EC last night (without knowing about this thread) and managed to generate a 6502 Gforth (I have used an older GForth Version, "gforth-gdfreeze-ec").

It seems that you don't need to patch Gforth to get rid of the "forward reference" errors, you need to define the Constant "NIL" in mach.fs.

Here is the mach.fs I'm using. The kernel looks good in disassembly, it's 27 KB in size and is currently loading in my Replica 1 board (so I can tell in a few hours if it is working).

Code:
    2 Constant cell
    1 Constant cell<<
    4 Constant cell>bit
    8 Constant bits/char
    8 Constant float
    2 Constant /maxalign
false Constant bigendian
( true=big, false=little )

false Constant NIL

\ feature list

: prims-include  ." Include primitives" cr s" arch/6502/prim.fs" included ;
: asm-include    ." Include assembler" cr s" arch/6502/asm.fs" included ;
: >boot ;

>ENVIRON
false Constant file      \ controls the presence of the
            \ file access wordset
false Constant OS      \ flag to indicate a operating system

false Constant prims      \ true: primitives are c-code

false Constant floating      \ floating point wordset is present

false Constant glocals      \ gforth locals are present
            \ will be loaded
false Constant dcomps      \ double number comparisons

false Constant hash      \ hashing primitives are loaded/present

false Constant xconds      \ used together with glocals,
            \ special conditionals supporting gforths'
            \ local variables
false Constant header      \ save a header information

true SetValue ec
true SetValue crlf
\ true SetValue rom

cell 2 = [IF] 32 [ELSE] 256 [THEN] KB Constant kernel-size                                                                                                                   
                                                                                                                                                                             
16 KB           Constant stack-size                                                                                                                                           
15 KB 512 +     Constant fstack-size                                                                                                                                         
15 KB           Constant rstack-size                                                                                                                                         
14 KB 512 +     Constant lstack-size       


Regards

Carsten
Top
 Profile  
Reply with quote  
cas
 Post subject:
PostPosted: Fri Aug 05, 2005 7:42 pm 
Offline

Joined: Wed May 21, 2003 1:08 pm
Posts: 27
Location: Germany
If you want to set the startaddress and endaddress of the 6502 Kernel, put this inside "prim.fs"

Code:
unlock                                                                                                                                                                       
 $2000 $f000 region dictionary                                                                                                                                               
 setup-target                                                                                                                                                                 
lock         


before the start of the kernen "0 Constant BOT-"
Top
 Profile  
Reply with quote  
dclxvi
 Post subject:
PostPosted: Fri Aug 05, 2005 7:43 pm 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
By the way, for anyone using an NMOS 6502, I noticed a few LDA (zp) instructions in prim.fs, and although it does use aligned addresses, you might want to double check that the JMP (abs) bug won't occur.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next

Board index » 6502.org Users Forum » Forth

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests

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:  
6502.org is an ongoing project by Mike Naberezny and contributors.