figFORTH help needed!

[enso1]

I finally got figForth working with an SD card, but...

I cannot find a block file for 6502 figForth.

I would also like to get the screen editor working, but again, cannot find the source.

I've spent the day googling and digging through various repos, but no luck.

If you have a working fig, please help me out.

Thanks

[SamCoVT]

That's exciting to hear that you got an SD card working. Are you planning on using the SD card raw as a block device (eg. just put block 0 starting at sector 0 with no filesystem)?

I don't know where to get a binary copy of the screen editor that Fig came with, but there is the source in the "fig-FORTH INSTALLATION MANUAL" by William Ragsdale:
http://archive.6502.org/books/forth_int ... lation.pdf
The editor starts on page 53 by my PDF reader's count, but the handwritten page number is 51. There are instructions for using it after the screens of Forth source. Note that this is not a full-screen editor, but rather a line-by-line editor that lets you work with Forth screens. Also, some of the words used in the editor come from earlier screens, like (LINE) is declared back on screen 61.

Were you looking for an interactive editor (eg. a full-screen editor)? Those usually rely on the terminal or video hardware to move the cursor around. There are some for more modern forths, but they will likely have to be modified for fig-forth as fig doesn't use 1024 byte blocks that ANS ultimately settled on.

[edited to fix title of manual]

[enso1]

I'd love to have the original 6502 fig-Forth screens matching my system... I found all kinds of blockfiles and text files with other, non-6502 systems or heavily modded for the hardware...

My SD disk is currently formatted FAT16 (for no good reason, FAT32 is not more difficult to parse). After formatting, I wrote a giant gigabyte file, which is by default contiguous, and after digging through the directory I found it starts at sector $B80, so I hardwired my fig R/W to compute the 512-byte sector as (BLOCK<<1)+$B80. I am not certain about that shift as fig may do it by itself -- the BLOCK/SCREEN/SECTOR/BUFFER relationship is a bit confusing to me still, and I don't have a real block file...

[SamCoVT]

I was using that method myself for a while, and it worked reasonably well. I ended up writing FAT32 support in Forth enough to be able to INCLUDE forth files by name (read-only), but if I were to do it again, I would use FAT16. FAT32 ended up with a lot of mixed double and single-cell values on the stack (difficult to keep track of) and the directory entries are messier because of the long file names (which I ignored and just used the short 8.3 names, but you still have to skip over them).

I did see in a different thread that you had already modified FIG to use 1024 byte blocks. That, generally, makes all of the block stuff much easier.

I did see this note in section 2.0 (Distribution) of the fig-FORTH Installation manual, which may explain why its a bit hard to find disk images:
FIG does not intend to distribute machine readable versions, as that entails customization, revision, and customer support better reserved for commerical vendors.

That seems to imply that any disk images that were created were made by typing in the listings.

Do watch out for code that assumes the 128 byte blocks that FIG originally came with. They tried to make it work with other sizes using the B/BUF (bytes per buffer) constant, however I ran into issues trying to make it 512 bytes to match a hard disk sector (compact flash, in my case). When I added the block support to Tali and got to use 1024 byte buffers and blocks (the newer ANS standards mandate that size for both buffers and blocks), things were much easier.

[enso1]

Yeah, I saw that official notice, but was hoping that in the last 50 years someone bothered to share it...

[resman]

Here is my Apple 1 FigForth implementation that uses the CFFA1. I keyed in the PolyForth editor and assembler according to my blog post: http://schmenk.is-a-geek.com/Forth.html

I worked around using the CFFA1 as a block device through a ProDOS formatted partition by simply naming each block as a ProDOS file named BLOCKxxxx. Hopefully you can find something useful here - I added the ShrinkIt archive re-compressed as a ZIP file.

[enso1]

Thank you!

[BruceRMcF]

enso1 wrote:

... the BLOCK/SCREEN/SECTOR/BUFFER relationship is a bit confusing to me still, and I don't have a real block file...

There is one mindspace, where BLOCKs are as long as the hardware sector. I'm guessing that in the original fig model, that's where they were at.

In this mindspace, the BLOCK number is the consecutive numbering of the sectors by their logical position in the file and the SECTOR number is the physical reference to the location of the sector on the disk.

A SCREEN is then enough BLOCKs to make 1KB.

There is another mindspace where a BLOCK is an abstract storage unit 1KB of characters in size. If the sectors in one storage device are 128KB long (like CP/M 2.2 sectors), then 8 consecutive sectors are one BLOCK, and if the sectors in another storage device are 512KB long (normal for FAT16), then 2 consecutive sectors are one BLOCK.

In this mindspace, a SCREEN is just what you call a BLOCK when it contains CODE (because it might contain some other kind of information ... eg, a module of pre-compiled code to be loaded into a pre-allocated Module location).

In any case, BUFFERS are using one of the 1KB buffers that normally holds a BLOCK or SCREEN that is being worked on without actually associating it with a BLOCK on the storage device. I don't remember if FIG does this, but some systems you could grab a buffer, and then write it out to a BLOCK, which overwrote what was there before without the overhead of reading it in first.

One thing about a 16bit cell size and 1KB BLOCKS is that it implies 64MB address space for BLOCK files, versus a maximum 8MB for 128KB "blocks" ... so if you never need a single BLOCK file to be bigger than 8MB in size, one thing you can do is to add a layer of abstraction to blocks, have a byte mapping up to eight "installed" files into the BLOCK space, 0 unassigned, 1 assigned, and have 8 BLOCK ranges able to hold up to 8MB BLOCK files each and then store the information required for each BLOCK file in a regular structure ... maybe a file descriptor and size in blocks (so you can throw an error for specifying a block past the end of the file). Then the top 8 bits of the BLOCK number indicates which one of up to eight open BLOCK files the BLOCK number refers to, and if that BLOCK range hasn't been allocated, an error can be thrown if it is accessed. That makes it very easy to have a simple wordset for assigning files or ranges of sectors to one of the eight zones of BLOCKs. IIRC, that wasn't commonly done in fig Forths (things get confusing unless all storage devices are treated as if they have the same size BLOCKs) ... but Forth INC relied on that for its BLOCK based systems.

If you do that, you'll want to modify the definition of LOAD so that rather than just avoiding interpreting BLOCK 0, it avoids interpreting when ( block# ) "HEX 1FFF AND" is 0, so Block 0 can be used as a description block.

[Dietrich]

Quote:

I would also like to get the screen editor working, but again, cannot find the source.

For a screen editor written in Fig-Forth you might want to look after https://github.com/Dietrich-L/CPM-65/bl ... VED-VT.BLK
It edits block screens which reside in high memory, but can be converted to work on disk blocks easily. THe editor is a screen editor with VT100 compatibility.
I am using the high memory RAM disk approach, because I want to fill this memory space from files under my underlying CPM-65 operating system and thus do not need to have separate forth dedicated disks.

Dietrich