Olimex €1 RISC-V CH32V003 retro PC with VGA and PS/2 keyboard

[brucehoult]

Can order now, ships October 4.

https://www.olimex.com/Products/Retro-Computers/RVPC/open-source-hardware

RVPC is EURO 1.00 old retro computer style RISCV computer with Keyboard, VGA and Woz like monitor which allow you to explore the RISCV architecture and assembler.

The RVPC is sold as DIY Kit for self soldering.

All components are carefully selected to be possible to be assembled even from beginners.

FEATURES

- CH32V003 QingKe 32-bit RISC-V2A processor

- 48MHz system main frequency

- 2KB SRAM

- 16KB Flash

- Power supply voltage: 5V

- PS2 keyboard connector

- VGA connector

- Audio Buzzer

- power LED

- Power supply Jack

- Four mount holes

- Dimensions 50x30 mm

SOFTWARE

- RVPC Wozmon demo code (shipped by default)

- Towers of Hanoi demo code

- TETRIS game demo code

- ch32v003fun covers you with software support for every feature of CH32V003

- Vmon is Woz like monitor for RISCV

- repository with retro games made for ch32v003


https://github.com/OLIMEX/RVPC/blob/main/DOCUMENTS/RVPC-user-manual.pdf

[brucehoult]

The VGA output is made by the RISC-V CPU "bit-banging" an I/O pin at exactly the correct timing. Just like in the ancient Sinclair (Timex in USA) ZX80 and ZX81 this means the CPU spends most of its time drawing the display and can only run normal program code during the video H and V blanking periods.

Running the Towers of Hanoi demo:



Tetris:



The RVMON program (which I believe is pre-programmed into the CH32V003 when you get it) allows examining the contents of memory (RAM  or flash) in hexadecimal, entering new values into RAM, and executing RV32 machine code starting from any desired address -- which of course is very likely to crash the machine if you are not careful.

A talk on the idea https://youtu.be/YlYE9a7zsqY&t=20370s (at 5:39:30 if you are not taken there automatically)

[MK14]

I can see one immediate problem.

Hand created/typed/entered machine code, has a significant risk of causing unintended crashes.  E.g. One hex digit wrong, out of the many digits for a real program, such as 500.  Could easily cause the program to simply crash and/or do nothing.

So, it could really do with some method of being able to store programs.

Example:
The Sinclair ZX81 (which this computer seems to have significant similarities to), was able to (very slowly) load and store programs to cassette tape.

Also, USB would probably be a more convenient way of powering it.  EDIT2: I think it was intentional, to allow users to easily assemble the kit, as USB connectors, can make it much harder.

But anyway, a fun kit/project/idea, just way, way too expensive for most people.   

