SamCoVT
commented
4 years ago After reading some of the documentation on the ANS file words, it looks like modifying REFILL is optional, and I can just read one line at a time into my own buffer and evaluate it there. Lines up to 128 characters need to be supported, but I could make a separate buffer of that size. I was hoping to use my 512 byte sector buffer (currently reading off a compact flash card), but without refill I wouldn't be able to handle lines that cross a sector boundary. The ANS standard says that refill, if you do optionally modify it, is supposed to read a single line into the input buffer anyway.
It's interesting reading about the file words in the standard, as they obviously seem to assume you will be using operating system facilities to do things and definitely seem biased towards the C standard library. In our case, there is no OS to go ask to do things, so we have to write it ourselves.
I think I'll go down this path (read lines into my own buffer) for a while and see where it takes me.
FYI, I was able to get blocks working fine, reading out of a block file on a FAT32 formatted compact flash (1K blocks line up very nicely with 512 byte sectors). The vectored words worked great for that. Blocks are great for simple software and simple storage (like my I2C EEPROM), but I'd like to be able to run the text files from my PC directly without having to format them into blocks. I might also take a peek at the code for \ and make it so it works in blocks as well (eg. if BLK is non-zero, stop at a multiple of 64 from the beginning), as much of my reformatting for blocks involves changing all comments over to parenthesis.
If I do end up writing some of the ANS words (it looks like I need to do at least read-line now), would you consider a collection of "Tali extensions" that folks could add to their user_words.fs or paste into the simulator or over to their hardware? Perhaps an "examples" folder? I've already implemented most of the double words that Tali didn't already have, as I needed 32-bit support for FAT32, and I could see a set of file words that could be added. My current setup uses compact flash, but if you replace the code to read and write sectors, it could just as easily use fat32 on an SD card.
scotws
I don't know it makes sense to implement all of the ANS file words, however I would like to add enough support to be able to run code directly out of files.
inputandoutputare already vectored, but I need support inrefill(and perhapsaccept) to properly handle the end of the file. I was considering having a NULL character frominputindicate the end of file, as the implementation of the filesystem will be hidden from Tali and only the vectored input and output words would be used - the keyboard never returns a NULL character.A slightly better option will be to add minimal support for "fileid" to Tali and provide the words to determine if a file is EOF, eg.
file-positionandfile-size. I can only think that these would need to be vectored so file system implementors could replace them without having to updaterefill.To get started, I want the ability to run code from a single file at a time with no nesting. The standard says up to 8 levels of nesting must be supported, and I'm not sure if it makes sense to support that much, but I would like to support nesting in the future.