Can you bootstrap over the network?

If you mean like over the internet, no, not yet. I would have to write a stack for it, and get a ethernet controller working. I have tried several times to get a working ethernet controller without success.

All the cores boot into a simple command shell resident in the 32kB ROM.
Here's a summary of the commands:

It's alive. I got the screen to clear and it displays the startup message. The timer interrupt appears to be working too.

I like it!

what is the Femtiki OS?

It is the 'Finitron MultiTasking Kernel" (FMTK). A simple OS I have been working on and off for a while. Mainly it is just whatever I call the boot program

A couple of mistakes in the previous diagrams. The shared node memory is 128kB not 32kB. The ager circuit is shown before the system; it is actually after, either the last node in the loop or the first depending on how one wants to look at it.

Things are broke at the moment....

Using Alt-Tab on the keyboard switches between the cores. Each core has its own video display and keyboard buffer. Alt-tab does not work quite right, it switches between the cores too fast, so one can see several screens in succession. I think it has to do with which core is buffering the keystroke.

The video display buffer for a core is 16kB. They are spaced out evenly in the text video memory. It is just a matter of changing a pointer in the text controller to display a different core screen. The text mode video controller has 128kB text video memory, enough for eight cores.

DRAM is not working yet. Running the ‘TRAM’ command hangs the machine. The dram controller never gets out of the RESET state. <- I changed the address of the DRAM to account for a larger memory, but forgot to update the select logic in the network circuit.

TinyBasic works!

Updated the NIC (SoC network interface circuit) to handle requests and responses simultaneously. Previously it could not handle a request and response at the same time. The update split the internal state machine into two separate state machines.

Things are broken at the moment. I have been fixing things up so that characters getting missed on cores other than core 2 do not get missed. About every fifth or sixth character output gets missed. I think this occurs because write updates are happening too fast. SO, I put in a software solution to delay a few cycles after an access to the global system resources.

> TinyBasic works!

A milestone - congratulations!

With floats even!
The port of 'TinyBasic' with floats was mostly adding fadd,fsub,fmul,fdiv instructions in places where regular integer instructions were. IIRC both integers and floats are supported.

Well, the multi-core works a bit better. The missing character intermittently seems to be fixed. Cores 2,4,5,8,9 appear to work while cores 3,6,7 crashed while clearing the screen. I changed the noc (network-on-chip) to use synchronous writes instead of posted writes. Synchronous writes wait for an ack back from the device before proceeding and are hence much slower than posted writes which do not wait. However synchronous writes occur in-order. Asynchronous (or posted) writes might write out-of-order if the write cannot be performed and it loops around the network. Synchronous writes still loop around the network, but the CPU is stalled until the write succeeds. If the network is busy, eventually all the CPUs will stall until something succeeds.

Running the ‘TRAM’ (test RAM) command still hangs.

The CPUs can access global system resources. The keyboard, timer, interrupt controller, text video and scratchpad RAM all seem to work. But the DRAM does not! It almost works. The memory request makes it out to the DRAM and DRAM responds but the memory controller is not generating a proper ack signal.

The system cache in the memory controller was seriously messed up. It was not converted to the 256-bit bus width needed. It was only 128-bit causing issues.

The DRAM channel’s command signal was not set. This signal is not used by other devices in the system. Other devices just look at the write enable (we) signal on the bus, but the DRAM controller looks for a LOAD or STORE command for the command signal. DRAM looks at the command signal as other commands are possible such as read-modify-write atomic operations.

Some progress on the DRAM front. The dump memory command almost worked. Dumping DRAM memory worked for about the first 2kB of memory, then the scrolling dump hung. I do not think it was the DRAM access, but rather other issues with the system. I tried subsequent longer dumps and they worked. The system seems to hang intermittently.

Write updates to the DRAM hang. The CPU is not getting an ack back.
Almost there!

Successfully wrote a couple of bytes to DRAM using the memory edit command. the system is using an earlier version of the memory controller (MPMC10) from a couple of years ago.

Got the RAM test routine happening. It takes a long time to test 1GB RAM using a 20 MHz CPU. The pointers to the DRAM test routine were only word pointers and the test routine is outside of the first 32kB of ROM. A long pointer was needed. -> A software issue.

Found a bug in the rf68000 which surprised me. The z flag was not being set for byte sized operations with the SUBQ/ADDQ instructions. When I checked the code, the flag update was commented out. I am not sure why. This bug showed up when disassembling lines of code. The disassembly was incorrect.

Ported over the disassembler from Tutor with suitable changes.

Forgot I added some string handling to TinyBasic. It is possible to assign strings to variables and concatonate strings with the '+' operator. IIRC there are also local variables, but I have not delved into how they work.

