6502.org

So I was wondering if anyone ever wrote a BIOS for a 65C816 computer?

Going to finalize the lay out of my board and get them ordered so I'll have them in my hands by the begining of May that way I got my 4 month summer to work on it. And I was thinking of how to empliment a BIOS.

So far the board is still pretty much what I was thinking originally:

STD Card with:

• WDC 65C816 @ 16Mhz
  4MByte of SRAM (10ns)
  32Kbyte of SRAM (in the first 64Kb address range ontop of the above RAM)
  32Kbyte of EPROM (45ns as its the fastest I can find, EEPROM makes it go up to 70ns)

IO Ports:

• RS-232 Serial Port (using the 65C51)
  Parrellel Port (Using a 65C22)
  PS/2 Keyboard and Mouse Ports
  IEEE-488 GPIB Port

It will have a Floppy Drive as well to load programs on after it boots up the BIOS will be able to pull instructions from storage locations such as the Floppy or hard drive (which may just be a bunch of Flash chips onboard to make up a virtual floppy drive, or it may just be a SD card have not decided yet).

I was thinking if I after soldering it all together worked on a BIOS that would boot up the system and then figured out whats onboard and put it into a table in the first 32Kbyte of RAM then programs can just use a standard "look up" for a RAM address where the data stored in it will tell the program where it will find the device.

So the BIOS will in effect allow the software to be run on any computer based on the 65C816 using a BIOS instead of it needing to be recomplied to match the memory and I/O maps of each individual system. As it will deal with the hardware, and then the software just has to run itself using pointers to the addresses stored in RAM to actually input and output data.

Or am I over complecating things?

Dimitri

Basically what you're looking for is a simple operating system.

Consider the Commodore kernals for example. They provided exactly what you want by the means of a jump table below $FFF0 - which were basically the same from the first PET, the VIC20 and C64, up to maybe even the C128. A program written for one of those could - in theory, there are other things to consider which were not take care of by the system calls (like zeropage space, ...) - be run on any of the other.

Will your floppy have some kind of own intelligence? If not, you'd also have to implement some kind of DOS (how are files mapped to disk blocks, file and directory management, etc) into the same address space. Might work with 32k total (to fit in your ROM) though.

André

BTW: the need to run programs on different systems was exactly what brought me to develop my relocatable file format http://www.6502.org/users/andre/o65/index.html - which allows to relocate a binary file when loading into memory. It even features late binding, so you could have a kernal jump table on different addresses in different systems. I used this to run my own operating system on different addresses (e.g. below $8000 on the PET as there is only video and ROM above), while below $FFFF on the C64) and be able to run the very same binary.

André

I have. My POC V1 unit has a BIOS capable of driving two EIA-232 ports, along with a stub to interrogate a SCSI subsystem (under development in POC V2) and attempt an ISL. There's even an interrupt-driven timekeeper in the ROM, along with a 65C816-specific M/L monitor.
Couple of comments:

• EPROM: 45ns EPROMs are usually OTPs, so you might want to rethink that. EPROMs that are truly erasable are rarely faster than 70ns.

• 65C51: Buggy and inferior to other ACIAs. I used the NXP 2692A dual ACIA in my design. Although more complicated to interface to the '816 buses than the 'C51, it has superb performance, easily supporting 115.2 Kbps simultaneously on both ports.

• IEEE-488: Not something I would include in a new design. What exactly do you intend to connect to it? The only widespread use of IEEE-488 outside of test labs was in Commodore peripherals like the 8250 floppy drive.

My opinion is you are trying to be too ambitious for a first system. I suggest that you start out relatively small and uncomplicated, and then add to it as you work out the kinks and get used to how everything functions.

fachat,

Operating systems to me involve some sort of multi-tasking as well at least in today's terms. 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. Quite similar to modern computers, when they boot.

A Splash screen showing the BIOS information, and possible user commands.
http://img.tomshardware.com/us/2007/10/ ... _00ghz.png

Then it loads your IDE drives and then figures out what services are available on the bus as well:


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.

BigDumbDinosaur,

The EPROM are indeed OTP. Trying to go for as stable as a system possible with a 16Mhz or faster clock. Which means cutting down in timing. I figure if I can stay under about 60ns I should be able to hit 16Mhz without issues. The fact that the 65C816 as I understand it when its being fed 5V instead of 3.6V at 16Mhz allows for additional timing tolerances means I may be able to get away with even faster clock speeds.

