EXPLORING THE FRONTIERS OF THE VIC-20 Some people claim that today's VIC-20 emulators are quite accurate. However, their inaccuracy can be proven even with simple BASIC oneliners. These work on real VIC-20's (PAL), but all known emulators fail miserably with them. POKE36864,0:POKE36866,162 Everyone who has randomly poked around the VIC-20 has found that large values in the $9002 register (36866) sometimes give out strange "garbled" screens. However, the above combination is perhaps the strangest of them all: the screen area starts four pixels later on odd scanlines than on even ones. On some text rows, the screen memory offsets also differ on every other scanline. Explaining this behaviour requires a good theory on the cyclewise functioning of the VIC chip especially during scanline changes. I don't yet have a good proven theory for it - only some wild guesses. I also have a machine that sometimes "randomly" changes the screen colours when using this trick. I currently regard it as a failure in the individual video chip, but it may also reveal a new kind of interconnection between the video registers. POKE36869,245:POKE2,2:SYS2 Character memory on unconnected space and CPU halted. When reading from the unconnected space, the VIC rereads the last byte transferred on the data bus. In this case, as there is no CPU activity between the screen memory fetch and the character memory fetch, the same byte is read on both fetches. In practice, this looks like a graphics mode that reads pixels linearly from the screen memory. However, the "pixels" are 8 or 16 pixels high and it therefore requires raster tricks to get more vertical resolution. Why would this kind of graphics mode be usable? Well, you can get a screenful of fully addressable 1x2-sized pixels that fit in 4K of RAM. The total picture size, all the way to the overscan, would be 224x144 or 232x140 pixels. POKE36869,80:POKE2,2:SYS2 The other way around: screen memory on unconnected space and CPU halted. This gives a different static screen depending on the state in which the machine was during the HLT instruction (opcode 2). Explaining this may also reveal something extraordinary. POKE36879,8:POKE36869,85 Screen memory and character memory both set on unconnected space. Thus, the visible pixels come entirely from the CPU activity (excluding the colours: the colour memory is always connected to $9400..$97FF). With proper code, it is possible to force any pixel combination on any scanline. This technique can be very useful for some effects. Although the VIC-I is a very simple chip and its documented functionality is very easy to understand, it is also surprisingly easy to get it into anomalies like this. Virtually all programmers in the last two decades have ignored these anomalies as "bugs" or "unusable features" as they haven't been able to understand them. Therefore, emulators don't support them either. The VIC-II of the C-64 is far more complicated, but due to the activity of the demo coders since the early days, there are very few unexplored and unused anomalies left. The VIC-20, however, is still quite a "virgin" platform, with a lot of untapped potential. Sometimes even surprising features are revealed from supposedly well-known areas: for instance, for over two decades, the dogma said that the three "melodical" sound channels only give out pulse wave with a 1:1 ratio. However, in the year 2003, it was revealed that totally new waveforms are possible because the inner workings of the sound channels are more complicated than anyone had assumed. So, here's your chance: join the VIC-20 scene before it's too late! You may still be able to get your name to the history books by revealing new features and by inventing new and revolutionary tricks that get used by generations of coders thereafter. The VIC-20 scene is now experiencing an era of exploration similar to what the C-64 scene experienced in the late 1980's. Be there, and you'll have something wonderful to tell your grandchildren.