pouët.net

Go to bottom

Impossiblator 3 by Pers' Wastaiset Produktiot [web]

== BREAKING NEWS ==

Our beloved friend Xaztur was found dead at his home in August 1st, 2007
after being lost for two weeks. As for today (August 2nd), the cause of his
death is not known.

We would have put an "in memoriam" message in the demo itself, but it didn't
seem to suit anywhere. So we state it here.

  IN MEMORIAM

  XAZTUR OF PWP

  1979 - 2007

== ABOUT THE DEMO ==

This is Impossiblator 3, a demo for the unexpanded VIC-20.

THE DEMO REQUIRES A *REAL* PAL VIC-20, and does not even work properly in
all of them (see later in this document). And it definitely isn't watchable
with emulators; many effects will be lost altogether. So, DO NOT USE AN
EMULATOR! USE A REAL MACHINE OR WATCH A VIDEO.

You don't need to write the whole d64 image. The two small files (also
included separately as impo3.prg and impo3a) are enough.

== CONTACTING ==

viznut at iki.fi
http://www.pelulamu.net/pwp/
http://www.pelulamu.net/viznut/blog/
http://www.youtube.com/viznut

== VARIANTS OF VIC-20 ==

On the last day of making the demo and testing it with different VIC-20s I
noticed that there is variance in how some bit leaks occur in different
VIC-20 motherboards.

In the effects that use "floating bytes", those VIC-20s with a "wrong" type
of bus implementation will show vertical stripes half characters wide.

My current hypothesis:

This demo was made with a VIC-20 with an "AND polarity" bus. That is, the
nybbles that leak from the color memory will seem to be ANDed with the low
nybble of whatever byte is hanging on the video bus. I filled the color
memory with $F in the critical positions in order to stop the leak.

However, I also have one VIC-20 which has an "OR polarity" bus. Here, the
leaking nybbles will seem to be ORred, meaning that the proper leak stopper
would be $0 rather than $F.

== FOR EMULATOR AUTHORS ==

I'm working on a complete explanation of the VIC-20 hardware from the
software point of view. There are still some issues that need further
research, but here's the part the demo depends on and which is not properly
emulated by VICE:

=== Color memory fetches ===

Whenever either the CPU or the VIC reads a byte from a V-bus address
($0000-$1FFF, 8000-$9FFF), it also reads the corresponding color memory
nybble to the bus lines VD8-VD11.

This is important to know because the value sometimes leaks out (at least on
the motherboard revisions of the individual VIC-20 I use for development).

=== CPU memory access ===

Whenever the CPU reads from an unconnected V-bus address (on the unexpanded
machine: $0400-$0FFF, $9800-$9FFF), it reads the byte that was read by the
VIC chip on the previous cycle. Color RAM leaking does not occur.

Whenever the CPU reads the color memory, the high nybble of the byte will
contain the high nybble of the previous byte read by the VIC.

Whenever the CPU reads from an unconnected "C-bus" address (on the
unexpanded machine: $2000-$7FFF and $A000-$BFFF), it reads back its own last
byte: LDA $2345, for example, puts $23 in accumulator. JSR $6000 executes
RTS (opcode $60).

JSR $6000 is also an elegant way of killing current versions of VICE.

=== VIC memory access ===

Whenever the VIC reads a byte from an unconnected V-bus address, it reads
the byte that was left on VD0-VD7 on the previous bus cycle, ANDed by the
color memory nybble that was in VD8-VD11 prior to the memory read.

If the CPU accessed the "V-bus" area on the previous clock cycle, the VIC
will read the same byte. However, if the CPU accessed the "C-bus" area
instead, the VIC will read back whatever byte it accessed on the earlier
clock cycle.
Go to top