insert clever title here

No huge progress, but a few small things to report.

I’ve got FATFileSystem building the way I want it. Turns out the whole main() thing was totally unnecessary - its enough to build with usestartup=no uselibs="rom". That vastly simplifies things. Now the loader is simply LoadSeg() followed by AROS_UFC0(). I’ve also removed all the references to DeviceIO and replaced it with a naive block getter/setter. Its untested, and probably performs woefully, but it should work. All the other bits that had been commented out because of missing things in the AROS headers are now re-enabled, so the driver itself should be ready to go.

Christoph did a little sleuthing for me, and managed to get a new email address for Marcin Kurek. I resent my request for information, and promptly got a reply! He sent headers, and is looking around for source code, which may be lost as he says this quite an old piece of code. My suspicions are confirmed though - its a block caching layer with support for various device backends - standard trackdisk, NewStyleDevice, TrackDisk64 and SCSIDirect. I don’t know what most of these are (though I can guess), but they’re out of scope for this project. I’ll worry about this stuff further when the time comes for writing porting instructions.

I’ve started re-adding things to the DOS headers to support packets. The first thing I did was put dol_Task back into struct DosList. Upon recompile, AROS segfaults before it starts. Some tracing revealed that struct DeviceNode and struct DevInfo need to have the same layout as DosList, as they need to be happily converted to and from via casting. That’s completely braindead, in my opinion, but such is life. Wholesale adding all the missing stuff in one swoop caused no crashes (yet), so I’m guessing thats enough for now.

The next step, which I’ve just started, is to add two conversion functions to dos.library, IOFSToPacket() and PacketToIOFS(). They really should be internal-only helper functions, except that they’ll need to be accessed by packet.handler, so they’ll just be documented as AROS-specific and recommendations made to simply use DoIO() or DoPkt() as appropriate. All this may change, as I’m starting to see signs of my current architecture fraying a little at the edges. Not enough that I can put my finger on it exactly, but the warning signs are there. Fortunately most of the code I’ve written so far will be required no matter what, so I’m not too concerned just yet.

And for the curious, I’m now storing my code in Subversion. Its not everything yet - I’m also making changed to DOS and its headers. Remember that its all extremely fluid, but any feedback is quite welcome.