EDIT:
If it can keep the current program, in part of the flash, that would be better (I'm not sure if it currently does that).

On reflection, I think the idea is that you also buy the ESP32-S2-development-thingy (mentioned in the documents) unit, which plugs into it (via a 2 pin connector, one of which is ground), and then allows program development to take place on a PC.

[brucehoult]

I can see one immediate problem.

Hand created/typed/entered machine code, has a significant risk of causing unintended crashes.  E.g. One hex digit wrong, out of the many digits for a real program, such as 500.  Could easily cause the program to simply crash and/or do nothing.

Yes, of course, and I SAID THAT.

Just like on Apple ][ etc, which I cut my hex machine code programming teeth on at age 17 in 1980 [1]. But, just like the Apple, if you can reset the board without powering it off then you can fix your code and try again.

So, it could really do with some method of being able to store programs.

Example:
The Sinclair ZX81 (which this computer seems to have significant similarities to), was able to (very slowly) load and store programs to cassette tape.

The initial talk proposed using the very slightly more expensive 16 or 20 pin package, which would provide plenty of GPIOs to drive a cassette tape or simulation of one. They switched to the 8 pin chip to make hand soldering easier.

You could maybe output data using the audio output, and input things mechanically via the PS/2 e.g. using a KVM.

If it can keep the current program, in part of the flash, that would be better (I'm not sure if it currently does that).

Certainly you can do that, given sufficient spare space in the 16k flash.

On reflection, I think the idea is that you also buy the ESP32-S2-development-thingy (mentioned in the documents) unit, which plugs into it (via a 2 pin connector, one of which is ground), and then allows program development to take place on a PC.

Yes, and to download other programming e.g. the Towers of Hanoi or Space Invaders or whatever.

I haven't ordered the ESP32 board as I assume I can manage to use one of the many other boards I already have e.g. Pi Pico 2 etc.

[1] I didn't has access to an assembler at all, but 6502 machine code was significantly easier to encode by hand than RISC-V. Most people will of course run an assembler on a PC even if they then enter code by hand.

[MK14]

I can see one immediate problem.

Hand created/typed/entered machine code, has a significant risk of causing unintended crashes.  E.g. One hex digit wrong, out of the many digits for a real program, such as 500.  Could easily cause the program to simply crash and/or do nothing.

Yes, of course, and I SAID THAT.

Just like on Apple ][ etc, which I cut my hex machine code programming teeth on at age 17 in 1980 [1]. But, just like the Apple, if you can reset the board without powering it off then you can fix your code and try again.

So, it could really do with some method of being able to store programs.

Example:
The Sinclair ZX81 (which this computer seems to have significant similarities to), was able to (very slowly) load and store programs to cassette tape.

The initial talk proposed using the very slightly more expensive 16 or 20 pin package, which would provide plenty of GPIOs to drive a cassette tape or simulation of one. They switched to the 8 pin chip to make hand soldering easier.

You could maybe output data using the audio output, and input things mechanically via the PS/2 e.g. using a KVM.

If it can keep the current program, in part of the flash, that would be better (I'm not sure if it currently does that).

Certainly you can do that, given sufficient spare space in the 16k flash.

On reflection, I think the idea is that you also buy the ESP32-S2-development-thingy (mentioned in the documents) unit, which plugs into it (via a 2 pin connector, one of which is ground), and then allows program development to take place on a PC.

Yes, and to download other programming e.g. the Towers of Hanoi or Space Invaders or whatever.

I haven't ordered the ESP32 board as I assume I can manage to use one of the many other boards I already have e.g. Pi Pico 2 etc.

[1] I didn't has access to an assembler at all, but 6502 machine code was significantly easier to encode by hand than RISC-V. Most people will of course run an assembler on a PC even if they then enter code by hand.

I was perhaps, partly wrong using the word 'Crash', which you did mention earlier in this thread, as regards getting the start address wrong.

I really meant the other/later forms of 'crash', such as when the software does run, but just doesn't do what it should, and outputs NOTHING.
So you are left scratching your head, as to why it is doing nothing at all.  Is it because it is actually crashing, or is it because the output parts of your software, have mistake(s), so they don't succeed in actually outputting anything (so strictly speaking not a 'crash' as such, but would appear to be the same).

Better (genuine vintage era) computer development systems, would allow independent 'soft' (i.e. nothing is cleared, except for the CPU registers), and 'hard' (RAM memory is cleared) resets.  As well as possibly single stepping, breakpoints and maybe other aids.  Which your 1980 Apple system, partly gave you, which was good!

I wonder if the included 'monitor' (I've not read up on it) does (or will in the future), include a number of useful built in routines.  Such as ones which write to the screen, accept user input, make beep sounds (via parameters), possibly even floating point arithmetic.
As well as many other useful routines, for use in peoples programs.  Such as writing to flash.

I think the 2k of RAM, would make it an interesting Forth language target, as that is one of the few (that interactively runs and allows development, on the device, without needing separate equipment) programming languages, that would still be fine with just 2k of RAM.

I suppose the original Arduino 'ONLY' had 2k of RAM, so it would still allow a tremendous amount of capabilities.

I'm still scratching my head over, how people can buy a 1 Euro dollar device, without incurring massive delivery charges and possibly VAT and maybe import/administration/fees as well.
But if it gets stocked in other suppliers, then it could be included in an order which involves buying other stuff at the same time.

[MK14]

Just like on Apple ][ etc, which I cut my hex machine code programming teeth on at age 17 in 1980 [1].

I think the Sweet16 feature it had.  If I've got the right Apple model in mind.

https://en.wikipedia.org/wiki/SWEET16

Was good.

I wonder what a modern day version of it, would look like.  Possibly single floating point arithmetic, rather than 16 bit integers?

Hopefully, with many other capabilities, such as some form of 'printf' like capability.  Even if it only prints strings or numbers to the screen.

The fact it only needs 1 byte per command, would be very useful when trying to interactively fit in just 2k of RAM.

Since the RISC-V is already 32 bit word size, some of the usefulness, of the original SWEET16, is removed, as the instruction set already has that capability, built in.

[brucehoult]

I wonder if the included 'monitor' (I've not read up on it) does (or will in the future), include a number of useful built in routines.  Such as ones which write to the screen, accept user input, make beep sounds (via parameters), possibly even floating point arithmetic.
As well as many other useful routines, for use in peoples programs.  Such as writing to flash.

Yes, this would certainly be helpful. Most of those functions, other than writing to flash, exist in the monitor now. It's written in C, so is easy to modify. But that will result in functions moving around a lot. Probably what you want is a, ECALL (trap) based interface, or simply a table of Jump instructions placed at a known location

I suppose the original Arduino 'ONLY' had 2k of RAM, so it would still allow a tremendous amount of capabilities.

I think the original has less, but the enduringly popular Uno has 2k yes, and 32k of flash. There's only 16k of flash here, but RISC-V code is more compact than AVR in several ways, most obviously when dealing with 16 or 32 bit values, but also when dealing with pointers. You probably do get more functionality into 32k of AVR code, but not by as much as it would at first appear.

I'm still scratching my head over, how people can buy a 1 Euro dollar device, without incurring massive delivery charges and possibly VAT and maybe import/administration/fees as well.
But if it gets stocked in other suppliers, then it could be included in an order which involves buying other stuff at the same time.

Always a problem with cheap devices. And of course you could get a heck of a lot more functionality by spending even 50c or $1 more on the BOM e.g. one of WCH's bigger chips e.g. CH305/7 with built in USB, 32k or 64k RAM, 128k or 256k flash, FPU etc. But they don't do 5V. And they come in more challenging packages to hand solder.

The whole fun here is to see what's the absolute cheapest you can make a usable computer for.

Shipping to NZ is 25 euro. Pretty bad for a 1 euro device. I've ordered 18 of them, with 30 euro shipping, plus another couple of euro charge for using Paypal, for 51.37 total. They'll get here for a bit less than 3 euro each. Goodness knows what I'll do with the other 17. Maybe I'll try to sell some locally.

Fortunately in NZ we don't have any import hassles or charges for shipments under NZ$1000 (568 euro at the moment).

I made my order five hours ago at 12:15 Sofia time, and DHL physically picked it up at 2:20 PM, so they clearly do have stock right now.

[brucehoult]

Just like on Apple ][ etc, which I cut my hex machine code programming teeth on at age 17 in 1980 [1].

I think the Sweet16 feature it had.  If I've got the right Apple model in mind.

SWEET16 -- and the mini assembler and Integer BASIC -- was unfortunately only in the non-autostart ROM. The machine I had access to was a ][+, which had the larger floating point BASIC in ROM and didn't have room for the extras.

The fact it only needs 1 byte per command, would be very useful when trying to interactively fit in just 2k of RAM.

Yes, though that is for operations involving one of 16 "registers" and the accumulator (r0) -- a lot like 8051 -- so adding one register to another needs three 1 byte instructions: "LD rA; ADD rB; ST rC". In the common case where the dst is the same as one of the sources x86, Thumb, M68K, RISC-V C, MSP430 etc are more compact.

SWEET16's 4+4 bit encoding also has a lot in common with the instruction encoding on the Transputer. The Transputer had a 3 entry stack not just an accumulator, though that was of limited use because a lot of instructions, such as unconditional branches, cleared the stack.

I wonder what a modern day version of it, would look like.

I've thought about writing an MSP430 emulator for 6502 and wondered how much larger it would be than SWEET16's slightly over 300 bytes of code. I think not much more. MSP430 code is more compact, and also has the considerable advantage that gcc exists for it.

But I don't think it's worth doing for RISC-V. RISC-V code with RVC is basically already as dense as MSP430 or SWEET16 or anything else. And it costs a lot of speed overhead to emulate anything. I don't think even FORTH provides any code size advantage.

The only advantage you could potentially get is something easier to code and read by hand. Even if you want an assembler/disassembler you might as well just do one for the native RISC-V ISA.

[MK14]

I am amazed they managed to create a complete computer, with VGA output, keyboard (PS/2) and built in sound, only using an 8 pin RISC-V MCU.

Probably what you want is a, ECALL (trap) based interface, or simply a table of Jump instructions placed at a known location

Yes, exactly.  It needs to have some sort of fixed, BIOS like table(s), so that people can start writing code and creating libraries or even simple OS's for it.

I've ordered 18 of them, with 30 euro shipping, plus another couple of euro charge for using Paypal, for 51.37 total. They'll get here for a bit less than 3 euro each. Goodness knows what I'll do with the other 17. Maybe I'll try to sell some locally.

You could always play around with one of them, put another safely away in a drawer, as a spare.  Then use the remaining 16, to make a massive 16 way, $16, 16-core RISC-V cluster computer.
48 MHz x 16 = 768 MHz (vaguely) of RISC-V goodness, and a massive 32 kB of RAM and quarter megabyte of total flash storage.

It would be so powerful, it could drive a sweet sixteen VGA displays at the same time, and allow for up to 16 people to use it, simultaneously, with their own keyboards.

If you look at the huge software library available for the original (as first mentioned by yourself) Sinclair ZX81, for its 1 kB of RAM, and (probably) considerably slower processing speed, when both keep their displays operating, continuously.  If the displays are allowed to blank, when the computer is under deep thought, then a 48 MHz 32 bit RISC-V, is probably dozens or more times faster than a 4 MHz (it might have been a bit slower, so the frequencies matched what the TVs needed) Z80 would be.

It shows that this very modest computer, would, given the right software, be able to do quite a bewilderingly large amount of things.

How long before someone writes a web-browser for it, and finds a neat way, to connect it up to the internet?

[brucehoult]

I am amazed they managed to create a complete computer, with VGA output, keyboard (PS/2) and built in sound, only using an 8 pin RISC-V MCU.

It is almost the only semiconductor -- and the only essential one.

There is an LED showing that power is present. There is a transistor driving the piezo speaker and a diode across it. That's it!

There is a capacitor across GND & Vcc on the RISC-V chip.

EVERYTHING else is resistors (nine) or connectors.

To address another question: there isn't a reset button (or a GPIO available for one), but there is a watchdog timer available, so that could serve much the same purpose. Just if you do write long-running code you might need to reset the watchdog from time to time. Mostly the check for keyboard input function doing that would be good enough.

Probably what you want is a, ECALL (trap) based interface, or simply a table of Jump instructions placed at a known location

Yes, exactly.  It needs to have some sort of fixed, BIOS like table(s), so that people can start writing code and creating libraries or even simple OS's for it.

Note that this is only for code entered interactively, via the monitor.

Programming serious things, such as games or real apps, is of course meant to be done in C, using normal C library facilities, and reprogramming the flash.

Using the 16 or 20 pin package would have allowed more GPIOs for mass storage on SPI flash or an SD card. Maybe some form of network connection, as you mention.

BUT you don't WANT to expand this thing too far.

Its purpose is to have a computer that works, and can do recognisable computer things, but that is so simple you can study and understand the entire thing. That's how Atari 2600s and Apple ][s and ZX80s were and its been sadly missing for a long time. Even the ZX Spectrum and C64 were a bit complex for complete beginners.

And by the time you get to $2.50 or $3 you've got ESP32 dev boards with hundreds of KB of RAM, and WIFI/BT. Or the Pi Pico.

Add a couple more bucks and you've got 1 GHz 64 bit 64 MB RAM full on Linux in the Milk-V Duo.

Capability rises very quickly with just a few more dollars on the price. But so does complexity.

[MK14]

I am amazed they managed to create a complete computer, with VGA output, keyboard (PS/2) and built in sound, only using an 8 pin RISC-V MCU.

It is almost the only semiconductor -- and the only essential one.

There is an LED showing that power is present. There is a transistor driving the piezo speaker and a diode across it. That's it!

There is a capacitor across GND & Vcc on the RISC-V chip.

EVERYTHING else is resistors (nine) or connectors.

To address another question: there isn't a reset button (or a GPIO available for one), but there is a watchdog timer available, so that could serve much the same purpose. Just if you do write long-running code you might need to reset the watchdog from time to time. Mostly the check for keyboard input function doing that would be good enough.

That is a good and interesting idea, to use the watchdog timer, as an alternative, to a proper reset button.  As you just said, if it connects to a keyboard input function, then it can ensure that the stop/abort/break/reset key functions on the unit, are still working.  Obviously the software can use/choose whatever keys or combinations they want to, so it could be CTRL + C and/or 'Break' and/or 'Escape' etc.

It also would be able to do a relatively 'soft' type of reset, and keep memory intact, but possible data or even program corruption, could occur, if it was a really bad crash.

E.g. 99.9% of the time, a crashing home computer (ones from a very long time ago), would perhaps just freeze up (stop responding).  But 0.1% (wild estimate) of the time, the screen could change to a random mess of ASCII characters, maybe even continuously changing ones.

[MK14]

Note that this is only for code entered interactively, via the monitor.

Programming serious things, such as games or real apps, is of course meant to be done in C, using normal C library facilities, and reprogramming the flash.

Using the 16 or 20 pin package would have allowed more GPIOs for mass storage on SPI flash or an SD card. Maybe some form of network connection, as you mention.

BUT you don't WANT to expand this thing too far.

Its purpose is to have a computer that works, and can do recognisable computer things, but that is so simple you can study and understand the entire thing. That's how Atari 2600s and Apple ][s and ZX80s were and its been sadly missing for a long time. Even the ZX Spectrum and C64 were a bit complex for complete beginners.

And by the time you get to $2.50 or $3 you've got ESP32 dev boards with hundreds of KB of RAM, and WIFI/BT. Or the Pi Pico.

Add a couple more bucks and you've got 1 GHz 64 bit 64 MB RAM full on Linux in the Milk-V Duo.

Capability rises very quickly with just a few more dollars on the price. But so does complexity.

That is a very good point!
Of course.

Yes, by keeping it VERY simple, it makes it practicable, for beginners and others, to fully understand the entire hardware and software.

Taking what you just said, as an example.  The Commodore 64, even though it was relatively straightforward, and very low computing power (compared to today's modern standards).

Some parts of it, were still potentially very complicated.  Such as its video processing chip(s) (with stuff like hardware sprites), sound processing chip(s) (which could make quite nice sounds, for the time, IIRC), and other complexities, such as the BASIC (interpreter language ROM), in some respects, such as its floating point (although it can seem relatively simple and straight forward, when you move on to things like calculating SIN()'s and stuff, it is not that easy or obvious, how it works), random number generator and other features.

To counter anyone who disagrees, then I'd suggest attempting to write, from scratch a Commodore 64 emulator (as a hypothetical exercise).

Because elements such as its 6502 (technically speaking I think it was a different CPU number, but it was basically still a 6502), its RAM and ROM (assuming you accept it was originally copyright).  Could be written (e.g. in C), rather quickly and easily (depending on programming experience level and things).

But its (the Commodore 64) complicated video and sound generating chips, could be considerably harder to emulate.  Although I've not tried to emulate them, or extensively read up on them, so I'm NOT 100% certain how difficult it would be.

Even the 'old' Sinclair ZX81, had a FPGA/ASIC like (I think it was called a gate array or uncommitted gate array, at the time era, the ZX81, was created).  Which replaced dozens (?, I'm not sure of the quantity), of discrete TTL chips, inside one gate array (like) custom or semi-custom IC's.  Which is probably why you mentioned the ZX80 over the ZX81, in the post I just quoted.

[MK14]

Maybe a cheap solution of getting hold of one or two of these.  Is to wait until the Chinese, hopefully copy/make this open-source design.  Then sell it rather cheaply, with their usual outlets, such as AliExpress and Ebay.
So, it might be priced at something like $3 .. $7, with either free postage included, or a modest amount.

Other charges, such as import duties, VAT etc, depend on the specific country involved.

But if it ends up being stocked by companies such as Digikey and Raspberry Pi parts suppliers, that would be even better.

Olimex sometimes gets some of their stuff, onto such platforms.

So, if a person sometimes buys other stuff, from those later sources, this thread item can be added to the order.

Even in the old days, stuff purposefully intended for machine code (mainly) use, were rather rare.

E.g. The MK14 (I'm saying nothing), Heathkit ET-3400, KIM-1, and others.