JC64: a C64 java software emulator
|
JC64: a C64 java software emulator
|
|
|
|
|
At 16/08/99 I start to build a new emulator using the Java language, because now
I have more free time.
But many months before, I thought how to build a new emulator using an high level
language. From 03/12/98 to 06/12/98 I write a peace of 6510 emulation in C++
language, but after 8h 50m I stop the work. C++ is the natural choose for having
a multiplatform emulator, a speed emulation, and a clean oriented project.
In that period however, I was using Java. Java has some useful characteristic:
it is multiplatform for principe, it's object oriented, and due to the fact that
he not allow direct access to pointer, he is more simple to program and debug.
Oh, I'm an assembler born programmer, so I must like the direct access to the
pointer. But, on the other hand, I like a well documented software and I think
that one Java point of merit is to have made a standard way to document the
software, and also the documentation is part of the program (otherwise how can I
know the interface -in the C++ sense- of one class?).
But how to make an emulator with an interpretate language? If one of you say me
to write an emulator using the Basic language (and use only one platform, so machine
optimization are allowed) I probably think that not is the case of lose time.
You probably think the same about Java.
I don't think that a real speed emulation may be actually obtained with Java
language without use native code, but when I chosen to use interrupt for having
real cpu cycle emulation in my assembler emulation on a 286, I was thought equal.
But now my assembler emulator run ok with the actual computer, so there will
be one day that the Java emulator may be used without problem because the speed
of computer become high day by day.
If you now think that I'm coding the emulator for reaches this day the short as
possible, you are wrong.
Actually my porpoise are these:
A side note: I think that VICE will be the definitive Commodore emulator. So this emulator will be useful only if the above point should be follow. In fact, for a demo coders, an emulator with an Vic monitor will be very good, even if this emulator use all the resources of his machine to run. Oh, for Vic monitor I look for a monitor that halt the emulation in some Vic line and cycle for seeing how cycle of Cpu instruction is executed. So very timing based software may be developed in this emulator. This monitor will could be build because the emulation is signals based, e.g. it reproduce signals like clock for having real emulation.
I want to show you the architecture of the emulator with some examples.
If one builds a class that emulate the cpu for the C64 emulator, he probably
use the I/O port bits with the C64 significant: bit 0 is LORAM, bit 1 is HIRAM, ...
This choose is sensate: it means speed and 100% real emulation.
But this is not a good object oriented programming: a M6510 cpu can be used in the
C64, but also in other 8-bit old machine that something would to emulate using the
same class without making big changes. So the M6510 class use the
abstract class M6510IO that performs the I/O operation needed by the cpu.
M6510IO is abstract, so in a C64 emulator I create the
C64M6510IO that performs the operation like in the C64: bit 0 is LORAM,
..., the other people create the xxM6510IO for his xx
machine.
What about VicII? The VicII class is an abstract class that performs
his operations without know that it is in a C64 emulator. The abstract is because
exists two kind of Vic: PAL and NTSC, so the implementation is different for the
two types: M6569 implements the PAL, M6567 the NTSC.
But how about the bus operations? The speed up way is to build the class that when
read from memory, the upper 4 bits of readed data may be read from Color RAM of
the C64, but because the VicII chip may be used in other 8-bit machine, this is not
the right choose.
The solution is to have an Bus class that performs bus operation for
all the chips that can access to the bus (in the C64 these are Cpu, Vic, Cartridge).
This class is abstract, so I must create the C64Bus class for emulating
the bus of C64: this class know that Vic read the 4 upper bits from color ram, that
in some case one can read the previous byte that the Cpu or the Vic was reading the
half cycle before, ...
Now you probably have understand my philosophy, so look for optimization and 100%
emulation.
In the first time, I think that the AEC signal may not be emulated, but I see
that there are the cases that this is not true (see DMA delay technique). So I
emulate the AEC but with some difference from the real working: AEC is emulate
correctly only in phase 2 of clock when Vic or Cpu may work, not in phase 1
when only the Vic uses the bus. This means speed up emulation because I don't
have to add more synchronization for Vic thread and Cpu thread for manage
correctly the AEC in phase 1.
Well, how can you help me?
This program is a GPL program being developed at Souceforge, so look at
JC64 developer pages.
I need your help.
Actually, this is the state of emulator:
The VicII use a 1 to 1 pixel generation based onto dot clock: this is a very
experimental code, but it seems to go ok (there's some minor question due to
internal vic buffer to be used, so more debug is needed).
A side note: with this chooice, the coding of graphics and sprites generation,
with collision (also to border area) and priority have take only 3 hours (on a
total of about 17 hours for all the vic emulation).
If you run the emulator, you must see something like this:
However, actual frame rate is very, very low. Think of a value; no, you don't think right. The frame rate is about 0.125 frame/sec in a PII 266Mhz with Linux (0.25 f/sec with little patch)!!!.
The fact is that actual JVM spend about 90% of cpu time execution to synchronize with the threads that emulator uses. So, only when native threads may run at the expected speed, this emulator may obtain some high frame rate.
 |
commodore 64 |
Ice Team Free Software Group |