View unanswered posts | View active topics It is currently Thu Mar 28, 2024 6:31 pm



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

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
robfinch wrote:
... 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 ...

Well, this isn't fig-FORTH, but it appears to be a kissing cousin:

https://github.com/6809/sbc09/blob/mast ... s/ef09.asm

Maybe you can use it as a starting point for your modifications. There's a small thread about it here, with further links and info:

http://www.44342.com/forth-f381-t1827-p1.htm

It appears to be DTC, with S as PSP, Y as RSP, and U as IP ... might take a bit of time to get used to it, but it looks like a tidy and comprehensive bit of source.

Mike B.


Mon Oct 12, 2015 3:56 am
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
Dr Jefyll wrote:
FWIW, I expect it's possible to find a machine-readable version of the FIG 6809 source.

http://www.forth.org/fig-forth/fig-forth_6809.pdf (linked at http://www.forth.org/fig-forth/contents.html . The FIG website is at http://www.forth.org/ .)

Quote:
Yes -- audio cassette tape! At the time, tape was my only mass storage [...] I don't miss cassette-tape storage! Getting that floppy working was a liberating experience.

Cassette was suitable for the time because everyone had cassette machines, and even a cheap one worked fine. Cassettes themselves were cheap too (although the cost per KB or MB would be astronomical by today's standards). I seem to remember early floppy-disc drives costing many hundreds of dollars, back when a dollar was a lot bigger than it is now. A technician I hired in 1985 or '86 asked me if I thought we could get the owner of the tiny company to spring for a hard disc for the only PC in the company. I laughed at him. The other computer in the company was an Apple II, with floppy-disc drives.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Mon Oct 12, 2015 4:18 am
Profile WWW

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
Garth wrote:
Dr Jefyll wrote:
FWIW, I expect it's possible to find a machine-readable version of the FIG 6809 source.

http://www.forth.org/fig-forth/fig-forth_6809.pdf (linked at http://www.forth.org/fig-forth/contents.html . The FIG website is at http://www.forth.org/ .)

The OCR on that .pdf is absolutely horrible, Garth. Ask me how I know ;)

Mike B.


Mon Oct 12, 2015 4:23 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
I put the pdf through OCR again at the Internet Archive - I think it came out better, but nothing close to perfect. See attached.


Attachments:
fig-forth_6809-reOCR.pdf [5.89 MiB]
Downloaded 423 times
Mon Oct 12, 2015 12:26 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I've got about 2/3 of FigForth 6502 converted for the RTF6809. It should be about 8kB when finished, with all the 32 bit words. It's a PITA to convert the 16 bit relative branches to 32 bit relative values by hand. I'm placing the Forth in a ROM at $2xxxx. Yes, that's at a 128kB boundary.

I managed to fix my test system so that it gets me to the bios prompt '$' now. I had screwed up the address decoding for the RAM. It was one bit position different between the hardware and software.

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


Thu Oct 15, 2015 3:18 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Finally finished off the first try at conversion. There's bound to be errors. As always, the source can be seen in my Github account. Modified the 6809 boot rom to run forth by typing 'FIG' at the boot rom prompt.
Now to test it.

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


Sat Oct 17, 2015 9:13 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
32-bit FIG Forth will be cool! :) And you're running at 66 MHz?

_________________
http://LaughtonElectronics.com


Sat Oct 17, 2015 3:45 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Well, the first FIG test failed - the system hung. The startup prompt wasn't even displayed.
Quote:
32-bit FIG Forth will be cool! :) And you're running at 66 MHz?

It will be nice if I can get it to work. The bitmap display will require 32 bit addressing, I'd like to get some sort of Forth demo running.

For now, I've reduced the clock rate to 25MHz to see if it helps reliability. There are some timing constraints with the DDR2 ram that I haven't got to work yet. Slowing the clock down doesn't seem to make a difference. Access to the DDR ram incurs wait states, as does access to some I/O peripherals. However access to the ROMs is full speed and the processor has an instruction cache.

