Maybe someone is interested. I ported FigForth to Michal Kowalski's 6502 IDE and emulator (http://www.exifpro.com/utils.html).
Have fun!
--Dietmar

A bit of pendantry: Mike Kowalski's software is a simulator, not an emulator.

Also, the latest version is available here on 6502.org. Thanks to Daryl Rictor, it has a number of bug fixes.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ah, FIG Forth. A classic!

Welcome, Dietmar. Hope to hear more from you in future.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Indeed, welcome Dietmar!

Just bumping this because I thought it might get more interest. (It's possible that most of the Forth users here already have setups, perhaps running native on their 6502 machines. I'm not really a Forth user, only knowing enough to try
when I find myself at the command line.)

Hi All,

I am a big fan of and have Tali running on my sbc fine.

However, FIGFORTH has always interested me. I've brought a couple different venison's up on my SBC, worked through tutorials with it and so on, but could never get screen listings to work. I had always assumed it had something to do with my setup, but I see the same issue exist in the simulator, thus I must be missing something.

As in the screenshot, I would expect a 0 list to list 16 lines but it crashes at line 2. I know this crash is happening when in routine L3030 / DDISC and that I have no disc attached, but I have thought I could use a RAM disk as described in the 1979 installation manual.

The section of the installation manual "fig-FORTH_Manuals_May79" I refer to, page 4 reads as:

RAM DISC SIMULATION
If disc is not available, a simulation of
BLOCK and BUFFER may be made in RAM. The
following definitions setup high memory as
mass storage. Referenced 'screens' are then
brought to the 'disc buffer' area. This is
a good method to test the start-up program
even if disc may be available.
HEX
4000 CONSTANT LO ( START OF BUFFER AREA )
6800 CONSTANT HI ( 10 SCREEN EQUIVALENT )
: R/W >R ( save boolean )
B/BUF * LO + DUP
HI > 6 ?ERROR ( range check )
R> IF ( read ) SWAP ENDIF
B/BUF CMOVE ;
Insert the code field address of R/W into
BLOCK and BUFFER and proceed as if testing
disc. R/W simulates screens 0 thru 9 when
B/BUF is 128, n the memory area $4000 thru
$6BFF.

An online version of the manual is at https://github.com/BillRagsdale/fig-FORTH/blob/main/fig-FORTH_Installation_Manual_May79%20good.pdf

I have tried this several ways, but basically, I enter the above R/W definition and get an OK, then I do the following "which is probably wrong":

' BLOCK R/W !
' BUFFER R/W !

I will then try list and it will show a line or two and crash. I have also tried not doing anything but starting figforth and 0 list, as well as only defining hi and lo.

If anyone can give me a new idea I would appreciate it. I do know if I connected up my SD card routines it would likely work much better, but I wanted to get thru playing with a ram disk first to make sure I understood what to do with read sd card access.

I do have Tali working well with my sd card solution, but FIGFORTH seems a little less straight forward to setup for me.

Thanks,

Don

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

Don, this is maybe a long shot, but does LIST rely on U* ? I haven't the time to check right now. But perhaps you'll be glad to learn of the UM* (multiplication) bug in common 6502 Forths anyway.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The R/W routine is in page 69 of Ragsdales manual. You have to replace it with the RAM disc code above and then it will work fine.
Be aware, that in FIG FORTH screens 1 & 2 are reserved for the error messages.

Dietrich

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

This exact exercise - trying to get FIG Forth to use a ram disk - is exactly what made me give up on FIG and find Scot Stevenson's Tali Forth 2 (even though I ended up being the one to write all of the block words for it later). I never returned to FIG, but it's interesting to see someone else trying to make it work and running into the same problems. I will say, first of all, "it's not just you" and this is actually a difficult problem that is not well documented.

It's a little more complicated than the notes you quoted would have you believe. BLOCK and BUFFER both take a single argument (the block# from the disk that you want in RAM) and returns the address of a buffer, while R/W takes multiple arguments and returns nothing, so it doesn't make sense to replace the entire actions of BLOCK and BUFFER with R/W. Instead, you are supposed to patch the calls to R/W that are already inside of those words with your new word.

