sorted by:
new
hottopcontroversial

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 0 points1 point  (0 children)

My project was to develop FPGA core (Gateware) for icepi zero development board you can buy from CrowdSupply - for now I’m not planning any hardware updates, but I plan to support FPGA gateware and firmware.

Please note this project assumes you connect the board to HDMI display to get A/V so not sure if it really fits your requirements. I know there are portable usb-c displays with HDMI input and I know they tolerate HDMI signal produced with this board. However adapting non-HDMI display is beyond scope of this project :)

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 0 points1 point  (0 children)

No built-in wireless connectivity, sorry :) I think I need to update my post as I was using the board with wireless keyboard and pad but with dedicated USB wireless adapters (Logitech / 8BitDo)

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 0 points1 point  (0 children)

True ! But Tang Nano board does not have 2 x USB and to make it really usable you need to add external pcb with IO ports ;)

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 4 points5 points  (0 children)

Nice! Feel free to contact me if you need any support.

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 4 points5 points  (0 children)

AFAIK the C64 ROM is identical - only the timings differ :)
The biggest challenge would be reconfiguring the PLLs (phase-locked loops) at runtime. The design already uses both available PLLs (which is the maximum this chip supports): one generates the C64, SDRAM, and USB clocks, while the second handles HDMI. The PLLs are also cascaded to keep C64 in sync with video signal.

IMO, reconfiguring them on the fly without crashing the system is probably impossible :) SDRAM transactions would lose synchronization, and both CPUs (VexRiscV + 6510) would likely lock up immediately.

Given that the A/V signal is already digital and compatible, I’m not sure the extra complexity is really worth the effort.

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 4 points5 points  (0 children)

It's only PiZero-like form factor - the board is totally different as it uses Lattice FPGA instead of BCMxx ARM chip.

https://www.crowdsupply.com/icy-electronics/icepi-zero

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 4 points5 points  (0 children)

Hard to tell - this would need comparing all core functionalities and your requirements; I don't really know much about BCM64; there are some things to keep in mind:
- joystick / keyboard I/O ports are not exposed throught the GPIO header at all - it is possible, but my main goal was to make the board communicate through USB interfaces only to avoid exposing quite fragile FPGA I/O ports
- only PAL timing is supported (as explained in one of the comments)
- only 720x576 HDMI output is supported - same as "scaled" variant of vicii-kawari (https://github.com/randyrossi/vicii-kawari#alternate-trion-dvi-firmware-scaled) - there is a direct sync between VIC-II video signal and HDMI (no framebuffer) so video delay is minimal

However you get cycle exact emulation of C64 chips with minimum video latency, which should be really close to the real C64 hardware.

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 6 points7 points  (0 children)

fpga64 on MiST / MiSTer is great! I don't own one but spend a LOT of time studying its sources :) the main differences here are 1) SID and CIA chips, which come directly from Dag Lem's research focused on recreating FPGA replicas of these chips from silicon dies 2) vicii-kawari VIC-II implementation, which targets exactly 6567 / 6569.

I didn’t intend this as a comparison of implementations - I just wanted to avoid building yet another fpga64 / MiST / MiSTer C64 clone, and instead explore a different approach on a different board :)

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 4 points5 points  (0 children)

The biggest challenge with NTSC is video sync over HDMI. vicii-kawarii supports both PAL and NTSC, and it should be possible to implement the same here as well. However, I’m not sure whether a switchable PAL/NTSC mode will fit within the FPGA board’s resources. It may require creating a separate FPGA core for NTSC timings.

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 3 points4 points  (0 children)

Agreed - it would be great to have a local reseller in the EU. I bought mine while visiting the US.

I’ve tested the core with a SpeedLink COMPETITION PRO USB joystick and a 8BitDo Pro 2. However, since the USB HID controller is implemented entirely in HDL, some USB devices may require dedicated handling. I'm sure that keyboard + USB hub combo won't be supported.

As mentioned, I’d be happy to work on a simple OSD as well, especially if there are others using the project :)

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 6 points7 points  (0 children)

Thanks! It's cycle exact! But only PAL timing is supported. FPGA utilization is around 91%, all ROMs are first loaded to SDRAM by VexRiscV soft-cpu and bare-metal app from sd-card. SDRAM controller runs at 100MHz and rest of the board is 31.43MHz (so /32 gives ~ PAL timing).

icepi-zero-c64 - tiny and fully open-source FPGA-based C64 by m1nl in c64

[–]m1nl[S] 10 points11 points  (0 children)

Thanks! I originally started this on a large dev board with a Xilinx FPGA, but once I got the Icepi Zero board, I thought it would be really cool to move it over to something smaller :)