I will take a look at the NXP 2692A ACIA. Thanks for the tip.

I wanted to include the GPIB due to the fact it worked on test equipment. Before coming here I was quite interested in the old HP calculators, and calculators such as my HP-41 allowed access to the GPIB which is why I wanted to include it on a 65XX project. You can even by brand new Oscilloscopes and the like with the GPIB on board. Its a older standard but not a dead one. Similar to RS-232 being probably the oldest standard still in use but still just as effective.

As for the systems over all complexity, I want to get the PCB boards made up, so I figured if I went big, I can work out problems as they come with the boards, then make new boards every time I want to add a extra feature. Initially I'd get the system working, then add to it (such as the BIOS). But clear defined goals are generally what I need to stay on track. Updating a design constantly ends up putting me in a endless loop of not getting it done cause I am always debating what I want to update next.

Dimitri

I might say "quirky," not "buggy." I've used it for decades and it has always operated the way the data sheet says, and there has never been a problem. The only one rated for more than 4MHz though, and the only one in production today (or preliminary production) is WDC's, which does have a bug in the even parity IIRC-- but who uses parity.

The MAX3100 14-pin-DIP SPI UART would go well on the 65SIB. It doesn't have RI and DSR and DTR like the 6551 does, but it does have 8-byte buffers. If you had to have those signals, you could do them with VIA bits.
There are thousands of models of lab equipment with IEEE-488 though, and they will remain alive and in use for probably decades more.

Okay, "quirky," as well as lame.
Multi-drop rigs use parity all the time. In years past, I used to do that sort of work, mostly RS-422. Parity was essential to detecting data collisions.
If the plan is to connect to a modem, at least DSR and DTR should be present. It seems almost counterproductive to use the MAX3100 and then have to provide additional silicon to provide some key handshaking signals.

As for RI, I seldom see that being implemented anymore, so its omission is not all that serious. I have a Courier modem attached to one of the serial ports on my UNIX box and it works fine without RI being connected. However, the server uses DTR to tell the modem when to disconnect (e.g., following carrier loss). Without DTR, the OS has to command the modem through the +++ escape sequence, which is not particularly reliable.
I'm well aware of that. However, I wouldn't go to the trouble to implement IEEE-488 unless I had a specific need to connect to an IEEE-488 device. It's a very old standard (although a robust one) that, like floppy disks in PCs, is fading away due to declining usage. For a first system, it seems a bit much.

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).
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.
BIOS doesn't handle user commands; that's a monitor's job (also known as a "shell").
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.
And, you don't need a BIOS for this to happen either -- 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.
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.

Some remarks on that: PET kernals for BASIC 4 introduced some mixture with the BASIC code to accomodate for the new disk commands (calling BASIC parameter parsing from KERNAL code ugh...), so I'd recommend KERNAL for BASIC version 2 (there wasn't any version 3). But here the C64 KERNAL is better separated from the rest of the system (the BASIC) and has IIRC some of the jump table entries cleaned up. You'd have to replace the serial IEC of the C64 with the PET's parallel IEEE488 routines though (which is another sign of how versatile the Kernal is - you can exchange all that "under the covers", been there done that...)

But noone keeps you from taking the best of both worlds, or from just taking the concepts and implementing it yourself.

André

Multipul drops on the RS-232 to detect collisions doesn't seem like something I will need. Cause it will probably only be used to interface to one device. Actually, never knew you could interface to more then one RS-232 device with one port.

BDD,

No specific need now for IEEE-488, however, the addition of a couple of spots on the printed circuit board doesn't seem like a big issue till I get around to making it work. As a hobby computer, the costs can't be sky high. So by building in enough hardware features to not require as many future rebuilds of the hardware, my costs drop to the initial PCB and componate costs and then my time to impliment the features as time progresses.

Kc5ja,


You make valid points as to why a BIOS and OS are similar in nature. I thought about a ROM resicident OS, but figured I'd settle for a BIOS, cause as BDD said, this has alot of features for a first project and getting a working system over the summer will be the goal. Fancy items like real DOS on ROM will be future upgrades. Eventually I want my STD Bus computer to with the original Apple IIGS computer. GUI OS, with a few features on it, such as ''fake'' 3D graphics. Cause I figure if they did it with much less RAM and CPU speed, why couldn't I in time.

