Worked on the Femtiki OS. Current build of the kernel (non-working) is less than 64kB code. Data is much larger. Data is mostly pre-reserved areas for things like application and task control blocks. Had to write some routines in assembler that I would have preferred to write in C but it turned out to be more difficult to code in C.

Cannot find the putnum() routine. It is not anywhere on my machine or in version control. It has disappeared. Sure I can re-write it, but it is a curiosity. I am tempted to get out old PC's and see if it is still present on them. It is like it has been scrubbed, Mandela effect. The RAM test routine and other functions used it.

I recreated putnum. It likely got lost due to a hard drive crash, or moving data from one PC to another. The last time I copied a PC, the copy only got to about 90% complete before aborting. Since there was not an easy way to tell which files had not been copied, I decided to go with it "as-is". Occasionally, I find something that did not get copied, but I still have the old PC.

Worked some more on the OS. Found a very old copy of OS routines, which was good because several missing files now had a starting place. I never get much past the task switcher, and the additional routines move past that point.

Decided to use a whole page of memory (16kB) for the environment block of an application. The OS currently only allows 32 active apps. Each application chews up a lot of memory. Building up the OS seems to be a bit of a chicken-and-egg issue. Some parts seem interdependent.

Slowly whittling away at stubbing out routines that should not be needed to boot the OS; they can be filled in later. Taking some side-tracks to support read() and write() of at least the text video screen and keyboard. Changed some of the device driver operation numbers.

Changed the MMU. It no longer is enabled on an app (pid) basis. Instead, it is either enabled or it is not for all apps. Also reduced the number of apps supported in the MMU to 1024 from 2048. The difference is only a single block RAM is used instead of two. Since the OS is
supporting only a handful of apps (32) running at the same time this is not really a limitation.

Switched the processor to a 68010 from a 68000. This was to allow writing to alternate address spaces with the MOVES instruction. Makes it a little easier to support the OS with a MMU. Whenever the app passes a pointer to the OS, the OS needs to be able to access memory according to the apps memory mappings. This is where the MOVES instruction comes into play. Otherwise it would be necessary for the OS to translate the addresses and it would be quite slow.

Put reverse byte order logic into the MMU. Plan on removing it from all the I/O devices.

Moved constants for variables to variable declarations in Femtiki_vars.x68.

Changed some branches to jumps as the code expanded beyond 32k limits.

Having fun with makefiles and linker scripts.

Monster software update, but it does not seem to have broken too much.

The system is now running a 68010 compatible CPU. Interrupts, which were the biggest change from the 68000, appear to work. The 68010 stuffs an extra format word onto the stack for interrupts. The interrupt sequencing is a little different from the 68000.

Moved the device driver code into the Femtiki source tree. Changed the way device handles are interpreted. The device control block number is now in the upper 16-bits of a handle, and the unit number is in the lower 16-bits. This was to accommodate devices that could have multiple units available at the same time. For instance, the text video display supports up to eight screens meaning it can be opened up to eight times. Previously the device control block was specified in the handle. The change was needed for file system where some disk type devices may have numerous files open at the same time.

Finally got Femtiki to build but have not tested yet.

Things are slightly broken again at the moment.

The system can be seen booting, it clears the screen, displays bootup messages, then the text screen is turned off. No idea yet why the screen disappears.
There were modifications to the text screen driver to support multiple screens. Each CPU core has its own local copy of text video driver information.

Working to get rid of the buffers and position information in the device control blocks. That information does not really belong there. That should reduce the size of the control block to 64 bytes.

Photo of the system boot gone wrong. Bootup triggered the graphics accelerator text-blit function for some reason, causing randomly formed characters to display. Looked like some sort of alien message.

Time to add some Evil music and play space invaders.
It might be wise to use 128 or 256 bytes for all control structures for the simple reason
malloc and free are are simple for kernel usage.

Most of the control structures for the OS are statically allocated ATM. Once it is confirmed that malloc and free are working well, that will change. The control structures are also power-of-two in size.
I put a lot of the OS vars in a shared SRAM. The larger structures have DRAM allocations.

Added request and response OS calls to support services. Also added a couple of OS calls to register and unregister services.
Spent a little bit of time tracking down where the screen disappears.

Added some more routines to the mem management code.

The OS is kind of a mash-up of several operating systems. Its intent is to be message based. One of my favorite operating systems books had a simple implementation of a message-based kernel. The book disappeared shortly after I moved. The KMOS kernel in Milenkovic’s Operating System and Design was studied, which IIRC is message based. Studied the MMURTL operating system which is also message based. Brief forays into studying Linux and other systems like Minix. Then there is Windows.

Never did figure out why the text screen was disappearing, but it does not disappear anymore. Now the monitor program crashes once return is hit on the keyboard, it is almost working again. Startup messages display okay, the prompt appears, and keyboard input is accepted until the return key is pressed. <- Figured this issue out, a couple of function pointers were swapped in a table. The wrong routines were called.

