Managed to get the date/time from the I2C RTC. But am still stuck on getting a MAC address from either the RTC or onboard eeprom.

What is this "MAC address" you speak of? I've used I²C a fair amount and never heard of a MAC address in that context, so I looked it up on wikipedia and it also says nothing about a MAC address.

My post was a bit succinct, it may have been unclear to some people.
MAC address not part of I²C . It’s data stored by an I²C memory chip.
MAC stands for Media Access Control. The MAC address is the network address of a device, often an ethernet controller. Each controller has a globally unique address. In order to get an address for the media controller (ethernet controller) in the system one is retrieved from a small eeprom which has been pre-programmed with a unique address as data in its memory.
In my system there are actually two sources of MAC addresses and I can’t get either of them to work.
Without a MAC address it’s not possible to connect to the ethernet. It is possible to manually assign one by hand (hard code it) but it’s better to use a MAC coming from a known source.

Found out why the MAC address from the RTC wasn’t valid. The particular version of the RTC chip doesn’t support a pre-programmed MAC address. duh , upon reading the specs more carefully. The eeprom is still returning all zeros which makes me think the address is wrong.

Added a triple mode redundancy feature to the multi-port memory controller. It may now read and write to three different areas of the ram. During readback a majority logic gate combines the three values read into a single read value.
There are issues with the system crashing due to bad return addresses. The system seems to work intermittently.

Not sure what I’m doing with OS garbage collection. Momentarily I have the JAL and JALR instructions automatically clearing a garbage collect flag in the same manner an exception would clear the interrupt enable flag. With the flag set garbage collection is allowed. The idea is to disallow garbage collection in function prologues because it can create false garbage collection requirements. So, after the prologue is finished the garbage collect flag is set, enabling garbage collection. It works somewhat like an interrupt disable / enable feature as an eret will automatically restore interrupts while an interrupt automatically disables them.
Setting the garbage collect flag after the function prologue is done is done by code emitted by the complier to set the flag.

The TMR memory cycles didn't resolve issues with crashing on bad return addresses.

The latest project revision is to use the Petajon (CS01) processor in an FPGA carrier card mounted on a board that provides svga video and keyboard / mouse ports. I was going to post a pic of the routed board but the colors are garish. So, I’ve been working on designing a circuit board. The board uses an ISA AT form factor. It was a toss up for a while as to what form factor to use. I plan to use the board as the "console" board in a computer.

Still haven't figured out the crashes. Some progress was made by including better interrupt nesting depth checking. If interrupts get nested too deeply they are ignored. In order for this to work BIOS and OS function returns have to be primed by setting the return register value to 'E_TooDeep' *before* calling the function. That way if the ecall fails the return status is sitting in the register.

Playing with the CS01 project. This post is relevant to the small version of the system running on a small xc7a15T FPGA (10,000 LC's) It’s a little further along than some of the other projects and I’ve got into the software for it more. Tonight, I managed to get serial output working using the FMTK multi-tasker. Serial input almost works too. I managed to capture a trace of a serial character input going through the serial IRQ routine and being placed in a buffer. So, the character is in the input buffer, it just a matter of retrieving it correctly. To retrieve a character of input the running app (in this case the monitor) must have the input / output focus. If the app doesn’t have the input focus then attempting to get a character returns a status of none available.

The cpu core has been updated with an additional integer register file for interrupt processing. That makes three integer register files, one each for user mode, machine mode, and interrupts. Having a separate interrupt register file simplifies some of the OS software and greatly reduces the interrupt latency. No need to store registers when an interrupt occurs. And interrupts can occur if the OS is running.

The above code pulls a pointer to the IRQ routine to invoke from the device driver table.

The following is a table of planned device support. 32 devices should be lots of room. Tables which are statically allocated for devices don’t take up too much room.


The following are vector numbers for device operations.

Two SDC cards would be better than two floppies. Front panel is allways handy.

I have to agree floppy drives are outdated. I like your suggestion of a front panel device too.

Difficult to find bug: the serial I/O wasn’t working because the SerialGetChar routine was checking head and tail pointers from user level code. The pointers are located at physical address $9800, $9804. When viewed in the logic analyzer the addresses accessed were $4C00 and $4C04. This had me going for a while because $4C is one half of $98 meaning it looked like the address was shifted by a bit to the right. I spent a lot of time trying to debug where the address was being shifted. Then I finally realized it was likely the physical address assigned to virtual address $9800 in user level code. I switched the code to calling the routine from machine mode and it was fixed. The issue had nothing to do with shifting.

Character input is closer to working. Every third character is recognized for serial input.

IO is so simple without an OS. With the OS in place, the cpu executes hundreds of lines of code to put a character to the serial port. The OS must check that the current task owns the serial port device before allowing the I/O. All the I/O management takes place in machine mode using physical addressing, so user level code can't really access the I/O other than to request access from the OS.

Added a user level CSR to contain the garbage collection interrupt enable bit. For code running at the user level only, a subroutine call will automatically disable the garbage collector interrupt. The interrupt must then be enabled after the function prolog is complete. Enabling of the interrupt is ignored by code not running at the user level. This is so that a routine may be written to operate any level, and it won’t inadvertently enable an interrupt while running non-user code.

Switched from using the subroutine call, to using the addi instruction to disable GC interrupts. This is going to be switched to a custom instruction ‘alloc’ in the near future. The name ‘alloc’ was changed to ‘gcsub’ to avoid conflicts.
Trying to debug what was wrong with the serial routines. There was a constant $F streaming to the serial port. Well it turns out a while ago I put a debug line in to output the hex code of the character of serial input. Turns out it was displaying this correctly as $FF (-1) meaning no char available. It works when there is no char available, but with chars it returns 0 when it should be returning the char code. Don’t know if this is a buffering issue or not.

Mostly more debugging today. Had fun for a bit before I realized that serial port interrupts were enabled. I wrote a little code to peek the serial port and echo it back. Of course it didn’t work properly with interrupts enabled. The receive interrupt would store the char in a buffer then the peek wouldn’t find anything.
Also put a second timer on the via6522 to work as the garbage collect interrupt timer.

More debugging. I found out why every fourth character was ignored by the serial. It turns out that the memory interface module to the static ram onboard was faulty. It didn’t always write out the correct bytes. Strangely, writing out words and some other values worked. The memory interface bridges between an eight bit wide sram and the 32-bit processor bus.

Debugging has been challenging. The system monitor is running as a user app and so doesn’t have access to the OS memory. It’s interesting then to get dumps of OS memory to try and figure out what’s going on. An OS call has been implemented to be able to report the status of PAM bits for instance. I need to figure out how to get the monitor to run at the machine level.