Did - thanks for linking to that!
Yoda wrote:@DavidCooper,
I solve the backup task very simply. I perform the main development loop is in the Bochs. So I just prepare a simple and small enough files - HDD images which work in Bochs. The real hardware is primarily for test, - will it work on it too. The backup process is just a copying of HDD image file.
I can see why many people would would find that the most convenient way of working, given that they're likely to be writing their OS code in a compiler or assembler under an operating system which may not be their own, so once they've got it converted into a disk image, the quickest way to test it is to boot it in an emulator, and it's also safer if it all goes horribly wrong. For me though, I do all my programming within my own OS - it became self-hosting at a very early stage in order to get away from loading via Qbasic (where it was originaly held as machine code in data statements). The way to achieve that was to have two copies of the first OS module which can modify and save each other. Ever since then I've been able to boot the machine and get to work within seconds instead of having to watch Windows waste several minutes of my life first, and then when I want to stop I can just save anything that needs saving and switch the thing straight off instead of having to wait a minute to see if it's going to hibernate or if it's stuck in a freeze. It also frees me from being pestered by idiotic messages from Windows about unused icons on my desktop while I'm trying to work on something so complex that it's taken me half an hour to load all the ideas involved in it into my head.
An emulator isn't the most comfortable working environment either as everything ends up in a small box instead of using the whole screen (unless you're doing something with a graphics mode the same size as the screen), there are irritating delays with everything, and particularly with cursor alignment when trying to get somewhere using a cursor key held down (although QEMU is a lot better than Bochs in that regard), the hardware scrolling doesn't work, the clock doesn't keep real time, the alarms are silent and the machine runs hot. I find emulators useful as a way of testing code that's likely to result in a crash or data corruption, and they're also useful as an indicator of things which might cause issues on some hardware, but my own OS running on real hardware is a much more comfortable programming environment, and it provides the added advantage of keeping all my program code and data off the internal hard disk (unless I actually want it to go there). I did write MBR code within QEMU though, since I was already going to be using Windows and HxD to write it to a flash drive.
Anyway, my plan is to go on working on real hardware, but instead of using a toppling pile of floppy disks I'm going to use two SD cards and two USB flash drives - I'll start by using one of the SD cards, keeping multiple copies of everything on that and occasionally backing up the most recent versions of things to one of the two flash drives. After a while, I'll stop using the SD card and switch to using the backup flash drive instead, making new backups from time to time on the second SD card. After another while, I'll start using that SD card as the device to work from and start using the second flash drive for backups. After another while, I'll use that flash drive to work from and bring the first SD card back into play for backups, and I'll just keep rotating through using those four devices in this manner. Additional backups of various things will be saved to other flash drives to keep a permanent record of the development of the OS, as well as of other software and files.
