In the 1994 I started to develop a C64 emulator for PC in the free time. In that
periods I had a 286 PC, so the speed of emulation would be the main porpoise,
because I think that with 16Mhz I must emulate a CPU of 1Mhz, the graphics, ...
But it was possible to develop an emulator for a 286? (at that time I don't known
that there's emulators, and some of them can go in 286 with little speed down.
So, I try to check how fast was the cpu emulation:
I write a (more incomplete) M6510 object oriented Pascal emulation: too slow!
I write a M6510 object oriented Pascal emulation with all code replaced
by assembly language: little better
During this point I find a real emulator that goes in the 286 (the C64S) and than other
that go in 386 machine. So I decide to use total assembler for making the emulator
(assembler is the my preferred language): the C++ language that I think to use
after the previous test was erased (I look for C for implementing the graphics more
faster that with Pascal).
I write the M6510 emulation cycle based (well, an operation is made in a cycle,
the eventually other are sleep cycle) using IRQ clock timing.
Yes, the other use polling to emulate vic and cpu, but I was thought that, even
if now I use a 286 to develop the emulator, when it will be finished I had a more
powerful computer, so the timing will be accurate.
Note that this features was done with the documentation that I had in that time
(some commodore manuals); vic and 64doc article, undocumented opcodes,... I never
known their existence. In fact, even if the cpu is timing clocked at 1Mhz, the
graphics (line by line) is done at the full speed of cpu, without cycles.
This choose was done because I think that when I will have a powerful computer,
I will find documentation for making Vic cycle exactly, and I can test them,
because with the 286 if we use true Cpu timing, the vic was slow (or vice versa).
After making the M6510 emulation I try to emulate the Vic. The main porpoise for
me was to emulate the border like in the Commodore, so 320*200 int 10h mode
was not to used. But fortunately, I had a copy of Xlib 4.0, so I decide to use
Mode X 360*240 (I did not know how mode X works, but in the Xlib there's the free
source code).
I use 3 memory pages:
The Main 360*240 for Commodore output screen
The Second 360*240 for emulation option panels
The rest of graphic for a split screen for drawing the Commodore/PC keyboard.
Well, the keyboard in the split screen was the better idea that I could be thought:
if you use an actually emulator, which keys is the - or = or ... Well you must see
the documentation, and if you want to write the special commodore graphics chars
you must see the commodore keyboard layout.
The emulation of Vic use 24/25 chars, scrolling (even if the 38/40 was not inserted
because I not had more time, the Vic emulation is done with a high quantity of
macro code, so this step was very simple to insert) and all graphics mode.
Sprites? No, I had no more time.
Cia emulation: very little.
SID emulation: nothing.
Joystick emulation: none.
The Utilities
Even if the emulator was the main project, I had write more code that will be
useful for the emulator.
A 6510 disassembler with automatic comment (I use this for disassembly the
Kernal and Basic, and all the assembler code I need to study)
Some assembler utility for reading the tape cassette
Well, the reading of Kernal and Basic ROM, and the my C64 programs from the tape
was an strong result.
I had build a PC to Commodore RS-232 converter (using an Italian kit).
Then I had loading the Kernal, Basic, and the Char from the Commodore to the PC.
But first, for the tape, I had manually build a connector for PC RS-232 to Commodore
Tape Datassette, then I try to understand how the readed bits means.
Nothing for me.
So, one day I manually copied (from the screen) the byte code of Turbo Tape utility
program, and then I started to study its assembler code, because the Kernal
Commodore routine for reading from tape was too difficult to understand from
my Kernal disassembly.
With this I read Turbo saved program, and because I understand how a program can be
written to a tape, I was able to read the Commodore format without using the Kernal
disassembly. Then I had write other utility for reading some commercial cassette
that I had. The format of the readed files are proprietary, and it is supported by
the actual Java Commodore emulator.
Why other files formats?
Because one porpoise of the emulator was to reproduce even the tape loading as in the
Commodore. Well, if you think that a emulator fast loader is to use always, then you
have never loading the "Last Ninja 2" cassette. Nice graphics and sound too during
the loading...
Another features of the emulator was to reproduce the cartridge, but that support
was never added.
commodore 64
Ice Team Free Software Group