neotron-compute/neotron-book

A user manual and technical reference for the Neotron family

neotron-book's Issues

Add a CPU

In the working branch I haven't yet pushed, I list other CPUs that might make good Neotrons. The new STM32H730ZBT6 should go on the list:

• LQFP144 package - so only need capacitors on the top side of the board
• Supports HyperRAM so can easily add a 24-pin 8 MiB HyperRAM
• Only has 128 KiB Flash, so is quite cheap (it seems the Flash is the expensive part) - £5.87 in one-offs at Digikey

Chip: https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32H730ZBT6/497-STM32H730ZBT6-ND/13171207
RAM: https://www.digikey.co.uk/product-detail/en/cypress-semiconductor-corp/S27KL0641DABHI020/428-3856-ND/6563034

Only does USB Full-Speed, but you can pin out an RMII PHY interface and 18-bit RGB and I2S audio, plus the usual stuff.

BIOS should be code page agnostic

Functions that return strings should be ASCII only.

The docs for setting a font should note that no particular code page is supported and that it is a function of the font. The only limitation is that the code points are 8 bit, for memory reasons. Although I guess a BIOS could offer a UCS-2 or even UTF-32 text buffer of they wanted to? How does XTerm et. al. store a grid of Unicode characters, handling accents and other modifiers?

We should also add support for enumerating and selecting hardware fonts, as well as passing in a soft font.

BIOS API as a trait?

If the BIOS was a crate, you could compile the os and the bios together. You could then use the full Rust ABI rather than having to use a C ABI - e.g. closures for disk access.

The BIOS API becomes a trait.

Alternative for device paths

Other Systems

MS-DOS has device paths like COM1, CON, LPT1. These files work in any current directory. MS-DOS also has drive letters, giving paths like C:\DOS\HIMEM.SYS.

UNIX has device paths like /dev/ttyS1, /dev/tty, /dev/lp0. These all have absolute paths within the common POSIX file hierarchy, and POSIX has no drive letters - filesystems are mounted into the hierarchy somewhere (e.g. /home/jonathan/file.txt).

Neotron Currently

The book currently proposes drive names, like work:/documents/file.txt. It also proposes to use the drive names to indicate devices, such as com1$baud=115200:.

On reflection, these complicated drive names are somewhat undiscoverable. You could have a DRIVES command which will list the known drives, but you cannot exhaustively list all the properties available for each of them.

Some alternatives

Option 1: A MODE command.

Go back to relative MS-DOS style device paths, or place all the devices inside some DEV: drive, such as DEV:lp0 and DEV:com1. Parameters are set for any given device through the use of a MODE command, such as MODE DEV:com1 baud=115200 parity=N stop=1. Now the devices are discoverable (DIR DEV:) but the properties are only discoverable by running the command MODE /?. Additional devices will require an update to the MODE command to support their properties.

Option 2: A sysfs style tree

Adopt the Linux approach of having properties represented by files within a virtual tree. For example, DEV:com1/ is a folder, and within it DEV:com1/baud is a file. You can read the file and get 115200\n, or you can write a string to that file to change the baud rate. The device itself would be DEV:com1/device. Now the devices are discoverable (DIR DEV:) and also the properties are discoverable (DIR DEV:com1/).

Disk access

In 5d885cd I took out disk access from the BIOS API. On reflection, I think that might have been a mistake. This is because:

• Some BIOSes will load the OS from disk, not find it in Flash. Therefore some BIOSes need disk access routines anyway.
• Putting disk access at the OS layer makes the OS care whether you have SDMMC interface or an SPI interface to your SD card.
• Putting disk access at the OS layer means the OS doesn't know how to read a Compact Flash card, or an IDE hard drive.

Basic enumeration of fixed and removable disks seems reasonable, along with functions to read/write 1 or more 512 byte sectors seems quite reasonable. Limiting to 2TB per device (2^32 sectors of 512 bytes each) also seems fine.

The downsides will be:

• Your BIOS will need a way (e.g. a BIOS set-up program) to specify where the SD card lives and how many you have. Press F10 on boot!