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?