Building the system with four cores instead of eight to reduce the build times. It also improves system stability.
Made all cores the same, all with decimal float support. Previously only supported on the first two cores. Using decimal floats on the other cores resulted in an illegal opcode exception. Not so good for trying to run TinyBasic.

Added support for IPI (inter-processor-interrupts). An interrupt can be triggered now by writing a certain location in the global address space with interrupt info.

Thinking about extending TinyBasic to support a global address space in addition to the local address space. Routines and data could be implemented in the global address space. The local address space is very limited.

Updated the software to use a device driver approach. First test writing to text screen via driver instead of direct writes.

Pondering how to save / load TinyBasic or other programs. I would like to use a flash drive with a simple file system.

Simple file systems no longer exist.
I have been looking for one for years, to port to my computer.
When one had simple operating systems, they just had floppy drives or DEC tapes so you had
to shoe horn in your DOS and swap like crazy. Then add in time sharing like TSS/8.
It only worked cause IO was still 10 cps TTY's.

CP/M has been ported to the 68000 so that may be your best bet.

I made a simple file system a while ago just to get basic loading and storing of software. I defined all files to be 64kB in size. And they were positioned according to the position of the filename in the directory. First file was at $10000, second at $20000 etc. It was really simple but wasted a lot of space. It is not too bad to come up with something really simple. But, if one wants directories and folders and disk caching it gets complicated real fast. Recently I have been relying on the serial port to transfer files between the SoC and a PC. Using the PC's filing system. Pondering using a RaspberryPI for disk storage. Reminiscent of the DOS built into the Commodore disk drives. Putting the file system on the drive itself is an interesting option.

Worked on the video frame buffer. The version used in the SoC appeared not to work. The first issue was the cycle active strobe was not active when it should be. This seems to be a timing issue in the core. Rather than activate it in a single trigger state, it was made active in the waiting state too. With that change the cycle active strobe was active. Screen displayed a noisy picture that looked a bit like a rolling display. Examining the response from the memory controller revealed there was no ack pulse coming back from the memory controller. This led to bus timeouts after a long time, resulting in video display issues.

After spending hours debugging the frame buffer, I decided to use a version updated for the FTA bus instead. That version did appear to work when last tested. So, in the SoC bus bridges had to be built to convert the CPU’s WISHBONE bus to an FTA bus.

Also upgraded the SoC to use MPMC11 (multi-port memory controller) which is structured a bit better than MPMC10. It is also capable of higher-frequency operation. However, it has not been fully debugged yet. Debugging the memory controller was on my todo list.
Changes have somehow affected the keyboard controller, so keyboard input is not working right. More debugging...

I'd be interested to know a little about the features in your memory controller - and perhaps also the not-features, things you decided not to include.

The controller is complex; a short book could be written about it.
Philosophy: include as much as reasonably possible, then provide ‘configure out’ options.

Some of the features:
• Interfaces to vendor’s MIG component.
• Up to 8 channels (not all need be present)
• Independent clocks for each channel (asynch).
• Configurable fifo or cache access for each channel
• Channels are 256-bit wide
• System cache (128kB) is 1024, by 256-bit cache lines, four-way associative
• Optional support for read-modify-write cycles to support atomic memory operations
• Async input fifos for all channels.
• Performs one write cycle or cache miss load cycle at a time (there is only one port to DRAM).
• FTA bus interface

Some features left out:
• Configurable channel widths
• Support for multiple write ports on the cache
• Larger system cache
• Bus interfaces to other standards
• Interfaces to other memory components
• Error detection and correction

Before I put together the memory controller, I searched around a bit for something that would work, before deciding to roll my own.
For instance, the vendor supplied component did not allow independent clocks for each channel. Which meant externals fifos and clock domain crossing logic would be needed. It would also require the bus standard in the SoC to be changed, a non-trivial update.
The controllers I found did not have independent clocks, I am not sure why. For instance the CPU may only run at 30MHz while the video frame buffer runs at 100 MHz. Forcing everything to operate at the same clock seems pretty restrictive.

Configuring for stream fifos or cache access is partially due to the small cache size. To prevent the cache from becoming polluted with stream data, stream fifos are provided. For instance many video displays require more than 128kB memory. The entire cache could be filled up with video data which would slow everything else down. If the cache were large (mega-bytes) and multi-way associative the streaming fifos likely would not be necessary. They are an option.

I left out configurable channels widths. It would complicate things and make it necessary to modify the controller for different designs.

Multiple write ports on the cache would increase the amount of resources required to implement the cache considerably.

Interfaces to other standards is more of a time restraint. It would take development time to implement and verify.

Impressive and interesting!

One thought: do you have a write queue, and can reads snoop on entries in the write queue?