Your list misses SM-1700 ("СМ-1700"), a full clone of VAX-11/730. But all the VAX-compatible computers were produced only during the last several years of the USSR, so just a few thousand had been built in total.
I want to mention another awesome project, which implements PDP-11 on FPGA and can be used with PiDP-11 panel. (PiDP-11 by default uses software emulator running on Raspberry Pi.)
Not the parent poster, but my experience may be relevant.
My background is exclusively in software engineering and computer science. I started by reading “Digital Design and Computer Architecture”. There’s new RISC-V edition https://a.co/d/imzGBK5 as well as freely available ARM edition https://dl.acm.org/doi/book/10.5555/2815529. The book starts from Boolean logic and transistor technology and goes all the way to assembly programming with everything in between. Most importantly gives great introduction to HDLs. Next I played with a bunch of hardware projects specifically targeting inexpensive Arty-A7 board to get comfortable with FPGA tooling.
I can attest to the parent saying that this is sufficiently different from software engineering I do at my day job and therefore feels a lot more like hobby. Especially if you also foray into wire-wrap prototyping, PCB design and assembly. Finding and fixing analog "bugs" is so much fun!
Finding out the digital design parts seems like the easy half of the problem.
The non-open-source-tooling (that is what you need for the dev boards I have played with) is what I've had a real struggle with - Vivado and Quartus are so horrendously complicated, that it seems easy to find a project failing at some late stage because you clicked a button wrong two days ago.
Learning these, and the interplay between board specifics and the way any onboard CPU talks to the FPGA mesh and how you interface between the peripherals just seems like a massive explosion of complexity that you seem to have to know in order to know how to learn it. And every board seems to be a horrendous combination of seemingly opaque "IP" blobs.
I've looked even for paid tutorial series, but everything seems to be assuming you've gotten past this stage, or aimed at the "here is how you build up pure stuff in VHDL/Verilog".
>Vivado and Quartus are so horrendously complicated, that it seems easy to find a project failing at some late stage because you clicked a button wrong two days ago.
The (open) industry secret is that nobody actually uses the GUIs for anything other than analyzing build products (viewing floorplans, etc.); everything else is done through tcl scripts and Makefiles. This lets you both avoid the disaster that is the GUI portion of the tools and keep the entire project in a regular text representation (which means you can actually edit everything and check it into version control!).
As an extreme example, I've never even managed to get Lattice Radiant's GUI to even run, the damn thing just crashes almost immediately. It doesn't matter though because the backend tools all still work perfectly. We've just written some tcl scripts which handle everything for us and we called it a day.
> The (open) industry secret is that nobody actually uses the GUIs for anything other than analyzing build products (viewing floorplans, etc.); everything else is done through tcl scripts and Makefiles. This lets you both avoid the disaster that is the GUI portion of the tools and keep the entire project in a regular text representation (which means you can actually edit everything and check it into version control!).
I've sort of worked out this but it seems to be a weird mix of "you need to know what the UI is doing and why in order to avoid the UI". Getting that initial understanding seems a very high barrier.
(version control also seems to be something they manage to break on a whim over toolchain versions - maybe it's one of these hardware things where people just stick with the same toolchain version over the life of the product).
I started by reading “Digital Design and Computer Architecture”. There’s new RISC-V edition https://a.co/d/imzGBK5. The book starts from Boolean logic and transistor technology and goes all the way to assembly programming with everything in between. Most importantly gives great introduction to HDLs. Next I played with a bunch of hardware projects specifically targeting inexpensive Arty-A7 board to get comfortable with FPGA tooling.
I think hitting F5 and using the arrow keys in-game should allow you to decrease the size of the gameplay window to try to increase performance. You might try that if you haven't already...
Yes, specifically IBM PCjr-ish clone. Compared to IBM PC 5150 it has 2x slower access to the first 96K of RAM due to “integrated” nature of its non-standard take on CGA. But, the rest of RAM is actually faster than IBM PC because it is a modern retro computing extension card made with fast SRAM.
It has TTL RGBI and composite NTSC outputs. The latter is actually very interesting in that it can produce 16-color images using color smearing effect on NTSC TV. Many games from the period used this to achieve more colorful graphics at the expense of dropping to 160x200 resolution. OP port of Wolf3d is also supporting this mode.
I am working on FPGA-based converter to be able to show RGBI and composite CGA on modern VGA screens.
This two-part blog explains step by step how to build a robot starting from training the ML model, using FPGA for hardware acceleration, writing an embedded C program and finally assembling everything on the chassis.
We work on an open source tensor processing unit at https://tensil.ai. It is not RISC-V based since only a handful of very simple instructions is needed for expressing data flows typical in ML.
Great questions! With Tensil, all computations are performed on the FPGA. In addition to matrix multiplication Tensil supports SIMD instruction with various operations. The ML activations, average and maximum pooling, normalization, and image resizing use SIMD instruction. Some ML operations, such as padding, are achieved by changing the memory layout. Tensil uses DRAM0 and DRAM1 memory pools (usually in DDR memory) to interact with the host to read model inputs and weights and write outputs. It also uses these pools to offload intermediate results between layers and between tiles within a layer when FPGA does not have sufficient BRAM, which is common on lower-end devices. Tensil compiler takes care of finding the most efficient memory scheduling for given on-FPGA memory size.
Okay thanks, so are DRAM0 & DRAM1 memory pools located on the host DDR memory, or is that a part of separate DDR DRAM hardware located on the FPGA board (kind of like how GPUs have their own separate DDR DRAM)? I definitely want to dive deeper into the source code of this project at some point and see how the compiler and everything works.
Edit: Sorry I think you already clarified that the DRAM0 & DRAM1 memory pools are located on the host
Something like the Alveo PCIe card has onboard HBM/DDR4 memory large enough for Tensil DRAM pools, so this would be similar to how GPU operates but could also reach to host memory via PICe if needed. Embedded applications with Zynq 7 and UltraScale+ have ARM processors on the same chip with FPGA and (usually) DDR as separate chips on one PCB. In this case, Tensil DRAM pools are just contiguous memory blocks in the memory shared with the CPU. We will be publishing documentation on the compiler design soon--stay tuned!
On a fast enough STM32 you don't need any hardware tricks at all, you can just use DMA to feed values to an IO port, and get 8-bit VGA colour even at quite high resolution - 640x480 is entirely doable if you have enough memory.
Very glad to see Rust on PIC32! This microcontroller is one of the very few that is still made in DIP package making it ideal for breadboardind and easy through-hole soldering, and by far most powerful, making it ideal choice for interesting projects.
I spent many years with PIC chips, starting with PIC16C84 and a homemade EEPROM programmer on my DOS machine. One thing I like to this day is that the PIC chips were extremely well documented, and the documentation style was consistent across their product line. This in turn made bare-iron programming relatively easy.
I still have my UV EPROM eraser from those days. My friend used an old chip of mine with the brass frame around the quartz window as a base for jewelry design. They do look cool on their own!
I kept a few of those chips to show my kids. They're really works of art.
The PIC16C84 was one of the (if not the) first MCU chips to use EEPROM (precursor to flash memory), so I didn't need an eraser. It became a favorite of hobbyists. Programs were so simple, that assembly language wasn't really much of a barrier. I only started using C later, in fact, to teach myself C programming.
Before that, I made a board that combined an 8031 (8051 without built-in ROM) and a 28 pin EEPROM. My programmers hung on the parallel printer port of a MS-DOS machine, and were controlled by code I wrote in Turbo Pascal. Ah, the days. ;-)
I missed the UV boat, but instead of getting a high voltage programmer like I should have, wasted a ton of time saving $100 by making an low voltage programmer that sometimes worked. Embedded was rough for a long time.
https://en.m.wikipedia.org/wiki/SM_EVM