Denial

Sadly, at the moment there is no good VIC 20 emulator for mobile.

The emulator of my dreams is one that:
- has true aspect ratio
- works in portrait mode, showing no or little borders
- uses a native commodore keyboard (even if arranged differently on several rows)
- bluetooth keyboard optional

I've considered writing/forking one myself, but I'm poor at android programming.

The JavaScript alternative is too slow as of today, the good matt dawson's JavaScript emulator is 5x times slower than it should be on my phone. Perhaps we might have a less-accurate but faster emulation?

Thoughts anyone?

nippur72 wrote:I've considered writing/forking one myself, but I'm poor at android programming.

Android programming is a simple task. If you use NDK, you can use C or C++. Only few Java wrapper functions are needed (window init, touch, keyboard etc.). NDK provides a "normal" linux programming environment for your application.

Help with improving the VICE android port is always welcomed

if your feeling game, you could try getting one of the old dos emulators running in dosbox on your mobile device....

If I succeed, it will be something like this:

(keyboard is experimental, I have to rearrange keys)

I use the commode 64 emulator, Frodo...there is a Vic 20 emulator for the commodore 64...so its a Vic inside a 64 inside Android...a bit convoluted, but it works well for most BASIC programs.

Looks good @nippur72 how is the speed?

the prototype I'm working has still the CPU written in plain JavaScript, so it's very slow, around 5x-10x slower. But as I've said in another thread I'm experimenting with ASM.JS that hopefully will make it run a lot faster, hopefully it will run at 1x speed on mobile. The only limitation is that you have to open it in Chrome or Firefox (for mobile).

Thanks for this effort! Too bad that latest Chrome for Android is very unstable, often crashing on my Huawei tablet
Anyway, a good native VIC emulator on a mobile device is VERY welcome!

I got a little confused. Are you writing a new emulator from scratch? Because that's what I just did in C for slow hardware.

@pixel I've written almost nothing yet (apart from the keyboard), I'm reviewing existing emulators (non vic-20 too) to reduce the effort to minimum.

Don't know about your C emulator, it would be perfect to compile it via Emscripten to JavaScript. Is it open source? Where I can find it?

nippur72 wrote:@pixel I've written almost nothing yet (apart from the keyboard), I'm reviewing existing emulators (non vic-20 too) to reduce the effort to minimum.

Don't know about your C emulator, it would be perfect to compile it via Emscripten to JavaScript. Is it open source? Where I can find it?

It isn't open source, yet, because it is extremely simple. Except for the 6510 CPU (with no BCD arithmetics), VIA joystick status bits and most simple 6561 emulation with a fake raster counter absolutely Nothing Else[tm] is emulated. Would have to clean it up a little bit before making it public.

EDIT: Are you sure you want to go down that road!?

> Are you sure you want to go down that road!?

the alternative would be learning android programming, ndk and all the rest, honestly I'm not in the right mood. I would like to go for the browser/HTML if possible, even with the hack of ASM.JS.

Optimizing current JavaScript engines would lead only to minimal increase in performance. I have studied the problem a little, and the only thing you can optimize is to make a CPU that executes instructions in one cycle (opposed to exact cycle emulation) to save the extra function calls between cycles.

One question: does your C-based CPU execute instructions on a big "switch()" statement? I ask because I've read an argument that states that big switches perform poorly. It was suggested to have an array of function pointers instead.

unless your compiler is from 20 years ago, it will convert switch statements into jumptables automagically

nippur72 wrote:the alternative would be learning android programming, ndk and all the rest, honestly I'm not in the right mood. I would like to go for the browser/HTML if possible, even with the hack of ASM.JS.

IMHO that'd be a smart move.

nippur72 wrote:Optimizing current JavaScript engines would lead only to minimal increase in performance. I have studied the problem a little, and the only thing you can optimize is to make a CPU that executes instructions in one cycle (opposed to exact cycle emulation) to save the extra function calls between cycles.

AFAIK that's right as well.

nippur72 wrote:One question: does your C-based CPU execute instructions on a big "switch()" statement? I ask because I've read an argument that states that big switches perform poorly. It was suggested to have an array of function pointers instead.

I've used an array of function pointers. I've put the CPU code here: http://hugbox.org/pixel/external/denial/6502cpu.zip It's very easy to turn into asm.js. Could probably run tens of virtual VICs that way on a Raspberry Pi (single core). (My bottleneck is the scaling for HD video output.)