For some time now I have thought about how we could create a more robust Sequential Character File manager (SCF) based on our existing SCF. The limitations of SCF as it exists are:
- One character at a time reads and writes to drivers
- Outmoded notions of older features like slow baud rates
What I am proposing is the creation of an XSCF file manager which would:
- Have a new read/write interface to the driver. Instead of passing a character in regA to the driver's write routine, we could pass a pointer to a buffer in regX and a count in regY. This would allow data to be blasted onto high speed devices. The same would go for read; the driver would return a pointer to a buffer and a count of data ready.
- Rework the options section of the path descriptor and device descriptor to bring it "modern".
I'm sure there are other enhancements that we could think of.
Some additional work would be required to support XSCF:
- drivers would have to be modified to accommodate the new multibyte I/O interface
- commands like xmode/tmode would have to be modified to accommodate new path options.
- command line utilities would have to be reassembled to accommodate changing offsets in the path descriptor, etc.
It would be a major transformation but one that would really boost performance.
You seem to have CSS turned off.
Please don't fill out this field.
This sounds similar to how OS-9000's SCF works, yes? I can imagine the improvement would be great. What new path options do you see?
Would there be no way to have a SCF/XSCF combo that would support both methods?
That does sound like an interesting and advantageous difference Boisy. What might be a problem for level3 if I ever get it going is that the pointer being passed wouldn't be pointing at the right place when the level3 block switching takes place. I am working on that because recent versions don't seem to leave as much system ram, by several kilobytes, compared to say 20 years ago when my coco3 lived on the next desk and an amiga was under this one. Or would it? If the complete processor is stacked before the switch, and pulled after, and the actual buffer is in the drivers rmb's outside of the separate 2 blocks that are being switched, and restored after the block switch has been done, I can't see why it shouldn't work. Because the block switching will take some time, I expect level3 will be noticeably slower at some operations that involve moving data from a drive to the screen. But, yes, I'd say "gopher" it. If an outline of a std way to convert the drivers can be done, I might be able to help with one or two of them once a recipe is known. ;-)