Cooperation on retro core infrastructure

[harbaum]

I'd like to suggest that we cooperate a little bit on the infrastructure side. With infrastructure, I relate to everything but the (retro) core itself. IMHO a unified nice framework using the hardware present on the Tang Nano 20k to provide various generic services to the core would be nice.

My suggestion would be to add common services like USB mouse, keyboard, the various joystick interfaces, HDMI, the SDRAM, the flash ROM etc etc and to make sure that the next core developer can also simply re-use these. Somewhat like the MiST and MiSTer frameworks do, but for now more Tang Nano specific.

The difference to MiSTer is, that there is not full Linux in the background and the difference to the MiST is that the MCU on the TN20k is way more powerful. The minor differences are that the e.g. the SD card is connected to the FPGA and not to the MCU which makes interaction between SD card, MCU and core a little different.

[rog77]

@nand2mario has done good work with the TN20k, and also seems to have contacts with sipeed - if the three of you had a unified project, sipeed it a lot more likely to release the firmware for modification, or maybe even offer any updated version by default if it didn't interfere with ordinary operations. ETA: I know nand2mario is also interested in loading bitstreams from sd/usb using only the onbaord mcu as they have it as an open potential enhancement issue, referring to a thread I started on reddit.

[nand2mario]

Sounds good. One thing is they mentioned they plan to add the ability to switch among multiple .fs images to the firmware, stored in the flash of BL616. That may be useful to core developers. Presumably they should be open to concrete proposals on how things should work technically.

[nand2mario]

Also I'm wondering if usb_hid_host would be useful to this project.

https://github.com/nand2mario/usb_hid_host

[vossstef]

sorry didn't found time yet to reply yet to Till's original note. I think indeed a very good idea to define a Tang specific infrastructure with OSD and the usual needed stuff as outlined above what all the different cores need.

[harbaum]

The usb_hid_host is really cool and makes much sense if one needs a simple USB HID interface. IMHO it comes with a few disadvantages like the fact that it uses up FPGA resources while the same functionality can be had in the BL616 bascially for free (at least with respect to FPGA resources). But having it as some kind of option selectable by a core developer sure makes sense.

With the MiSteryNano/Atari ST core I am pretty close to the capabilities of the FPGA and it's currently over 90% used. At the same time there's still stuff i'd like to add (harddisk support, MIDI support and if possible a 16MHz 68000 with caches for Mega-STE compatibility). So I'd like to keep the FPGA side as simple as possible and move as much of the infrastructure into the BL616 MCU as possible. Also one day someone will hopefully port the Amiga/Minimig core which will likely also be a very tight fit especially if AGA support is included.

On the other hand the BL616 side isn't very convenient to develop for. The bouffalo SDK still has a bunch of quirks, especially in the USB part and the initial reaction to some of my bug reports bascally was "we don't support open source projects and we don't support sipeed boards". But this seem to have gotten a little better lately.

I wonder how they want to allow the BL616 to choose between different cores. Is there a way to tell the FPGA from which part of the SPI flash to load its bitstream? Or where do they want the different cores to be stored?

I will document what I've done with the BL616 so far. I am basically re-doing many of the things I did for the MiST over ten years ago. But as the BL616 is way faster and has more ram and flash, things can be implemented significantly neater.

[vossstef]

I full agree with Till. Recentry tried and old OSD with ZCPU and figured out that FPGA entirely filled up as i plugged it in and found out 'no way'... As anyway µC there it should be somhow used to allow many more retro core types. I am only worried that there is presently no way back due to lack of sipeed original µC firmware. The Litex project makes use (for to me unknown reasons) of the extra onboard PLL via special UART (SPI) configuration mode and by replacing with own firmware this feature would be gone...

[harbaum]

I hope the firmware availability issue will be resolved. And for now it's more convenient to work with the external BL616/M0S Dock, anyway.

I am not sure it's possible to switch between USB host and USB target in the same firmware on the fly. So it may not be possible to directly integrate both firmware types. A simple solution would be to poll the "UPDATE" button in a custom firmware and once its pressed, the BL616 resets itself and goes into the FPGA download mode.

