There have been various reincarnations of the Commodore C64 over the years, and [Dave Van Wagner] has created one that can run on an STM32F429ZI Discovery development board. These dev boards have been around quite a few years and feature a 2.4 inch color TFT LCD in addition to the typical I/O circuitry, and are a pretty good value — [Dave] says they currently sell for under $30 through distribution.
The project began earlier this year when [Dave] set out to write a command line program in C# that emulated C64 Basic. He had written a 6502 emulator many years earlier, but had not tested it. [Dave] went on a programming binge in March and got it up and running over a very long weekend. He subsequently decided to add support for VIC-20, TED, and PET as well.
Even though [Dave] says C# is a beautiful language, he subsequently ported the program into C (an ugly language?) in order to run on the Discovery board, swapping the command line terminal interface for real LCD video and a USB keyboard. There’s also an Arduino version (terminal interface only). It runs about 15% slower than a real C64, and there are some limitations still like no SID. But overall, this is a great project and a low-cost way to emulate a C64 in an embedded format. If you want to explore further, here is the Mbed project for the STM32F429, and you can find the Arduino and C# versions on his GitHub page. You may remember [Dave] from the C128 video hack we wrote about last year.
“Even though [Dave] says C# is a beautiful language, he subsequently ported the program into C (an ugly language?)”
Uh… Do you even know whats under the hood for C# or python for that matter ? Its C/C++
That doesn’t actually say anything about the C# programming language. Furthermore, you’re also incorrect. C# compiles to intermediate language in most cases, like Java, which is in turn interpreted by a native runtime. There is no C/C++ code involved most of the time (depending in what your application needs to do). That’s for most of the cases… I’m aware of compiling to native and C/C++ interop and so forth, but that’s not what most C# developrs do in their day to day job. Many juniors may not even know such features!
Java is JIT compiled, not interpreted.
I think afterhourscoding is just confusing terminology, because it’s the same for C# (or any .NET). It’s compiled to intermediate language, which is translated by Just-in-time-compilation to native code.
Uh, just because a compiler for one language is written in another language, doesn’t make the languages identical…
Your argument seems to be conflating beauty with capability. All these languages are turing complete, but that doesn’t mean there’s no benefit in using one over another. Or else we’d still be writing everything by flipping switches on the front panel of an Altair to load machine code.
> Uh… Do you even know whats under the hood for C# or python for that matter ? Its C/C++
Except, when it isn’t. For example the pypy python runtime is written in python, not C/C++.
C/C++ is a Low Level Language that compiles down to Machine Code. C# is a High Level object oriented language that compiles down to CLR (Common Language Runtime), which is interpreted by JIT in ASP.NET. In other words with C/C++ you can create standalone programs while C# you can’t.
That is not what high level vs low level means. I’ll give you examples:
Low level languages: Machine Code
High level languages: Anything human readable… ie; BASIC, C, Pascal, Fortran, Java, COBOL, Modula, etc… literally everything else. Even macro assembly is considered a high level language.
Here is the definition for edification:
“A low-level programming language is a programming language that provides little or no abstraction from a computer’s instruction set architecture—commands or functions in the language map closely to processor instructions. Generally, this refers to either machine code or assembly language.”
I specifically referred to macro assembly above because it does give abstraction from the bare metal due to the embedded macro system, but RAW assembly does not.
You can’t create “standalone” C programs, even “hello world” requires multiple libraries to be loaded. Just using main() requires a library.
C# can compile to native code. It has for the past few versions. So yes, with C# you can create “standalone” programs.
oooh! programmer fight!!! we’re gonna definitely see some bitchslapping here… :P
I won’t dogpile n the C/c# fuss that has already started.
What a nice project! The end result doesn’t much excite me (a C64), but getting a 6502 emulator going like this and then spotlighting yet another STM32 variant is inspiration — and that what we all come to Hackaday for!!
As for C/C++# i will pick good old C anytime. Otherwise give me Haskell. Seriously though, the switch to C was I am sure driven by what was supported by the Mbed environment, and I think very appropriate for an embedded project like this.
Very cool project.
Too bad someone had to blow a gasket and freak out because of a perceived knock on their pet language.
Amazing, all this discussion and not a mention of Visual Basic., until now….
Which one is 15% slower than a real C64 and has no SID emulation? The Arduino or the F4 version?
SCHEMA/LISP is still the ugliest language I’ve even encountered. You can try to CARvince me I’m wrong, but I CDR care less.
That chip is clocked at 180Mhz? I still have Frodo emulator running on PalmOS Tungsten T2 (OMAP1510 – 168MHz ARM) and it runs full speed with sound. Emulation is not cycle exact so disk fastloaders do not work but otherwise games just work.
Where do I plug in my Jumpman Jr. cartridge?
Featured project creator here. I just heard my project was posted. Thanks for all the wonderful feedback and insight.
My latest C64 port today [November 2020] to Teensy 4.1 (600MHz) has achieved 1263% cpu speed, compared to about 85% cpu speed on the STM32F429 [April 2020]. Welcoming code review, pull requests, and pointers to get faster than 12.6x. github.com/davervw/c-simple-emu6502-cbm/tree/teensy_lcd
And all C based languages are beautiful! I enjoy them all. Anybody love AWK as much as I do?
I applaud your work Dave, especially because I find ituch easier to accumulate dev boards than to actually DO something with them. In fact I have both an STM32 and a Teensy waiting for a cool project like this! Is there any chance a bit more speed (or sound) could be wrung out of the STM32?
Sorry, that should say “I find it much easier….”
I hate, HATE typing on a touch screen.
Thanks for your feedback!!! Touch screens are not replacement for a full keyboard, but ha! they fit better in our pockets when we travel around our universes. Squeeze more speed? Dunno. Leaving that exercise right now for someone else, open source and all that. My Teensy is doing much better than STM now, as it has D64 support too (just one so far… just LOAD/SAVE so far….) And doesn’t have than hang after half an hour bug (oops, a resource leak?)
I wonder if it would’ve been possible to use nanoFramework to port the C# version?