Code in the boot rom to dump the register set doesn't work. It displays the headings then hangs. Which is strange because the codes pretty plain vanilla.
Code:
                      DumpRegs
 0000F86C 8EF844                  ldx             #msgRegHeadings
 0000F86F CC0000                  ldd             #msgRegHeadings>>16
 0000F872 BDF7CD                  jsr             DisplayStringDX
 0000F875 12                      nop
 0000F876 12                      nop
 0000F877 CF0000D0AF              jsr             XBLANK
 0000F87C FC0900                  ldd             mon_DSAVE
 0000F87F CF0000D2D2              jsr             HEX4
 0000F884 CF0000D0AF              jsr             XBLANK
 0000F889 FC0902                  ldd             mon_XSAVE
 0000F88C CF0000D2D2              jsr             HEX4
 0000F891 CF0000D0AF              jsr             XBLANK
 0000F896 FC0904                  ldd             mon_YSAVE
 0000F899 CF0000D2D2              jsr             HEX4
 0000F89E CF0000D0AF              jsr             XBLANK
 0000F8A3 FC0906                  ldd             mon_USAVE
 0000F8A6 CF0000D2D2              jsr             HEX4
 0000F8AB CF0000D0AF              jsr             XBLANK
 0000F8B0 FC0908                  ldd             mon_SSAVE
 0000F8B3 CF0000D2D2              jsr             HEX4
 0000F8B8 CF0000D0AF              jsr             XBLANK
 0000F8BD FC090A                  ldd             mon_PCSAVE
 0000F8C0 CF0000D2D2              jsr             HEX4
 0000F8C5 FC090C                  ldd             mon_PCSAVE+2
 0000F8C8 CF0000D2D2              jsr             HEX4
 0000F8CD CF0000D0AF              jsr             XBLANK
 0000F8D2 FC090E                  ldd             mon_DPRSAVE
 0000F8D5 CF0000D2CE              jsr             HEX2
 0000F8DA CF0000D0AF              jsr             XBLANK
 0000F8DF B6090F                  lda             mon_CCRSAVE
 0000F8E2 CF0000D2CE              jsr             HEX2
 0000F8E7 CF0000D0AF              jsr             XBLANK
 0000F8EC 7EF66B                  jmp             Monitor
 

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


Sun Oct 18, 2015 1:27 am
Profile WWW

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
Your assembler is able to produce two different op-codes for JSR, presumably for 16-bit and 32-bit versions, right? How does it know which one to assemble, especially if you're JSRing to code within the current bank?

Is it possible that you're accidentally mixing and matching 16-bit and 32-bit RTSes, fouling up your return stack? Does DisplayStringDX return with a 16-bit or a 32-bit RTS?

Mike B.


Sun Oct 18, 2015 6:39 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Your assembler is able to produce two different op-codes for JSR, presumably for 16-bit and 32-bit versions, right? How does it know which one to assemble, especially if you're JSRing to code within the current bank?

The label for the subroutine is tagged as far so that the assembler will know to use the far version of the JSR. Otherwise the near version is used. Another factor is the calculation of the effective address. When the address is calculated if the top 16 bits don't match the current location counter's top 16 bits then it must be a far address.
Here is a sample showing a label tagged as a far address.
Code:
; The ORG directive must set an address a multiple of 4 in order for the Verilog
; output to work correctly.

   org      $0000D0AC
   nop
   nop
   nop
far XBLANK       ; tagged as far
   lda      #' '
   jsr      OUTCH
   rtf
...
       jsr             XBLANK   ; assembler knows XBLANK is far


Quote:
Is it possible that you're accidentally mixing and matching 16-bit and 32-bit RTSes, fouling up your return stack? Does DisplayStringDX return with a 16-bit or a 32-bit RTS?
I thought that was most likely too. And spent some time going over how things could be messed up.

However, I believe I have now found the problem. Verilog output which is automatically generated by the assembler was messed up. The assembler outputs 32 bit Verilog, so it works on a multiple of four bytes. If there was an .org directive that orged into the middle of the group of four bytes then the output is screwed up. It was working okay all along, but then the other day I finally org'd something unevenly.

By carefully orging things at a multiple of four bytes, I was able to get the register dump code to work. I really should create a near link routine for all those far addresses so that near JSR's can be used to reduce the code size.

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


