Work is progressing on the Dos Abstraction layer. The mountlist parser is finished, and the filesystem and device are being looked up by the library loader and accessed. If found, they are being put into a DosDevice structure and added to the list of devices.
I have just finished the abstracted version of LoadFile (which used to be implemented by the FAT driver dierctly to load from the "current" FAT volume) so that it looks up the dos device in question("BOOT:"), find the Filesystem attached to it, and call the LoadFile routine on that filesystem, passing it the path of the file.
Onoes! /o\ A memory leak has developed somewhere within the Dos_Loadfile routine. It's leaking 32 bytes, but it is cause the available space for the file to drift by 544 bytes each time. Something must be done! One scheme is to modify MM_Malloc() so that it records the return address of the call to MM_Malloc(), that way, the address of the instruction that allocated the space will be on record.
Success! With a little inline assembly, I have been able to read the address of the instruction that is calling MM_Malloc() and store it along with the used block entry. When my used block is full (and the system is therefore going into a controlled fail) it writes out the top entries in the memory list so that I can see what the block size is and where it was allocated, and can track it down.
My file searching function (that finds the first directory entry that matches the filename) was being called, but the returned entry was not being freed in all cases. That was fixed, and now it is looping the load quite happily with no leak. \ o /
Memory leaks and allocators aside, I need to finish off changing the Fat driver so that it uses the Context and not any global variables. A good place to start would be to remove all the global variables and then see where we are :)
Ok, so I have spent most of the evening re-writing the Fat driver to use a structure for its state instead of global variables. This way it will be able to handle multiple Fat volumes at once.
Damn, that's why it doesn't work. I need to implement the mountlist parsing within the Ram driver. It needs to read the parameters and make sense of them. However, on the up side, it did remind me the LoadFile routine needs to test for a DosDevice being passed, a FileSystemContext within that DosDevice, and for the Context to be flagged as valid.
\ o / A quick implementation of the versatile strtol() string-to-long converter and I'm able to finish parsing the mountlist values into the ram driver, and it has found the disk image in memory correctly, and FAT has deemed that it is valid.
Now ... why is it throwing an interrupt 6 (Invalid OpCode) when I try to read the drive?
Fixed the invalid opcode ( was passing 0 instead of the context ) and put in the appropriate exception path for that too, and then fixed the general protection fault that it hit after that. I was using a ternary operator without the correct parenthesis. Instead of allocating 1024 bytes, it was allocating 2, then using 1022 bytes of other allocation's space with "predictable" results.
You can now request that the Dos layer load a file such as "Boot:test~1.lib" and it will look up "BOOT:" in the device list, find the FileSystem attached to it and tell it to open "test~1.lib", which will then use the BlockDeviceDriver in the DosDevice to read the "disk".
No comments:
Post a Comment