One of Scot's (scotws) other projects, besides creating Tali Forth 2 for the 65C02 , is Liara Forth for the 65816, specifically for the W65C256SXB board: https://github.com/scotws/LiaraForth

What chip is that?

Thanks, but I can't take credit. I got the idea from Blazin' Forth. From the Blazin' Forth System Documentation:

And it's not that complicated. Here's the code for CONFIGURE for my Forth:

MRU and LRU are two VALUE's that point to the first and last entries in the buffer table, a small data structure that manages the block buffers. The table has a phantom entry at the top ( to facilitate moving the entries ) and one entry for each buffer. Each entry is 6 bytes ( 3 cells ): block number, buffer address, and an update flag. The entries are arranged with the phantom entry at the beginning and the other entries from most recently used (MRU) to least recently used (LRU). This facilitates keeping the most recently used blocks in memory when a new block needs read from mass storage and all buffers are used.
That part at the end ( MRU 283 ! ) tells the Commodore kernel that MRU is the top of memory ( as far as the Commodore kernel is concerned ) so if I open an RS-232 channel, the Commodore kernel will allocate memory for the RS-232 buffers ( it allocates two 256 byte buffers ) without interfering with Forth's block buffers.

As for Tali Forth 2 being in the public domain, there was a discussion at this thread viewtopic.php?f=1&t=3090 concerning this very thing.

Let me guess, your implementation of BLOCK and BUFFER would be:

Talk about following the letter of the specification while ignoring the intent.
Seriously, If such a technicality was acceptable to the standards team, then why require the block wordset to be present when support for files is present?

The standard doesn't require block storage at all, those words are optional.

The file word set is independent of the block system, you don't even need to support it if you have the file words.

Really? That's what I get for being lazy ( because I am currently not interested in implementing the ANSI standard ) and taking someone else's word for it instead of carefully checking the standard for myself.

Microchip 24C1025? I like that. Let me suggest using our hobbyist-friendly I2C-6 connector, for tiny I²C modules: viewtopic.php?f=4&t=2155 A few here on the forum have incorporated it into their SBC designs.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Chapter and verse. Yes, the block word set is optional, except when certain of the file-access words (basically, anything that can actually manipulate or query a file or its contents) are implemented, or if BLOCK, FLUSH, or UPDATE is implemented. Oddly, the argument can be made that the rest of the block word set doesn't trigger the requirement of section 3.2.5 (see below for the quote) for including the entirety of the block word set.

Close! But I like exception handling:
And, yes, I acknowledge that this is entirely silly. Worse, the apparent "out" of declaring that a system implements all of the words of the file-access word set without declaring that it implements the file-access word set (thus avoiding the requirement of 11.3.2) falls afoul of 3.2.5:
Which, as we're about to see, was deliberate.

The actual justification is, in fact, given:
Because merely declaring a dependency on the Block word set is, for some reason, insufficient. In a way, though, I'm glad to have this justification. It means that I may safely say "this is silly" and ignore it, instead of having to honor it because it might actually be important.

It's a 24FC1025 from Microchip. It's listed as a 1Mb IC, but of course that's Megabits, so it ends up being 128KBytes. It programs in 128byte chunks, and it has an oddity in that 64K of it is at one I2C address, and the remaining 64K is at another I2C address. I suppose that's not much different, code wise, than having your blocks split between two disk drives. 128 blocks is way overkill for my uses, but it works pretty well based on my initial experiences with it.

I've written everything in Forth and it takes about 4 seconds to read or write a 1KB block. I'll rewrite the routines for it in assembly at a later date. I found Garth's suggestions about pins to use and some assembly routines, so I should be able to talk to it as fast as I can bit-bang at 4MHz. It's rated for 1MHz I2C (at least the FC variant I have is). I was just happy to find a big (relatively speaking) flash chip that ran on a 5V supply and came in a DIP package.

Thanks for the link, JimBoyd. I'll give that thread another read later and discuss it with Scot (scotws) as it's his project.

I saw that connector, Garth. It's a little late now as my board is already made, but of course I didn't know I was going to be adding EEPROM at the time. I will definitely be adding that connector if I make another board in the future. I may make an adapter for my board with a few of those connectors on it if I start adding more items to my I2C bus.

Thank you for collecting all of those implementation notes on I2C in one place. I used one of your suggested pinouts (clock on bit 0 and data on bit 7 of one of the VIA ports) and I expect that will let me run the IC as fast as possible when I get around to rewriting my routines in assembly. I have the "FC" variant that is rated for 1MHz I2C because it was the same price as the 400kHz versions from my vendor.

I'm implementing just the optional block words, so fortunately I don't need to do the file-access words as well. In the 2012 standard (what I'm currently trying to follow) https://forth-standard.org/standard/file it just says you need to provide a mapping if you support blocks in files. The way it's written sounds like they got rid of the need to support blocks at all if you don't want to. They do say you need to put 0 into BLK when using a text file as input, but that's the only block word I can see that they mention you needing.

I can offer my Liara Forth (https://github.com/scotws/LiaraForth) but it's tied to the 265SXB, written in my own variant of 65816 assembler, and after what I've learned from Tali Forth 2 it should probably be taken to some place nice and quiet and completely replaced with something else. Despite its quirks, the 65816 is fun to program, though I'm somewhat frustrated by the lack of an emulator with the ease of use of py65, and the 265SXB can be frustrating as well.

BTW, for the record, Sam is being modest -- for instance, he pretty much single-handedly added the test suite to Tali Forth 2, which improved the code quality by leaps and bounds, as you can imagine. The code is in the public domain, because that is the tradition with Forth.

Yea, that's where I was getting the information -- the 2012 standard.

PETTIL on a 32K machine uses only one 1K buffer for BLOCK, BUFFER, LOAD etc... It does some odd things with memory management