This would mean that both firmware's are compiled into one binary and some magic marker early in the boot stage determines whether the uploader code is run or whether the retro firmware code is being run. But I have not managed to leave any message over a device reset. It seems the bootloader e.g. erases all memory. Maybe there's some hw register which can be used to leave a message that'll survive reset.

It would be cool if it was possible to detect whether the board is powered from USB as that means it's plugged into a PC and thus is supposed to run the uploader firmware. But IMHO that's not possible with the hardware as it is.

Actually, I don't understand the purpose of the seperate PLL at all. At least while it's controlled by the BL616 it doesn't allow the FPGA core to trigger any PLL configuration by itself.

[harbaum]

I just moved a very rudimentary SD card/FAT/disk image handling out of the core into the MCU which caused FPGA utilization to drop from >90% to 78%. And this was just very basic stuff. Now in the MCU I have full FAT/exFAT sd card handling with long filenames, subdirectory support and various other goodies.

This is the same with USB. You can do simple things like single HID targets inside the FPGA. But doing this in the MCU will save FPGA space and will give you more features. E.g. USB joysticks typically need a hid descriptor parser, otherwise only very few joysticks will work properly. This cannot be done inside the FPGA.

[nand2mario]

Let me have a chat with sipeed and find out if they are open to either share the firmware binary, or as discussed here provide a mechanism for loading custom binary after MCU boot.

[rog77]

I have full FAT/exFAT sd card handling with long filenames, subdirectory support and various other goodies.

This is the same with USB.

Is there any way to present a USB storage device to the FPGA, say, as an spi device with the MCU selecting a particular partition via OSD menu, or presenting a subdirectory as a partition to the emulated device? As you say, bitstreams could be on USB storage, but so could ROMs/disk images/user files.

[harbaum]

Is there any way to present a USB storage device to the FPGA

Sure. That way files stored on USB media could be used by the core just like it currently does with the SD card. Since the USB is available to the MCU without the help of the FPGA it could even reconfigure the FPGAs from a bitstream stored in USB media.

[harbaum]

See a little documentation on how I currently use the SPI connection between MCU and FPGA: https://github.com/harbaum/MiSTeryNano/blob/main/bl616/misterynano_fw/SPI.md

Some of this currently still is very Atari ST specific. E.g. key events are sent as Atari ST key matrix positions. But this can be extended to support PS2 codes again or even C64 key positions allowing to remove the keycode translation from the core.

[vossstef]

thx ! Need still some time to integrate as ongoing refactoring...

[rog77]

Is there any way to present a USB storage device to the FPGA

Sure. That way files stored on USB media could be used by the core just like it currently does with the SD card. Since the USB is available to the MCU without the help of the FPGA it could even reconfigure the FPGAs from a bitstream stored in USB media.

Interesting read on the SPI, thanks. I like how you have the different keymap idea covered too.

The thought occurs that if one is likely to have a second BL616 connected to the board anyway, couldn't this act as a USB device, such that a computer connected to it could access files whilst an emulated core is running? I lthink this might be more useful for cases where the core is used to produce something and the user doesn't want to physical usb/sd to access created files.

On the other hand, I wonder how many write cycles the bl616 flash is good for in practice, as nand2mario says there is space for bitstreams on there (and rememberinghow you said the ram is too small to hold them), and presumably they could be copied from SD card without needing extra hardware?

[harbaum]

One of the things I'd like to see a nice common solution for is the SD card. MisteryNano and nestang use the sd_reader which supports 1 bit SD mode. Unfortunately it doesn't support writing. The C64 on the other hand uses SPI mode which supports writing but is rather outdated and slow.

Perfect would be an SD mode driver with write support and perhaps even 4 bit support.

The only thing like that I could find is a rather complex wishbone based variant.

Does one of you guys know a nice solution?

[vossstef]

Let me have a chat with sipeed and find out if they are open to either share the firmware binary, or as discussed here provide a mechanism for loading custom binary after MCU boot.

any news ?

[harbaum]

They sort of agreed that I release the flasher part as a binary-only library. I have prepared for this, but this is not finished yet as other parts are more interesting to implement ...