I've been tinkering with this a bit to develop some tests.
I wanted to dig under the hood a bit for a few things I'd like to work on. I had ChatGPT write a toolchain so that the code can be compiled using the Workbench compiler on my Windows system and then it produces a .image with every thing that boots.
I kicked off a compile on my Lisa 2/5 and let it compare the result so that the output from the toolchain is a byte for byte match with what the Lisa makes and it was.
One thing I wanted to investigate was why Lisa OS I/O feels so much slower than MacWorks. In FILEIO, I found that locating a position within a file repeatedly walked the file's extent map from the beginning. That added more overhead as the requested position moved farther into the file. Changing the lookup to avoid re-traversing the earlier extents helps a lot depending what it's doing.
Another test was to run the same test against the ESFilePro using its RAM vs SD and that netted about a ~10% increase.
The final test I did was using a RAM backed FS (so that the process goes through all the filesystem overhead vs just raw RAM reads) to see what possible upper bounds might be. An actual internal interface would be faster since the extent search eats a lot of CPU cycles depending what it's looking for.
| Request size | Original LOS + ESProFile (kB/s) | Patched LOS + ESProFile(kB/s) | Patched LOS + Lisa RAM(kB/s) |
| 512 B | 18.58 | 23.20 | 31.98 |
| 1 KiB | 30.28 | 36.05 | 57.02 |
| 2 KiB | 44.15 | 49.85 | 93.65 |
| 4 KiB | 57.31 | 61.64 | 137.97 |
| 8 KiB | 67.32 | 69.91 | 180.74 |
| 16 KiB | 73.78 | 74.94 | 213.88 |
| 32 KiB | 77.48 | 77.73 | 235.47 |
The speeds are good, but the reductions in cycles frees it up for working on what it just received I think will give a boost as well. I'd ultimately like to design an expansion board drive that could do DMA. The Lisa supports it having its own ROM to boot from and having a driver in the OS should let it use it.
LisaEm was a huge help in getting this done for quick tests of ideas.