DdraigDOS: The early(ish) days
DdraigDOS was born out of a desire to have a proper operating system for Y Ddraig. Initial testing to get the basics of the hardware was done using some basic programs in ROM but the majority of the hardware testing and initial software development was done using my monitor ROM. It allowed me to test the various hardware functions and to download programs over the serial port, that could then be run out of RAM. The main downside of downloading programs over a serial port, at 38,600 baud, is once the programs grow over time it can take a long time to download. I think the final version of the VGA card demo test demo took over 8 minutes to download, mostly because of the bitmap image embedded into the code.
While it could have been an option to add file support and more to the monitor, it thought I would be nicer to have a more familiar operating system to work with. There’s a few options available that could have been used such as FUZIX, Linux, CPM-68K, EmuTOS and probably others but it seemed a more interesting and good learning experience to write a basic operating system just to get a better understanding of how the operating system works.
I’ve been working on DdraigDOS for close to a year now. Work has been done on and off during that time but it’s getting to a point where I’m happy with how it’s working.
DdraigDOS runs out of the ROM on the board and has the following features:
- Syscall interface using TRAPs to access the hardware functions
- The NewLib library as the standard C library
- Simple driver system to detect and use installed cards
- Display driver that adapts to detected video card and displays in the correct mode
- FAT32 filesystem support
- ELF executable support
There’s a serial console that can be used to access the OS that co-exists with the keyboard and display support. Currently any text on the display is also written to the serial console and text input can be done either with a keyboard attached or through the serial port. The plan is to have the video output as the main interface and use the serial as a fallback if there’s no video card connected but for now it’s convenient and provides a simple way to download programs to RAM or copy files to the disk.
The FAT32 support is provided by the FatFS library. So far, it’s only working on the IDE interface connected to a CompactFlash card. I’ve yet to try it with a physical hard drive but I think that would be a fun experiment providing I can find a working disk drive. I’m also planning to add floppy drive support via an expansion card so it will have to be extended for that, but that’s a little while off yet. ELF executable support is useful in that it allows programs created with the GCC toolchain to be run without any special requirements for the produced executable.
Built in commands
The following commands are built into the operating system.
basic - Start EhBASIC
binfile - Receive binary file over serial and save to disk <filename>
cat - Display contents of <file>
cd - Change directory <dir>
copy - Copy file <src> <dest>
dir - List directory contents
del - Delete file <file>
dump - Dump memory <from> <count>
help - Show available commands
loadmem - Load a file to the specified memory location <file> <mem>
mkdir - Create the specified folder <dir>
rename - Rename file <src> to <dest>
run - Run code at address <addr>
srec - Receive S-Record file over serial
time - Display or set the current time and date (time ? for help)
uptime - Displays how long the system has been running
writemem - Write memory <addr> [byte ...]
Most of the commands are file system related and should be familiar in their use but there are a few there that are more useful during development.
srec, loadfile, run and binfile
These are a set of commands that have been used mainly for development purposes on DdraigDOS and will mostly be deprecated and removed at some point in the future. These commands were used mainly after the file system support was added. They provide a convenient method of transferring files or running code from the disk but without having to manually copy the files onto the CF card from the PC. I found development a lot easier once I could do everything from the serial terminal on the PC rather than having to physically move the CF card just to get some new programs on there.
Both the srec and binfile commands allow programs and data to be transferred to Y Ddraig over the serial port. srec receives and decodes a Motorola S-Record file into memory. It’s intended for downloading test programs rather than data files and once the program has been downloaded then the run command is used to execute the program at the specified address. The loadfile command was useful in a similar manner that it also allowed programs to be loaded from disk into memory. The run command was used then to execute the programs.
The downside of both the srec and loadfile method of running code is that the starting address of the code needs to be known so it’s not useful for general use. Both were very useful before the ELF executable support was added just for the early testing.
The binfile command is somewhat more useful than the others, it’s sole purpose is to receive a binary file from the serial port and write it to disk. This is currently the main process for getting data and executable files onto Y Ddraig. This command is possibly the only one that may be kept in the OS. While better and more efficient file transfer methods are needed for downloading code to Y Ddraig, until that happens this is still very much a useful command.
Further work
- Command history and editing
- Batch files/scripts
- Networking support
- Improved file transfer support
- Flash updater
Command history and editing
Possibly more of a luxury than a necessity but being able to scroll up and down through the last few commands run and being able to change the command line is basically the default on most operating systems these days. It may not be the most important feature to be added, but I’ve lost count of the number of times I’ve hit the up-cursor key and then remembered that it doesn’t work. It’s a very useful feature to have and I believe, one worth adding if only to allow me to be lazy when typing commands.
Batch files/scripts
A simple batch file, just reading in a command with parameters and running it would be an helpful feature to add. Initial support would probably be just to read and execute a few basic commands but for longer term, it would be nice to have some simple scripting support similar to how MS-DOS batch scripts work.
Networking support
The operating system currently can detect and initialise the RTL8019AS card with some default settings. Other than initialising the card, nothing else is supported yet. A full network stack is needed along with some basic support added to the OS for at least obtaining an IP address. How much of the networking system is built into the OS and how much is handled by the userland programs is yet to be determined. Having never worked on network code other than at a higher level, this could be very much a learning experience and very likely to use something along the lines of LwIP to provide the network code.
Improved file transfer support
The current binfile command which is used for most file transfers to Y Ddraig works but is very basic. There are not error checking abilities and large transfers over the serial port can be slow. The plan is to implement some improved transfer protocols such as Kermit or ZModem to make getting files onto the disk drive a lot easier. Multiple file transfer alone would make things a great deal simpler.
If network support is added, then it opens up even better ways of copying files to/from the computer. The ability to transfer files over the network should speed things up greatly.
Flash updater
Updating the ROM on Y Ddraig is probably the main use of the srec command. To download a new version of the OS, an assembly language program is used that contains the entire OS binary image. This is downloaded using the srec command and then executed from RAM. The program then erases and re-programs the flash memory with the new code. While this method works well, it would be nice to have the functionality built into ROM. The ability to have something along the lines of *upgrade
