Neotron Pico

You can now buy Neotron Pico boards direct from Elecrow. See https://www.elecrow.com/neotron-pico-rev-1-1-assembled.html.

I also wrote an Amiga ProTracker compatible MOD file player for Neotron OS. See a Neotron Pico playing MOD files here:

Over the past couple of weeks I've been working on SD Card support for the Neotron Pico. The broad schedule ran like this:

1. Detect when a card is inserted into the slot.

2. Detect when a card is removed from the slot.

3. When a BIOS "List Block Devices" API is called, initialise the SD Card and report its actual capacity.

4. Remember the fact that the card is initialised so we don't initialise it again needlessly.

5. Update the Neotron OS so it can read and write arbitrary blocks from disk. Test this using the Neotron Desktop BIOS and a disk image.

6. On the Pico BIOS, support the "Block Read" and "Block Write" BIOS API calls.

7. On the Neotron OS, implement the BlockDevice trait from the SD Card library over the BIOS API calls, and implement a basic DIR command.

8. Change the OS "load" command to load a file from disk into RAM, instead of reading keyboard input.

9. Profit!

Somewhere in there was a step around "re-write the embedded-sdmmc crate so it makes more sense internally, and so it allows you to create a new driver object (unsafely) without rebooting the SD Card".

Right now, I have branches open on three different projects (Neotron Pico BIOS, Neotron OS and embedded-sdmmc) and I need to close them and push out updated versions in the right order, so the next one in the tree can depend on a published version of the previous one ... but if you have all the right branches checked out, you can do something like this:

Now, it's a real computer!

I've spent some time thinking about how to improve the PIO program that runs our Super VGA out. Currently it requires one 16-bit value per pixel, delivered from one of two ping-pong buffers each 1280 bytes long. Loading these buffers with RGB pixels based on characters read from the text buffer takes quite a lot of CPU time. If we limit ourselves to just two colours for the entire screen, we can build a small look-up table and get all 640 pixels drawn into the buffer per scan-line using about 90% CPU at 126 MHz.

My plan was to change the PIO so that instead of taking RGB colours as input, it instead took a series of commands: some commands to load a new colour into the X or Y register, and other commands to just clock out pixels from either the X or Y registers loaded earlier. This used almost the entire PIO memory, but I thought it should work. I coded it up with a pen and paper, and then transferred it to the computer. However, I managed to break something as despite getting a sort-of picture on the screen, most of the scan-lines per missing and the picture was rolling terribly.

I came back to it a day later, and decided to try another approach. On the Monotron, we used a huge look-up table which converted eight-bits of glyph, along with its chosen foreground and background colours, into three eight-bit values for R, G and B. The initial problem with porting this approach is that on the Neotron Pico, instead of three eight-bit values, we need eight 16-bit values (well, 12-bit values stored in 16-bit words). This blows the lookup table from 64 KiB (256 x 8 x 8 x 4 bytes) to 512 KiB (256 x 8 x 16 x 8 x 2 bytes). Plus it would be stored in off-chip Flash which has a big access latency because it's accessed over a Quad SPI interface.

One way to shorten this table would be to use an array of functions, where the functions store the correct pattern of foreground and background colours into the given position in the scan-line buffer. We'd need 256 functions, to cover each variant of our eight-bit input. I tried this, and the performance sucked. It also chewed up so much RAM (these functions are in RAM to avoid that Flash latency) we had to decrease the amount available to the OS. That wasn't going to work.

I also tried a 256 entry match statement, which was smaller, and faster. But still not fast enough.

I then came across an old branch where I'd worked on this problem previously. This used a lookup table containing RGB pixels, but instead of taking eight pixels as input, it takes only two pixels and so four lookups are required. The lookup table needs to be 2048 bytes long (4 x 8 x 16 x 2 x 2 bytes), which we have space for. But does it run fast enough?

No.

Previously I had to overclock the chip to 201.6 MHz (eight clocks per pixel) to get this version to work. But, I have better benchmarking tools now - I output the precise time it takes to complete the render into the scan-line buffer using the dedicated LED on the Pico. Placing an oscilloscope on the LED's control line allows me to measure the time taken using an oscilloscope. As it turns out, winding the clock speed up from 126 MHz (five clocks per pixel) to 151.2 MHz (six clocks per pixel) is just enough to get it done. We're using 90% of Core 1 to do the drawing, but it's stable.

Time for some test code to check all the colour combinations, and a little bit of ASCII art to show off...

Maybe I'll come back to the PIO improvements another day, but for now this is a big achievement. We have full 80 column VGA text mode, in either 25, 30, 50 or 60 lines, with 16 foreground colours and 8 background colours, just like on the IBM PS/2 and other VGA compatible systems. With a simple ANSI sequence interpreter in the OS, the world of Bulletin Board ASCII art awaits!