BLOCK actually reads from the disk into a buffer, you need R/W to do that. BUFFER, although it doesn't actually read in from the disk, may need to flush an existing buffer to disk to have a buffer to give you, so it needs R/W for doing that. When the instructions say to insert the address of R/W into BLOCK and BUFFER, I believe they mean to go into the middle of those words and replace it there (each word calls R/W once) - difficult to do without a listing and tricky even with a listing.

I think the easiest path forward is to replace the R/W in the assembly with the ramdisk version and reassemble - that will automatically "patch" both BLOCK and BUFFER in exactly the right places. You can use FORTH words in the assembly, but may have to look up their assembly labels. See the current version of R/W (search for "RSLW:") in the assembly to see how it's done.

Here is my solution to patch the existing BLOCK and BUFFER (only lightly tested):The 48 and 44 are the offsets into those words where the old R/W CFA lives. Note that RAM will likely be set to zeroes in a simulator and might be garbage on a real system. You'll want to fill them with blanks (spaces) first if you want to put code in them. Do note, if you are used to Tali which has block size = screen size = 1K, that FIG uses blocks of 128 bytes by default (B/BUF . to see on your system) so each block is only two lines of a screen and it takes 8 blocks to make a full screen.

Wow fellows I can't thank you all enough, this gives me allot of new insight and motivation to keep digging!

All of you in this thread, I have previously learned something from, either thru this forum, your GitHubs, or at least one of you I think I have come across on YouTube. You are all legends in my book

Thanks, and I am off to play with this some more!

PS: SamCoTV : I run TallyForth2 on my SBC as the main rom app, I have a way to go, but wanted to share I very much enjoy working with it and its the main interface, making calls to other programs and so on. I follow your GitHub, read your "patch" emails, and hope the day will come I can contribute.

I keep going back to FigForth for the learning experience and, well because I can't stand knowing I don't yet understand!

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

About 5 years ago I was playing with FIG and ran into the exact same frustration, so I'm happy that I now know enough about Forths in general to go back and actually solve this issue. If you keep playing around, you too will learn enough to be able to do the same. The best way to learn is to work on things (regardless of whether you get them working or not - I have about a 30% success rate of idea->working prototype).

I think that's one of the reasons I like Forth so much. It lets me very quickly poke around at a low level (to see if the hardware is working) and also very quickly get to a high level so that it doesn't take as much time to determine if something is even going to work or not. Also, when things do go wrong, I can use those same words I just developed to recreate the issue and see if I can solve it. It's nice to be able to bring the system right before/after a failure and then be able to poke and prod the system and try changes live to see if they solve the problem.

If you are going to be playing with FIG for a bit, I'll give a pointer to a version of .S that I used here (I don't remember where I got it and I can't find it again). Between that and DUMP, you can do a lot of poking around to see how things work.

Thanks to you all, I have been able to get the ram disk working, as long as I start forth and then enter the colon definition mentioned above and patch, however I can't seem to get it to work by direct patching.

I have tried the following with this figforth 1.0:



With Taliforth2, thru the use of:

' myblockreader BLOCK-READ-VECTOR !
and
' myblockwriter BLOCK-WRITE-VECTOR !

I am able to create execute custom assembly which for example, assume I enter 1 list:
1) Store the screen number 1 which I want to work with by gathering the topmost item on the data stack
2) Convert this number to a decimal value
3) Instruct my sd card to open and read the related file, in this example 1.fth
4) Populate the buffer 4FF location with this data

With a flush, I do something very similar, creating separate files for each block named by their block number.

For FigForth I was hoping to achieve something similar, and thought a good start would be to get the ram disk working and from there figure out what I needed to do.

In the simulator, I can enter the colon definition in this thread and patch block and buffer with the new R/W as given, and this works. I have further tested it by creating words to clear the appropriate memory and also to write some characters to specific places to see that they show at on the respected screens at the right places. This work great.

However, once I alter the figforth 1.0 source as mentioned above, the simulator will crash on a 1 list command for example. I cannot determine where it crashes either. I have tried breakpoints, however, even before I make modifications, it appears R/W and/or RSLW are never executed. This is hard for me to follow, because if I enter a 0 load, although it passes thru allot of garbage, that does not crash and is reading memory from "somewhere" thru some routine.

Thanks !

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran