Direct CF card driver use

[toncho11]

@fhendrikx @ghaerr

Having this direct CF card driver opens new avenues for a software MMU or banking with pages of 512 bytes or multiple. The driver might provide a good speed for a swap file.

Actually if we can set a swap partition (no filesystems) then it might work very well. A swap partition where each new data is stored at the end because we have space and we do not care about fragmentation.

#2345

[ghaerr]

The driver might provide a good speed for a swap file.

We already have the XMS ram driver that would do the same thing even faster - no one is using it for such purposes.

But the bigger problem with any software MMU/banking is that any application program has to be specially written to take care of such a thing. Back months ago we came up with a plan to build web browsers and editors, but none of them were already built to take advantage of the design necessary for this type of memory expansion.

Correct me if I'm wrong, but weren't the early EMS (hardware banking) solutions permanently outdated once the 286 and then 386 appeared with its ability to address more memory (XMS)? If true, this could mean that software banking techniques are really only useful on 8086 systems.

[toncho11]

Yes, I am actually thinking for the XT machines. How for example Nano-X can handle multiple applications using 640 kb of memory on an XT machine.

[ghaerr]

I see. Well, for XT yes we're likely limited to what you've suggested. XMS ramdisk or extended addressing won't work. Someone will still have to port and/or develop programs specially for XT.

How for example Nano-X can handle multiple applications using 640 kb of memory on an XT machine.

Yes, memory is quite limited - and in Nano-X's case it's still limited for 386+ machines with XMS, as Nano-X doesn't know anything about XMS either. In general, any and all graphics has to be very specially handled as a image the same size and resolution of the EGA screen itself can't even be fully held in main memory, ever.

[ghaerr]

On another subject about CF card use: ELKS will need to somehow automatically handle the business of swapping CF cards. I'm thinking that, instead of how it's coded now and reading the CF card metadata only at boot time, it should also (re)read the metadata at block device open time.

This would allow for the user to swap CF cards in between mounts, or, if just using hd or another program to display data, at any time between program executions.