I will also be using Forth on this 65C816, Garth made a very good case for it. And I will stick to it. Cause it will be nice to learn another programming languge.

Andre,

Your project files have been were many of my ideas have come from. Actually the schematic for the floppy drive that provides a parrellel port that I am doing is a copy from yours. I thank you for sharing the information.

Dimitri

Usually not done with EIA-232, more often with EIA-422 or -485. However, EIA-232 line drivers are certainly capable of pulling the lines one way or another, so EIA-232 can be used as a crude sort of network.
Running an OS out of ROM will limit your system's performance, either because you have to constrain the clock or wait-state every ROM access. If it were me, I'd use the BIOS to get the system on its feet (like what happens in modern servers and workstations) and then load the OS to RAM (from disk perhaps) or copy an OS out of ROM to RAM. Currently available SRAM is very fast (10-12 ns in many cases) and easy to interface to the 65xx bus, which would work nicely with an '816 cranking at 20 MHz. The best you can probably do in ROM is 45 ns if you use OTP. Regular EPROMs or EEPROMs are seldom faster than 70 ns. On my POC unit, I use a 70 ns EPROM and the fastest I can run the system with reliability is 10 MHz. Beyond that the EPROM can't keep up.

Yes I did not plan on running any OS at real time from the ROM but the OS would clean boot similar to Linux Live CD's. They load themselves onto ROM but everytime they boot they have a fresh image inserted into RAM which makes it well suited to prevent malicous code attacks from taking over the system as every reboot reloads a original OS.

But I'd like to contain as much as possible on the 32kbyte ROM that will allow me to get different programs running which is the end goal os any computer to become 'useful'.

If I do get to the stage I have a GUI, then I will need to load the 'real' OS above what I want in a BIOS from disk or perhaps flash memory.

Dimitri

I partly agree with you. I personally would use as less as ROM as possible. If it was possible, I would just use enough that it could contain the Boot Loader. The Boot Loader loads the BIOS. The BIOS then loads the OS.
The Boot Loader is hardware dependant, but only for one source (most likely an hard disk). The BIOS is hardware dependable as well but because it resides in RAM, it is better configurable then the BIOS of nowadays PCs. The BIOS is bound to certain rules of course. I would make use of a prooven concept: vectors. It is used in CP/M, DOS and by Commodore. The OS should be completely hardware independant.
If this all sounds familiar, it is. This idea is based on CP/M 3. Here the ROM (= BIOS) copies itself to the top of the memory and loads the rest. Because it is situated in RAM now, it can be altered. My idea: if it can be altered, why not load it instead? :)

As I said, I partly agree with you. You are right about the performance but the ROM can be mirrored into RAM and then replaced by this RAM: speed problem solved.

This is how the Amiga 1000 worked. The chip foundry couldn't supply the Kickstart ROMs in time for market delivery, so they altered the circuit to use WOMs -- ostensibly "Write"-Only Memory, instead.

A WOM is basically just a RAM with a gate on the WE# pin. When RESET# is asserted, this gate is opened, allowing the system firmware to load stuff into it. Then, after the CPU accessed a certain memory location, the gate was forever closed, thus allowing the system to treat the RAM as though it were ROM.
There are two other wonderful features of this too, which often gets overlooked:

1. You can bootstrap the OS from a serial EEPROM, which are much easier to program and much cheaper to acquire.

2. You can use a relocatable binary format, allowing you to re-use the same BIOS (or OS) image at different locations in memory, depending on your hardware's specific memory map.
You in fact agree 100% with BDD, because if you read above, this is what he suggests doing in the first place.

The reason I would only party agree is because we're used to ROMs with stupefyingly slow access times. This needn't be the case, of course. A dedicated mask-programmed ROM can be made quite fast, and can (in fact) probably handle several tens of MHz if engineered correctly (e.g., instead of one monstrously huge matrix, the die would contain many smaller matrices, which decoding logic would multiplex depending on the high-order address bits; this kind of partitioning is how CPLDs attain much of their speed, for example).

The ROMs in the Amiga 2000 and 500, for example, could handle 8MHz 68000 bus accesses without any slow-downs.

Actually, you completely agreed with me. My earlier suggestion was to copy the required part of the ROM to RAM and run in RAM only. In the PC world that's referred to as BIOS shadowing.