Ach, Martin, the projects that are worrying me are a text editor that can handle large files efficiently, and a micro-C compiler
both of which need a working file system!
At the risk of more meandering; Lets think about what "large" might be in the context of a 6502... (Or even a 65C816).
Which is what I did when I wrote (re-wrote/ported, again) my original C nano-like editor which I've used in several projects over the years....
You have 64KB of RAM. Lets say you have 32KB free for applications. Do you want the whole file in RAM? (Answer; Yes - because paging in bits from a file is slower than you can type) You you need to manipulate 32K of RAM. That's achievable.
My first port was to take the C version and make it run in my 65C02 board. It compiled with cc65 to about 14KB of code, using the ROM based IO routines (which were another 10K). My system is much like ye-olde BBC Micro with the top 32K being application + OS + IO and the bottom 32K for data. A good number of Acorn ROMs worked without change including BBC Basic, Comal, etc..
The editor worked very well and I could edit text files up to the size of RAM. It relies on a "malloc" which I'd already written in Sweet16. It worked well on the files I edited, but at that point I stalled - because, like you, I wanted "a micro C compiler" for the system. I could edit Basic files as text and *exec them into the system, but that was a bit tedious.
Plan B; Use BCPL. so I could load the editor (written in C), create/edit BCPL source code. Load up the BCPL system and compile and run those BCPL programs.
An iteration later and I'd re-written it in BCPL and I could just about use it on the same system running the BBC Micro BCPL system. Not much free RAM though, but as a proof of concept, I could use it to edit a BCPL source file and compile it.
Plan C; Move to the '816 and write an OS in BCPL. (He said, casually...) Adapted the editor for the new system and it trivially handles files up to 5000 lines of 250 characters long. That's a limit I artificially set. The system has 512KB of RAM - but if I were to load such a file, I'd need nearly 8MB of RAM, so that's not going to happen - in reality files I use are only a few 100 lines long. The editor itself is 1800 lines and 32KB, compiles to about 6KB in bytecode, the BCPL compiler is 2 files of 2500 and 4100 lines respectively. I can not compile the compiler on the '816 system as it takes many hours and runs out of memory. The editor compiles in a few minutes.
And that's sort of where I'm at today, but the platform has moved to RISC-V (and ARM32) with memory sizes measured in MB... The memory allocator is still "best fit" (same as it was in the Sweet16 version) and it seems to work remarkably well.
But there is still the hankering for a micro C compiler... I want one written in BCPL that produces the bytecode my system runs on.... Might have to write it myself - one day... Actually, I'd settle for one written in C that can be adapted to produce the bytecode..
-Gordon
(The code posted last night has the cf_write calls commented out so I can test without trashing the disk!)
Neil
(Small) SD cards are cheap enough now that you can afford to treat them as almost disposable. Or no worse than old uv-eproms. Keep a stack pre-formatted and go for it.
-Gordon