Here is a bad photo of the triangle test. The bands on the photo are not present in real life, it is due to the camera and image compression.
The triangle display looks like it is not writing every pixel of a triangle. It is surely reading the memory correctly as if the reads were not working, the display would have more of a snow effect to it. The display is solid, but it is missing pixels.

Quit reading books I can't find, or use.
I need to find pre-unix stuff, simply because I have only 18 bit addressing

What are the advantages of your implementation over real 68000 hardware?

You could go like the early micros and incorporate ROM BASIC or some other interpreter. It almost provides a command shell. There are some commercial micro-kernel OS that use only a few kB, so it must be possible to develop a small OS. Femtiki looks like it will be using about 64kB 68k code for the kernel.

Advantages over real 68000:
- It is more flexible. Easier to customize. For instance, the core has tick count, process id and core number special registers.
- It is likely faster. It is running at 100 MHz.
- Electronic waste reduction. The same FPGA board can be used to experiment with different systems. When finished with the 68k project, there’s less to dispose of.
- Maybe less expensive, amortizing the cost of the electronics over multiple projects.

The OS trials begin:

First trial run of the OS kernel: crashed right away. The vector for the OS dispatcher was not set.

Second try: appeared to do nothing when triggered from the monitor’s FMTK command. Returned to the monitor without a crash, but is it working or not? Added startup messages to the initialization.

Third try: Displayed startup message. Then appeared to return to the monitor. Not sure if it is running or not. The first thing it does is set interrupt vectors for Femtiki. If it did that then the at least the timer routine must be working.

Wrote a couple of routines to dump the app and task lists.

Femtiki is displaying startup and end of startup messages, but it is not displaying the test messages appearing inbetween.

Trial run 5: Dumping the apps and tasks did not work. Crashed. The DisplayStringCRLF() function was not prototyped correctly.

Trial 6: a carriage return/line feed was missing off an assembler line causing the next line to be ignored. This was to set the IRQ vector, which was not being done. Dumping apps did not crash, but displayed an empty list. Dump tasks displayed an empty list then crashed.

Added a NACK state to the WISHBONE to FTA bridge. The NACK state waits until the WISHBONE request is finished before negating ACK. Previously it was just assumed that the WISHBONE request would finish when it saw an ACK.

Changed the video timing to 72 Hz vertical to try and improve the display quality. 800x600 72Hz uses a 50 MHz dot clock which is exactly half the system clock frequency. The 60 Hz timing used a 40 MHz clock. Changing the clock made the display worse.

Added a PLL to the system to generate the five-times video clock. Previously an output of the clock generator was used.

Added a two-stage synchronizer to the hsync signal transferred to the bus clock domain. It looks like the display is not synching properly to the horizontal sync.

Modified the bootup to start Femtiki automatically. Things are completely broken now. Hoping to at least get a clearscreen and startup message with the next build.

Is the video logic correct after synthesizing? Something might be reduced out.

The sync generator, which is part of the frame buffer, is okay. The text video display works fine. It is just the bitmap display that is messed up. The bitmap display is controlled by the frame buffer. It is working a bit better at the moment. The display is stable again.

The toolset is very good at removing only the logic that is unused. If there is an unused output for instance, the toolset will remove the driving logic for that output.

It is difficult to see what is happening by looking at schematics generated by synthesis. They are just too complex, and look like a mess of wires. Occasionally, I will call up the schematics and trace signals, but it is time consuming. I can often resolve issues using other debugging techniques.

Tweaked the memory controller.

Tweaked the WISHBONE to FTA bus bridge, returning an ACK signal one cycle sooner for writes.

Added a device discovery black box to PS2 keyboard controller. It was less difficult than I thought it would be.

Reset the entry point for boot-up back to the old entry point. There are now two entry points, one for the system monitor, and the other for Femtiki. The system is not as broke as it was yesterday. It can get the point of being able to type commands at the monitor prompt. Trying to run some graphics routines causes a crash.

Bug Fixes
Trace mode in the CPU core did not work properly. A flag was being set and never cleared. This interfered with proper operation of interrupts. The trace feature was added to the monitor program. It is now possible to single-step through code. I had been meaning to add trace mode code for a while.

Changes
Moved the device discovery boxes from $D0xxxxxx to $F0xxxxxx to provide more contiguous linear address space for kernel mode.

Switched the MMU to use 8 kB page tables, it was set for 16kB tables. The issue that cropped up was the initial page tables and system page directory are stored in dedicated block RAM. 16kB tables were too large. About a half dozen tables are needed to get the system going. Going to 4kB tables was considered, but that requires more page tables, not really reducing the amount of BRAM needed. It also increases the size of the page directory.

For 32-bit virtual addresses, the page directory requires only 256 entries making it 1kB in size. It turns out to be 2kB in size as a shadow area is used to store the linear addresses of the page tables for the corresponding physical addresses.