So when I discussed checking out Bran's Kernel Development Tutorial apparently I wasn't kidding. I have now compiled my own kernel in C (and it actually works). As kernels go I suspect that it is unique, because I implemented a floppy disk driver before a keyboard driver :-) But hey, this is my OS so I can do whatever I like... Here it is in action:
So far, all it does is boot up, then find the first floppy disk and do a hex dump of the disk contents to the screen. But there is a *lot* of coding needed to make that work! At kernel level you have responsibility for stuff like turning the disk motor on and off and moving the drive heads to the right track. Plus the command set for accessing a floppy drive is pretty *nasty*. Also, I have had to remind myself all about tracks, heads and sectors.
The information and examples shown on the OSDEV tutorials have been essential reading. Without all their examples I would not have gotten this to work. I have tried not to just copy & paste somebody else's code, I have tried to write this in my own style - but credit has to go to all those people involved in the OSDEV tutorials.
My code is only designed to work with 3.5" drives (although it has not been near a real disk yet) I have only used it in VirtualBox. It does not seem to work in Bochs for some reason (I don't know why yet).
So anyway... this has been a challenge, and I'm very pleased that I've gotten something that actually works. I guess the next step is to begin writing FAT12 support, so I can get some proper file access.
I have been messing around a bit more with editing disk images and my IsoCobbler application. Here is a newer version (and source in Visual Studio 2010) now with some extra features.
There are commands like NEW, which allows you to start from scratch with a blank FAT formatted floppy image (the 1.44 or 2.88Mb variety). You can also LOAD and then EXPAND your existing 1.44Mb images and IsoCobbler will attempt to make them into 2.88Mb ones, trying to keep the boot sector working in the process.
After writing the EXPAND command, which needs to transplant the boot sector and hack it around a little bit, I decided to implement an MBR command as well. This allows you to put in your own boot sector, or save the existing boot sector from a floppy disk image. Anyway, for details of all the commands, see the "Help" file included in the downloads. This version still expects all the files to be in the root, it doesn't support folders yet (which might be next on my list actually).
So after all that messing about, I have gotten as far as building my own boot sector in x86 assembler (using NASM, The Netwide Assembler) which in turn boots into my own simple kernel (and when I say kernel, I mean Hello World application). IsoCobbler did of course make a bootable ISO out of that experiment, so I have a bootable CD that runs my own bootloader and then starts my Hello World code as the kernel. Umm, now I'm feeling the need to go off and write a 'proper' kernel (in C probably). It seems that making a program to help me build CD-ROM images has gotten all out of control, since I seem to be considering the idea of building my own OS as a consequence. Right, I'm off to visit Bran's Kernel Development Tutorial, I may be quite some time...
One of the results of all this DR-DOS memory stick work was that I also created a bootable floppy disk image. I created it using Microsoft Virtual PC ... but the resulting disk image would be bootable in VirtualBox too. I manually edited the xml files to attach the virtual floppy disk in Virtual PC, as described here. This disk image just boots DR-DOS with a CD ROM driver, some memory management and a RAM Disk driver.
My next step will be to use this floppy disk image to build a bootable CD. I will then use that as the basis for my revised PDP-11 Live CD. I'll probably use SIMH for DOS since I don't expect that I'll be allowed to redistrubute the demo version of Ersatz-11 (although I think that Ersatz is a better emulator).
Here is a way to make a blank floppy disk image that you can use in Oracle VirtualBox. It's a hacked around version of this. You just make a batch file with these DOS commands in:
if exist blank.img del blank.img
for /l %%i in (0,1,31) do echo 01234567890123456789012345678 >>blank1.img
for /l %%i in (0,1,35) do type blank1.img >>blank2.img
for /l %%i in (0,1,39) do type blank2.img >>blank.img
After running it, you end up with a working disk image, and here is a version that I then reformatted inside a virtual machine. I've since found that you can use these images in Windows VirtualPC too, although there is no UI to attach them, you have to edit the xml files of your virtual machine manually.
So it appears that I've forgotten how to connect up a floppy drive. In my defence, I have not used a floppy disk in years... Fortunately it seems that the cable in my PDP-11/53 should be the standard type. My likely mistake was to rummage in my bin of "reclaimed" computer parts and try to use the cable I found in there. It does not have a twist in it :-( Typical.
Seriously. That might be the cause (or one of the causes) of the "Drive Error" message I was getting. Mind you, if my RAM chips have died (as I suspect) then I might get other error messages. I should expect dodgy memory to manifest itself in all kinds of ways I guess.
So after some reading on the interweb I have been reminded that the standard floppy cable has a twist in it. It looks hacky; but was the normal technique used to distinguish drive A: from the B: drive. Of course the cable I had in my box of leftovers was flat - a non-standard cable. I expect that it won't work in my PDP.
On a standard twisted cable the connectors after the twist are usually for drive A: whereas the connectors on the untwisted section are for the B: drive..
The other thing that I remembered is that 5.25" drives normally had a "card edge" connector, rather than a couple of rows of pins like you find on 3.5" drives. I had forgotten that too. So when buying floppy cables, if you want a "standard" one you need both card edge and the 34 pin female connectors, with a twist in the cable.
Maplin's still sell these cables, so I've now got the correct one (I think). Hopefully I will be able to correctly connect my RQDX3 disk controller to my RX33 disk drive now. Watch this space...