I also found this interesting project, which I have ported to the ulx3s -https://github.com/lawrie/FPGAWhack. It is also a type of parallel processing GPU,. with a CPU and an assembler, but the source of data is effectively limited to the x, y co-ordinates of a pixel and a frame number. There is a compiler (in python) that lets you enter an expression involving x, y and f, which calculates the pixel color. It can be used to generate interesting graphical output. There is more detail here - https://github.com/jbush001/FPGAWhack/wiki
@lawrie HI lawrie, great GPU-vacation. 85F is large and rare project use it fully and compile time will rise significantly so a part of preparation could be getting a free login on some supercomputing cluster for yosys compilation. Here is DOOM for ULX3S and 1h compile time on normal PC https://twitter.com/sylefeb/status/1288053013748289538
@daveshah1 can yosys actually split its processing on parallel cluster to get any speedup?
you could in theory process submodules separately but you would get a less optimal result that way
FlexGripPlus is also very interesting, but VHDL : https://github.com/Jerc007/Open-GPGPU-FlexGrip-
@daveshah1 Recently I upgraded Yosys after a 6 month hiatus. My impression is that Yosys has slowed down a lot. The 6 mo's old Yosys took I think about 4 mins to compile a fx68K retro system, the current Yosys takes about 8. I can time exactly if that is helpful. Maybe some extra passes were added in the past 6 months? One of the attractions of Yosys (for me) is its fast turn-around as compared to the vendor tools. Would it make sense to have a "fast" mode for development of designs that do not need full optimization? I.e. a bit like compiling C without optimizations during development? Maybe I should direct this question to Clifford instead of you?
Maybe the analogy to C goes further. Back when C was developed, separate compilation of modules was one of its features, and the reason were the slow compilers (or the slow hardware if you like) of the time - standard Pascal at the time could only do whole program compilation. A related design point is the sqlite library. It has many source files, but for for ease of usage for distribution it is all combined into one big source file (the "amalgamation"). Somewhat to my surprise, compilers get more optimizations in the amalgamated source than in the separate source files. My point is: maybe a bit of inefficiency during development is acceptable for most designs and it accelerates the development cycle noticeably.
Sharing a small audio demo I made for ULX3S:
https://github.com/dan-rodrigues/ics-adpcm/tree/master/demo
It uses ULX3S to demo the ADPCM decoder / mixer core in the root of the repo. (thanks Emard for dacpwm.v)
https://github.com/dan-rodrigues/ics-adpcm/tree/master/demo
It uses ULX3S to demo the ADPCM decoder / mixer core in the root of the repo. (thanks Emard for dacpwm.v)
https://www.ebay.com/itm/PCM5102-I2S-Interface-DAC-Decoder-GY-PCM5102-I2S-Player-Module-for-Raspberry-Pi/183853870696?hash=item2ace8b6e68:g:C-gAAOSwYbZdCvX1 thanx for this demo! Besides SPDIF and HDMI, this i2s module for 5$ can also produce very clear sound and is directly pluggable to ulx3s
@emard I am trying to get back to TI-99/4A work with the ULX3S, i.e. looking to continue the SDRAM work sometime this week. Just checking if there's been some further work with SDRAM controllers to have a perhaps more recent starting point (I haven't read all the 100+ recent messages yet)
Thanks @emard , I was thinking of soldering headers to the board at some point to try a few peripherals like that
For HDMI audio I did see this repo, it is in SV but when I get a chance I'll try running it through sv2v and see if the output is workable with OSS toolchain:
https://github.com/hdl-util/hdmi
I would just try SPDIF but I don't think I have any equipment that accepts it
@Speccery I'd be glad to get 99/4A equipped with SDRAM for complete expandable space. @pnru_gitlab has made for QL https://github.com/lawrie/ulx3s_ql/blob/master/src/sdram.v the latest SDRAM controller. I suggest you try it first maybe it will just work or we can ask Paul for support :)
Thanks for sharing @drr I plan on doing some audio demos. Currently working in vhdl on ISE but want to port to fully open source ICE40 and Verilog (have an iCEBreaker and ULX3S on order). My demos will be streaming using a Python script running on the PC side using serial over USB communication with async.v on the FPGA (source from https://www.fpga4fun.com/SerialInterface.html). I really like the idea of using Icestudio to create my projects in a visual style. Do any of you guys use Icestudio?
I should also be ordering a MIDI Pmod at some point. Just waiting for @goran-mahovlic to get back to me when he's finished testing
ULX3S boards are packed and ready, I am just waiting for some papers from CrowdSupply
I was just checking out https://github.com/fpgawars/icestudio#supported-boards. Any chance of ULX3S support?
Ahh yes I should have looked at the source. All ULX3S boards are supported (https://github.com/FPGAwars/icestudio/tree/develop/app/resources/boards)
I'm pretty blown away by the team here. You guys seem to be adding support for everything under the sun. It's going to be an extremely versatile board with tonnes of tools and examples to play with
@emard, @speccery: I'm building a Verilog model for the mini Cortex and just completed an SDRAM controller that is matched to the 99000 and 9995 bus. It does one R/W plus one refresh cycle for each CLKOUT cycle (i.e. it is not free running like the 68K one). I'm happy that I spent so much time going into the details of SDRAM a few weeks ago: so far all my recent TI99 controllers have worked out of the box (but pride comes before the fall....). I will post my current 99K controller within the next few minutes.
The controller is here: https://gitlab.com/pnru/ti99/-/blob/master/sdram.v
I am using this with a 25MHz CPU clock (i.e. 6.25MHz CLKOUT) and a 125MHz sdram clock.
I am using this with a 25MHz CPU clock (i.e. 6.25MHz CLKOUT) and a 125MHz sdram clock.
@emard I'm building an IDE_SPI bridge from the CPU to the ESP32. The CPU thinks it is addressing an IDE controller, but the commands go to the ESP32 that gets the sectors from a file on the SD Card. Overall timing should still be faster than a 1984 WD1003 controller + disk. I'm modeling the SPI a bit on your OSD code. Is there any particular reason for the choice of sel/sclk/miso/mosi pins on the ESP32? Or just a choice just as good as any?
@emard Maybe I'd suggest this delay loop to be done with for/generate loop with compile-time parameter N steps. That is a good idea, indeed.
@pnru_gitlab SD card pinout is hardwired on PCB from ESP32 to SD card. The pinout is chosen that MMC mode should work and it works from arduino. But not micropython. I'm at the moment testing this again with all SDCard() parameters but no mount in 4-bit mode, error unexpected response 0x108. I can download some nightly build of micropython hmm
@pnru_gitlab I assume this is the mini Coretex you are referring to - http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm
I see that runs v6 Unix. Have you ever looked at this variant of v6 unix - https://pdos.csail.mit.edu/6.828/2016/xv6.html
There is a port of that to the Nyuzi GPU processor I mentioned recently - https://github.com/jbush001/xv6-nyuzi
AAAa yes those pins are randomly chosen. Take care that gpio32 and higher are ESP32 input only, others are bidirectional. In some maybe-future-plans, we maybe choose ESP32-S2-WROVER and then pins 5,16,17 will not be availabe but some others will. Apart from this, any pin would do for SPI
I like ZAP / Papilio DesignLab IDE / ZPUino and think IceStudio and FPGArduino is the next logical step. I'd like to have a crack at porting some of the ZPUino demos to FPGArduino. I have to wonder what happened to Jack Gassett and Gadget Factory as he created such a great set of tools and it would be a shame to see all of that work wasted. Are there any fans of the old Papilio boards here? Also before I start the arduous task of porting vhdl to Verilog how is vhdl support for Yosys going? Should I just wait for better support or is Verilog the way to go for open source FPGA development?
@pnru_gitlab additional SPI trick: as SD is mounted in 1-bit mode, some pins are free and most SD cards are then relasing this pins in hi-Z mode. So for FPGA-SPI-ESP32 communication I use pin2,14 (I think) which would not be available if SD were mounted in 4-bit mode. If ever micropython gets 4-bit more properly and it justifies use with increased SD speed, we should move SPI away from those bits.
@lawrie Thanks for the tip! In the mean time it runs a much enhanced version of V6 with elements taken from V7, V8 and V9 and the TCP/IP stack from BBN (that ended up in 4.2BSD). This is what I want to get running on the ULX3S. It will also be the machine that talks to the Blit, running on another ULX3S.
For a while in 2017/2018 I was planning to do a similar SBC with a 99105 or 99110 CPU and a better MMU. But then @Speccery convinced me that FPGA's were perhaps a more interesting route to go. It took me a long time to overcome my reluctance to a multi-gigabyte vendor tool download, but took the plunge. Luckily Trellis was just around the corner, as was the ULX3S.
@emard Which pins would you recommend, if the SD Card was using 4 bit data?
Good question :) if looking at my yet unprototyped ESP32 rework, I'd suggest to avoid using gpio5 first. Then for example gpio16,17,25,26 can be ESP32->FPGA and gpio32 FPGA->ESP32. This of course partially "contaminates" external bus for PMODs GP,GN 11-13 but if you haven't soldered and plugged something should be ok