Also, this is better than the RC2014 Pico VGA Terminal can do (that is currently 40 column colour, or 80 column mono). I've sent them a note explaining how I got it to work. Everyone deserves 80 column colour text on their Pico!
 

The delivery from JLCPCB arrived yesterday (2022-11-23). I did an unboxing video where I soldered up one example, did a smoke test, programmed the two processors and showed we get VGA video output.

Check it out!

I worked on the Neotron BIOS interface this week. I merged a bunch of long-standing changes around sharing a VGA-compatible text framebuffer, and added back in Block Device support. I also updated the Neotron Desktop BIOS and the Neotron OS, so you can now get Key Events from the pix-engine GUI window forwarded into the OS via the BIOS HID API.

I hit BUY at JLCPCB, and ordered:

30 off Rev 1.0.0 (using up all the SMD parts I had pre-purchased and had JLC stash away for me)

25 off Expansion Card Template v0.7.0

Let's hope they work! If you want to buy one, get in touch and I'll see what I can do. Or order your own using the files at https://github.com/Neotron-Compute/Neotron-Pico/releases

You can now apply to be a Beta Tester and get a free Neotron Pico Kit:

Sign up form and terms and conditions here: https://forms.gle/kxvUtNGSfCFAbtvo6

In the last post I referred to some testing of the Audio CODEC using CircuitPython. Here's a video showing the code, with the Neotron audio in the background.

I also should mention that the PS/2 keyboard is being received on the BMC chip correctly, but work continues on getting data from the BMC to the main RP2040. Comms is working, but only at around 1 MHz currently. Here's a video showing programming the BMC, keycodes being sent to the laptop over the debug log, and the PC Speaker doing a short beep for every keypress.

As a bit of an experiment, I thought I'd try loading CircuitPython for the Raspberry Pi Pico onto my Neotron Pico board. Whilst the point of the board is to develop and run the Neotron OS, I found that Circuit Python was pretty useful for developing PCB tests and checking out various bits of functionality. The main advantage was that I could interact with well-tested libraries and not have to wonder if my code was wrong or the PCB was wrong!

Using the Adafruit I2C library I was able to talk to the Texas Instruments Audio CODEC and configure the various volume and audio source selection registers. This then enabled analog 'sidetone' between the Line In and the Headphone Out, so I was able to verify that those paths worked. I then switched to the Microphone input and got ... nothing. Much fiddling ensued to no avail, but when I went to unplug the microphone, I heard it pop into life. It turns out I'd set it up for a stereo microphone (mixed down to mono), whereas the mic I was using was a mono mic with only Tip and Sleeve. This meant the Ring contact in the jack was shorted to Sleeve, which was GND, but my circuit was shorting Tip to Ring - thus Tip was shorted to GND and there was no audio. The workaround to only half insert the jack so that Tip connects to the Ring contact only, and the Sleeve doesn't reach as far as the Ring contact. I'll put a fix on the PCB to take audio from Tip only, and send the 5V Mic Bias signal to Ring - if the microphone doesn't need the bias, it's fine for it to go to Ground. But with the jack half-inserted, we've got a functioning PA system!

The same I2C library was used in conjunction with the Adafruit DS1307 driver, and we can confirm the RTC is ticking away nicely.

Next I turned my attention to the MCP23S17 chip and quickly knocked up a Python equivalent of the driver I'd already written. Once I was happy I was driving the Debug LEDs, I set the chip to permanently select CS1 and then started up the Adafruit SD card library. Happily this was able to not only read directory listings off the card, but was able to do it at 25 MHz! Excellent news.

The final part to test was the expansion slots. I only have one card edge connector installed currently, in slot 3. But I built up a Neotron Expansion card (the template design with no changes) and I was very quickly running a larsen scanner on the expansion card LEDs, whilst simultaneously running a counter on the on-board LEDs. This shows the 3:8 decoder is working, and it correctly isolates bus devices whilst the IO chip itself is updated. Success!

So - to sum up - a small change is needed to the microphone circuit to better support mono microphones, and then I think we're ready to order 25 units of Rev 1.1.0.

The latest rev 1.0.0 boards arrived today. I worked through a test procedure carefully:

1) Visual Inspection

2) Load through-hole components (and VGA buffer JLCPCB didn't have in stock), but leaving out the PSU

3) 12V input at 40mA current limit showed no issues

4) Manually apply 3.3VP to R1303 and check DC_ON pin of PSU header goes to 5.6V

5) Flash STM32 and check we can power on and power off the board (no PSU fitted still) with the button, and that the power LED works

6) Fit the PSU module, check 5.0V and 3.3V rails OK (5.03V and 3.29V)

7) Fit the Raspberry Pi Pico and check the VGA output

Still to do:

1) Talk to the CODEC over I2C and do audio loop-back tests

2) Talk to the MCP23S18 over SPI and drive the debug LEDs

3)  Talk to an expansion card

4) Talk to the SD card

5) Check the PS/2 ports work