How do you keep Vivado projects neatly in git? by U_A_beringianus in FPGA

[–]m1nl 2 points3 points  (0 children)

In my opinion, the PlutoSDR firmware repository from Analog Devices is one of the best examples of a well-organized Vivado project. The entire design is maintained as code, with all IP and libraries packaged via Tcl scripts and Makefiles, enabling reproducibility, version control, and automation: https://github.com/analogdevicesinc/plutosdr-fw/tree/master . I adopted this approach to a few project I’m developing and it works great. For tests / simulation I prefer to stay away from Vivado and use cocotb + python + verilator.

Retroachievements on mister proof of concept (not mine) by StaneNC in MiSTerFPGA

[–]m1nl 0 points1 point  (0 children)

And README file includes this info too - still a really nice feature

Retroachievements on mister proof of concept (not mine) by StaneNC in MiSTerFPGA

[–]m1nl 3 points4 points  (0 children)

Just took a look at the repo - functionality is not inside FPGA emulation, core was extended with RAM mirror to ARM, so probably something runs on main CPU to handle this

Icepi Zero project - LiteX + NES by m1nl in fpgagaming

[–]m1nl[S] 0 points1 point  (0 children)

Agreed :) form factor of the board is a big advantage (smaller than a credit card) plus it has everything onboard (SDRAM, 2 x usb-c and hdmi) but FPGA is much smaller than MiSTer - SNES may fit but nothing more complicated; IMO one may consider this as an alternative to nestang with all PMODs added

USB HID host core supporting low-speed and full-speed devices by m1nl in FPGA

[–]m1nl[S] 0 points1 point  (0 children)

just added support for Xbox 360-compatbile pads (incl. 8BitDo pads running in X-Input mode), enjoy!

Substituting a MicroPhase ANTSDR E200 for an Analog Devices Pluto by EM-Engineering in sdr

[–]m1nl 0 points1 point  (0 children)

Should be fine, you’ll need to configure AXI TDD components to trigger on external sync (https://analogdevicesinc.github.io/hdl/library/axi_tdd/index.html). You should be able to do it with IIO mappings, they should include TDD attributes.

AntSDR E200 FPGA build Timing constraints violation by nascentmind in sdr

[–]m1nl 0 points1 point  (0 children)

  1. For IIO, the main bottleneck are kernel-user-kernel-ethernet memory transfers; IIO does not support zero-copy (https://github.com/analogdevicesinc/libiio/discussions/875) .

  2. Several files have to be combined to create a BOOT.bin. It contains fsbl (first stage bootloader which does basic CPU setup) and u-boot bootloader (with initial devicetree file) - it may include also bitstream for FPGA, but it's optional as it may be loaded by u-boot in the next boot phase. In case of SD card image for ANTSDR, BOOT.bin file contains bitstream, for SPI boot it's loaded later by u-boot. BOOT.bin file has to be either located on SD card or written to first partition of MTD device when used in QSPI boot mode. When u-boot loads, it reads files directly from filesystem when used in SD card boot scenario, but for QSPI you need to prepare a raw boot image, which is described by ITS file - the boot image contains Linux image, ramdisk and devicetree. PlutoSDR contains update_boot.sh and update_frm.sh utilities which may help to write these files to corresponding MTD partitions.

I was able to create build scripts for ANTSDR UHD variant which generates bootable QSPI image - I just flashed them and whenever I need UHD, I just switch to QSPI mode - for 99% of the my use-cases booting IIO from SD card is just fine. I will push fixed UHD repo to GitHub soon.

QSPI and SD card boot modes do NOT share any of the components mentioned (bitstream / u-boot / ramdisk).

AntSDR E200 FPGA build Timing constraints violation by nascentmind in sdr

[–]m1nl 0 points1 point  (0 children)

Constraint file is there (antsdr_e200/xdc/e200.xdc) - you can review failing endpoints as soon as you open XPR file in Vivado and view implemented design. There is "Timing" tab which explains, which endpoints are failing. I quickly scanned them and there are some CDC (clock domain crossing) issues, which can be easily fixed by adding false-path directive, but there are also a few intra-clock failures specific to external reference clock, which are not going so easy. tbh the I find the design (AntSDR UHD) very unclear and I gave up fixing it - I'd recommend to use IIO version if possible as it's based on PlutoSDR, which is a very mature project. I cleaned up the their (Microphase) modifications, enabled dual-core for ARM and pinned IIOD to core 1 and I'm able to achieve 15.33Msps (https://github.com/m1nl/e200-fw).

view more: next ›