Dimitri wrote:
Operating systems to me involve some sort of multi-tasking as well at least in today's terms.
An operating system is actually a collection of programs which, together, lets the user operate the hardware (hence its name). BIOS is just one component of an OS.
Other names for BIOS include HAL (Hardware Abstraction Layer).
Quote:
You'd have to send a "reset" signal in your program to boot back into the BIOS to get a new program running in my mind.
There's no reason for the reset. The only reason you need a reset signal is because modern, memory-protected OSes prevents user-mode applications from directly jumping into BIOS services. For example, on a 6502/65816 system, you can just JMP ($FFFC) to reboot the whole machine.
Quote:
A Splash screen showing the BIOS information, and possible user commands.
BIOS doesn't handle user commands; that's a monitor's job (also known as a "shell").
Quote:
Then it loads your IDE drives and then figures out what services are available on the bus as well:
Not always. See CP/M for an example BIOS which didn't enumerate anything. And, see Tandy 1000 computers for an example which had MS-DOS in ROM, and thus never booted from any storage device.
Quote:
And that information goes onto a table in RAM to allow the software to be written without prior knowledge of the system for the program to run.
And, you don't need a BIOS for this to happen either
![Smile :-)](./images/smilies/icon_smile.gif)
-- see the Commodore-Amiga for an example where the most of the OS was packed into ROM, but yet still satisfied hardware-independence so well that it took Microsoft another 12 years to compete reliably with Amiga's "AutoConfig" system, and 10 years for Intel to catch up with the founding of the PCI SIG. Apple and IBM was also late to the party, with the release of NuBus-based Macintoshes and Microchannel-based PS/2 machines each a few years after the introduction of the Amiga.
Quote:
I wanted to include the GPIB due to the fact it worked on test equipment.
You
Definitely want to review Commodore KERNAL then. By way of analogy, if in Unix everything is a file, then in KERNAL everything is a GPIB device. I recommend studying the original PET KERNAL though; VIC-20 introduced a lot of non-I/O-related calls which only confuse the system. The C128's KERNAL is monstrously huge and almost entirely hardware specific. The PET is nice, clean, hardware-independent, and predates all the functionality of Plan/9 (even if Commodore didn't realize how powerful the kernel was).
To give you an idea of how accessible[1] it is, I added a GPIB pseudo-device (#255) to implement a hierarchical filesystem just like in QNX. Device drivers would "mount" at specific spots in the filesystem tree, and handle I/O requests on behalf of the calling program. I never finished it, but I did get the proof-of-concept working under the Commodore 64's KERNAL. It should work similarly on a PET too.
I think that a good approach to writing a BIOS for your system, if you cannot find one already in existence, is to port a Forth environment to the hardware. Then, rip out all the I/O functionality of the Forth environment and refactor it into a separate chunk -- that chunk forms the minimal BIOS you'd need to get the system booted into a usable environment. You don't need to stick with Forth afterwards -- just use Forth as a means to discover what's needed as a basis.
_______________________
1. Note I didn't say easy to expand, however. KERNAL is definitely extensible, but sometimes you have to jump through a few hoops to get it to work as you expect it to. If you do decide KERNAL is nice enough for your needs, you can always fix it later on to not require such hoop-navigation.