Port to the nano6502

[venomix666]

A port of CP/M-65 to the nano6502 - a 65C02 based SoC which I have made for the Tang Nano 20K FPGA board, which is a cheap FPGA board available on Ali-Express, Amazon etc. with HDMI output and a microSD-card port.

It runs the CPU at 25.175 MHz and CPMFS is used natively on microSD-card using the parallel SD-protocol, so it is very speedy.

The console is 80x30 (on 640x480 over HDMI, hence the 25.175 MHz clock...) and there is a SCREEN driver.

The input is currently using the built-in USB serial port, which is nice as you can run this with only the FPGA board, but there are plans on a carrier board with support for a USB keyboard so that it can be run as a stand-alone computer as well.

The build generates two images, one which will write all 15 drives (of which 14 are empty) to the SD-card and one which will only overwrite the A-drive in case you want to preserve the data on the other drives. I use two python scripts to generate these images, and I have placed these in src/arch/nano6502.

There are a couple of utilities in user area 1 on A: for setting text/background color and flasing the on-board LEDs.

Note: The issue with only seeing one file per drive on the first access attempt, mentioned in #113 is present here as well, so it is likely a bug in the initialization of the DPHs when using multiple drives.

[davidgiven]

Excellent, thank you! I spotted one typo but otherwise all LGTM. I haven't had a chance to look at the multiple-drive issue yet.

That board looks really cool. How much of the FPGA is used up by the 6502 softcore?

[venomix666]

Excellent, thank you! I spotted one typo but otherwise all LGTM. I haven't had a chance to look at the multiple-drive issue yet.

That board looks really cool. How much of the FPGA is used up by the 6502 softcore?

Thanks, I'll fix the typo right away!

The GoWin tools unfortunately doesn't show logic usage per module, but the full design including 6502 softcore, UART, graphics generation and HDMI driver, SD-card controller, address decoding logic etc. uses about 15% of the available logic cells, so I would guess that the softcore itself uses about 5%.

There are for instance projects for the same board with implements the 68k CPU + full chipset for the Atari ST and Amiga, and full RISC-V implementations running Linux, so there is plenty of room.

I'm currently using the on-chip block RAM, which is single cycle access synchronous SRAM, of which there is just about enough for 64k of RAM, 8k of ROM and some graphics memory and buffers, but there is also 8 MB of SDRAM on the chip. I didn't really see any use for it in this system, but it would be possible to implement a bank switching solution to access it from the 6502. As the SDRAM is not single cycle access it would make the design more complex with different clock domains and/or wait-states, but it could be an interesting addition in the future.

All in all, it is a really nice and capable little board.

[davidgiven]

One thing which I tried for the neo6502 which worked with great success is to swap out the BDOS with one which makes calls to the neo6502's ARM processor for filesystem access. That was because the neo6502 has FAT file system support 'in hardware'. It was a bit clunky to implement but ended up working really well --- well behaved CP/M programs (i.e. ones which don't look at the block map in the FCB) can't tell the difference, and the end result is much more user friendly. It occurs to me that your board probably has enough space to run something like a Z8 softcore in parallel just to do filesystem stuff.

Of course, using a 32 bit softcore is a bit cheating, but I have found a 6502 FATFS implementation: https://github.com/commanderx16/x16-rom/tree/master/dos/fat32 It's too big to live in the main CP/M-65 address space but another option is to use bank switching to have two address spaces...

[venomix666]

Both the Atari and Amiga projects I referenced above use a small RISC V core to handle the FAT filesystem and load disk images etc., but as you say that is a bit cheating and things start to feel more like an emulator than a specific computer implementation to me.

The FAT implementation for 6502 looks really interesting - it may be possible to put that code in ROM, add a dedicated RAM area for it, and do some clever bank switching in a modified BDOS - I might look into that for a future update. I'll also have a look at the neo6502 BDOS to see how you solved it there.

[davidgiven]

You have enough RAM and FPGA space to run two 6502 cores. You could put CP/M-65 on one and use the other one for I/O via a mailbox interface. Paradoxically that might be easier than adding bank-switching.

[venomix666]

Yes, two 6502-cores sharing a dual port RAM could be easier, although it makes booting the system and so on a bit more involved.

I thought a bit about doing it with bank switching and while it is easy to ensure that the BIOS is not switched out, it does not seem trivial to ensure that the DMA area is not. There are workarounds of course, such as switching out the top 128 bytes of the zero-page and using it as a transfer buffer, or just map some RAM to the I/O address area during transfers (or the brute force approach with just bank switching twice for each byte...)

I think I would also prefer to rewrite parts of the 6502 FATFS-code to use the hardware accelerated SD-interface which I am currently using, rather than the software driven SPI approach which is there now. This should hopefully be straight forward as it would only be the code for reading/writing actual SD-card sectors which would need changing, but who knows :)

I also found someone who has implemented FATFS reading in verilog, which is an interesting approach if nothing else, but I think that adding write support to this would be a nightmare: https://github.com/WangXuan95/FPGA-SDcard-Reader

[davidgiven]

Sorry, been on holiday! Merged. Thanks!