Skip to main content

Operating System

I've decided to write a small and very limited operating system called BluePrint-DOS (BP-DOS) for my computers, with the goal being to require a minimal amount of hardware, and to more easily facilitate running programs, by loading them from a block-storage device than burning an EEPROM every time a new program is to be tested/run.

The hardware requirements will be:

  • 32KB of RAM, to hold both OS routines and the running program
  • A free-running timer to facilitate CPU 'sleeping' when no action is being done.
  • A block storage device to store OS and program files.
  • User I/O, for hopefully obvious reasons.
The function of the OS itself will be to:
  • Load, run, and return from user programs.
  • Provide file system routines for reading/writing files to the selected block device.
Lower level functions will be stored in ROM, and these include:

  • Block-storage sector read/write routines.
  • User input hardware routines.
  • Timer interrupt service routine.
  • Display hardware routines.
  • Serial I/O routines. 

The OS itself will only be mono-tasking, and in fact will hand over all system control to the user program, only leaving behind useful hardware and filesystem routines. For any additional hardware, those will have to be driven by a user program. Upon exit, a user program will perform an additional RET instruction than there are CALL instructions in the user program, to return control to the OS.

As for the file system to be used, I've decided to use LEAN for its simplicity, low storage overhead, and featureset. You can find out more about it here: http://freedos-32.sourceforge.net/lean/

When all's said and done, the operating system should be portable to any processor system that meet or exceeds the hardware requirements.

Comments

Post a Comment

Popular posts from this blog

HP-125 Floppy Drive Emulation

A 'back burner' project I have in mind is to repair an old HP-125 computer I picked up at a thrift shop quite a while ago. This computer has no onboard storage drives, instead coming paired with an HP-82901M floppy drive unit , which communicates over HPIB/GPIB/IEEE-488 (whatever you want to call it). These drives are either pure unobtanium, or are downright bankrupting, so I need to find a way to emulate it. My requirements are as follows: Standalone operation, not requiring another computer to emulate Low cost parts, or using mostly parts I have on hand (Optional) Multiple uses, I don't want this to be a one-trick pony While I've learned how the GPIB protocol works, I have no idea what the command set is that either the HP-125 and/or HP-82901M speaks. I've found mention of the HP-82901M using the Amigo command set, as introduced with the HP-300 "Amigo", on this page about emulating an Amigo-compatible drive with a modern PC . That project requir
1 comment
Read more

Disk Selection

So I've started work on the BIOS-ROM for the Z80-based Zephyr computer in preparation for use with BP-DOS, and I needed to decide between SCSI or IDE for a storage disk. The SCSI disk I have would be ideal on the hardware level, since both commands and data are 8-bit (with hardware generated/checked parity), plus it would make for a nice auditory experience being a full-height 5.25" disk. However, an issue arose when reading through the commands section of the SCSI standard, there are several different bus phases, and the flow path can be quite confusing at times. I'm sure given time it could be done, but I'm interested in getting the Zephyr computer running in a reasonable time frame. Instead, I have opted for using one or two IDE disks, for simplicity of the bus and command-set. Data transfers are done on 16-bit words, so a data read/write takes two input/output cycles from the CPU, and the ordering of which byte of the word will vary between reads and writes. On
Post a Comment
Read more

EEPROM Programmer Pt.2

I have decided to revisit my earlier plan of making an EEPROM programmer with as few I/O pins required as possible. I have decided to abandon that requirement in favor of making something functionally complete with a minimum of software development required. I'm using an Arduino Mega as the programming controller, with the sole reason being the large amount of I/O pins available. Rather than reflashing the controller every time an EEPROM needs to be rewritten to hold a new program, I've implemented a method to send the desired program over a serial connection, and program the EEPROM in 128-byte chunks. This is done via the Xmodem protocol, which allows for a pause between packets to allow time for programming 128 bytes at a time, before requesting the next packet. Due to the variant of EEPROM I have, a 12V level signal needs to be applied to the /OE pin in order to enable a full chip erase. This 12V line will be handled by an opto-coupler, and a momentary pushbutton acting
Post a Comment
Read more