Sun Oct 18, 2015 7:45 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
After a couple of more bug fixes, forth gets into the bootstrap code then hangs. It appears the user area config is corrupt for one thing resulting in a bad SP. I wrote a little routine to dump the user area and it looks like random data. So it appears to be a problem with the DRAM. The next step is to write a DRAM test routine I guess.

Only one bug in the cpu core was found having to do with long branches. The target address calculation was off by one byte. I missed the fact that the PG2 opcode prefix associated with a long branch already incremented the pc by one before the long branch was processed.

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


Thu Oct 22, 2015 12:38 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I wrote a simple DRAM test routine, and it hung at approximately 64MB boundary. I ran the test multiple times with the same results. I'm thinking there's a timing problem at a bank boundary crossing. Now I'm going to try changing the timing of the cpu core with respect to the DRAM controller core. They are currently both running at different clock rates. I've run the DRAM core and a cpu core at different clock rates before without a problem. The bus interface uses an ACK / NACK sequence which should eliminate problems due to differing clocks.

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


Fri Oct 23, 2015 12:25 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
For some reason or other the DRAM is acting as if it's only 64MB; it supposed to be 128MB. So for now the system is organized around the 64MB size.
I've managed to get FIG Forth to do the TRACE routine. It now gets to the ABORT word and hangs at DR0 after tracing the DECIMAL word. It's almost there.

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


Fri Oct 23, 2015 10:03 pm
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Cool!

I guess you realize DR0 is installation dependent, as its job is to select Disk Drive zero. (In a drive-less system the disk accesses are replaced by moves to/from a memory area. Words such as DR0 and R/W are accordingly redefined.)

Quote:
It's almost there.
The first milestone will be getting the FIG startup greeting. Next is being able to enter keystrokes and have them echoed onscreen (and getting BackSpace to work).

The real fun stuff is when you're ready to enter a string and hit Return. Forth will have to find the word (if the string is a word) or convert the string to a number and place it on stack. Lots of scope for glitches in all of that!

_________________
http://LaughtonElectronics.com


Sat Oct 24, 2015 4:01 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
I guess you realize DR0 is installation dependent, as its job is to select Disk Drive zero. (In a drive-less system the disk accesses are replaced by moves to/from a memory area. Words such as DR0 and R/W are accordingly redefined.)
I managed to glean that by studying the source code. I'm leaving the disk I/O routines for later. Pending what I'm going to use for a disk.
Quote:
The first milestone will be getting the FIG startup greeting.

I guess there's probably a long ways to go yet. The program gets into the PDOTQ routine then it seems it doesn't return properly. The last thing that displays onscreen is the address of the terminal's input buffer 0x00000100.

The biggest thing I had to fix was to implement the double indirect jump at the end of the NEXT routine properly. Unfortunately the processor doesn't support indirect jumps via a far address. The indirect address can only be in bank zero. So I coded the thing by loading the indirect address manually, and storing it off in another variable called W2. Code for the next routine is shown below.
Code:
00020064 BD00CC          NEXT      JSR   TRACE
 00020067 15EC9F0038                        LDD   FAR [IP]
 0002006C DD3C                              STD   W
 0002006E 108E0002                          LDY   #2
 00020072 151BECB90038                      LDD   FAR [IP],Y
 00020078 DD3E                              STD   W+2
 0002007A DC3A                              LDD   IP+2            ; inline increment IP by 4
 0002007C C30004                            ADDD  #4
 0002007F DD3A                              STD   IP+2
 00020081 DC38                              LDD   IP
 00020083 C900                              ADCB  #0
 00020085 8900                              ADCA  #0
 00020087 DD38                              STD   IP
 00020089 108E0002                          LDY   #2
 0002008D 15EC9F003C                        LDD   FAR [W]         ; double indirect far jump is needed here
 00020092 151BAEB9003C                      LDX   FAR [W],Y
 00020098 DD40                              STD   W2
 0002009A 9F42                              STX   W2+2
 0002009C 156E9F0040                        JMP   FAR [W2]
 

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


Sun Oct 25, 2015 10:54 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 57 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 2 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:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software