targets vic20

Commodore VIC20 emulation of Xemu

Foreword: this VIC-20 emulator is incomplete, unfinished, and very incorrect, even the CPU type is not what a real VIC-20 used! You really don't want to use this emulator as your main VIC-20 experience :)

The reason of this emulator: it's a great test bed for Commodore LCD emulation. Commodore VIC-20 is a much more known machine, and basically also uses the VIAs as the Commodore LCD. Commodore VIC-20 is proven to be able to use serial IEC bus, while I have/had (?) problems with that with Commodore LCD emulation. Thus, if I can do it well on a Commodore VIC-20 emulation, I can say, I do it well, so I can try to hook the IEC part to the Commodore LCD emulation. And so on. Also, VIC-20 is a "simple" machine enough to emulate, compared eg to a Commodore 64 (which would also need CIAs and not VIAs to be emulated).

Other reason: my "more serious" emulator (Xep128, also on github) is about being just too complex to "play" with it for "quick modifications" to try things out about the basics of writing emulators (ie using SDL, the timing code, in the future: audio sync, etc). It seems it's better to do it here, with more simple emulators, and using the results in the Xep128 project as well.

About the CPU: since Commodore LCD uses software compatible CPU (exact type is not very known) of 65C02, my experimental VIC-20 emulator also uses that! That's a direct attack against poor VIC-20 :) as it used 6502! So, of course things like illegal opcodes won't work using my emulator!

List of stupidities of my VIC-20 emulator

• 65C02 as the CPU, not 6502 (no illegal opcodes), this is by intent!
• Exact screen origins, timings are not exact
• Scanline based emulation, parameters can only change after a whole scanline
• No sound is emulated
• No tape, or serial IEC bus is emulated (floppy drive)
• NMI handling, RUN/STOP + RESTORE does not work
• Only "PAL" system is emulated
• VIA emulation is unfinished, and maybe quite inaccurate as well

Some extra features

Command line option examples:

@1 @8 @16 @24 @40

@1 @8 @16 @24 @40 -

@1 @8 @16 @24 @40 something.prg

• The @ options configures the memory expansions at the given kilobyte. Of course you can specify less (or none) of them.
• The - option causes to "boot" into monitor mode. The monitor is currently unusable, only x (exit) command works :)
• If some filename is given (ie not start with @ or -) it tried to be loaded and auto-started, as a BASIC program (or ML one, with BASIC 'stub').
• No filename and - causes to boot into BASIC.

NOTE: currently no check about illegal .prg, which would exceed the available configured RAM, or even overwriting ROM with bogus start address with the two first bytes, etc. Also, it's possible that the program requires other memory configuration, so the BASIC start is different, this is not handled autmatically either ...

Functionality of auto-load (currently the only way to load a program ...) requires the emu ROM to be usable, you can find it in the rom/ directory.

You can use numeric key pad arrow keys as the "joystick", "5" is the fire. Optionally, you can use the right CTRL of keypad button '0' for fire too.

You can try to use a supported Game Controller / Joystick as well (I've tested with XBox-360 controller). Currently, there is no mapping of controls, which can be a big problem. Only axes 0/1 can be used as the joystick, but it's hard to tell, which controls they are on your joystick (maybe even vertical/horizontal is mixed ...), or the "hats" can be used as well. Every buttons are used as the "fire" button.