| 1 |
cebix |
1.1 |
<HTML> |
| 2 |
|
|
<HEAD> |
| 3 |
|
|
<TITLE>Technical info</TITLE> |
| 4 |
|
|
</HEAD> |
| 5 |
|
|
<BODY> |
| 6 |
|
|
|
| 7 |
|
|
<H1>Technical info</H1> |
| 8 |
|
|
|
| 9 |
|
|
<CITE> |
| 10 |
|
|
"Known?" said Gandalf.<BR> |
| 11 |
|
|
"I have known much that only the Wise know, Frodo." |
| 12 |
|
|
</CITE> |
| 13 |
|
|
|
| 14 |
|
|
<HR> |
| 15 |
|
|
|
| 16 |
|
|
Frodo tries to exactly imitate C64 hardware features. Now the 64's hardware |
| 17 |
|
|
(esp. the graphics chip "VIC-II") has a rather simple design resulting in |
| 18 |
|
|
many of the internal processes coming to the "outside". So there are lots |
| 19 |
|
|
of "undocumented features" you can do effects with the designers never |
| 20 |
|
|
dared to dream about.<P> |
| 21 |
|
|
|
| 22 |
|
|
Frodo uses a line-by-line emulation, i.e. the function of the VIC and the |
| 23 |
|
|
processor (6510) are emulated for one raster line of the C64 screen at |
| 24 |
|
|
times. In practice, Frodo runs VIC and 6510 alternately for 63 simulated |
| 25 |
|
|
cycles each (corresponding to one raster line). At first, it emulates the |
| 26 |
|
|
processor for 63 cycles, then switches over to the VIC that paints one |
| 27 |
|
|
pixel row to the screen, then again 63 cycles processor, and so on... If |
| 28 |
|
|
the 1541 processor emulation is turned on, 6510 and 6502 (in the 1541) |
| 29 |
|
|
instructions are executed by Frodo in an interleaved fashion.<P> |
| 30 |
|
|
|
| 31 |
|
|
Even though this is a heavy simplification of the processes in a real C64, |
| 32 |
|
|
it lets you perfectly emulate many graphical effects possible on the C64, |
| 33 |
|
|
e.g. FLD, DYCP, hyperscreen and many more. But this method has one big |
| 34 |
|
|
disadvantage: Changes made to VIC registers by the processor in the middle |
| 35 |
|
|
of a raster line will only take effect at the start of the next line. E.g. |
| 36 |
|
|
you can't change the border color in the middle of a line, the color change |
| 37 |
|
|
takes place in the next line. Therefore, very sophisticated techniques |
| 38 |
|
|
depending on the exact position of a register change can't be emulated. For |
| 39 |
|
|
instance, it is no problem to open the top and bottom border, but opening |
| 40 |
|
|
the left and right border is impossible (and therefore not implemented in |
| 41 |
|
|
the emulation).<P> |
| 42 |
|
|
|
| 43 |
|
|
Frodo SC goes one step further by switching between VIC and 6510 in every |
| 44 |
|
|
cycle and precisely emulating the internal functions. Modifications to |
| 45 |
|
|
VIC registers become visible immediately in the next clock phase and |
| 46 |
|
|
therefore it can even emulate effects that depend on the exact position |
| 47 |
|
|
of a register change within a raster line, e.g. special FLI routines, |
| 48 |
|
|
opening the left/right border, linecrunch, DMA delay, multiple repeated |
| 49 |
|
|
sprite lines and executing programs in open address spaces ($de00-$dfff) |
| 50 |
|
|
and in the color RAM. The 6510 emulation is also more precise and does |
| 51 |
|
|
the same memory accesses as the real 6510, even the "unnecessary" ones |
| 52 |
|
|
that come from design weaknesses of the 6510 and are not needed for the |
| 53 |
|
|
function of single opcodes (e.g. in an instruction sequence like |
| 54 |
|
|
INX:INX:INX:INX, the 6510 reads every opcode twice).<P> |
| 55 |
|
|
|
| 56 |
|
|
A detailed technical description of the VIC-II can be found in an |
| 57 |
|
|
<A HREF="http://www.uni-mainz.de/~bauec002/VIC-Article.gz">article</A> |
| 58 |
|
|
I wrote (32k gzipped). |
| 59 |
|
|
|
| 60 |
|
|
</BODY> |
| 61 |
|
|
</HTML> |
