Warning by viznut/pwp

[Mike]

A new demo for unexpanded VIC-20 by viznut celebrating 20 years PwP. PAL only.

The checkerboard/whatever zoomer in the background was done with VIC accessing unconnected space.

[FD22]

Do we have to guess the URL?

[Wilson]

Very nice little demo and great to see another PWP prod!

The checkerboard/whatever zoomer in the background was done with VIC accessing unconnected space.

There was some debate on the consistency of that technique years back (even from Viznut himself) across board revisions, right? Did those inconsistencies ever get ironed out or is this another VSP situation? Either way, it's always really neat to see implemented!

Do we have to guess the URL?

http://www.pouet.net/prod.php?which=63854

[Mike]

Hi, Bryce! Nice to see you again.

There was some debate on the consistency of that technique years back (even from Viznut himself) across board revisions, right? Did those inconsistencies ever get ironed out or is this another VSP situation?

The screen results might differ, yes. VSP on the C64 might lead to corruption of RAM - the exact reasons for this had just be worked out some months ago in a thread in csdb.dk.

When the VIC accesses unconnected space on the VIC-20 and instead takes its pattern data from the instruction and data stream of the CPU, this is another mechanism at work. There are no known cases this would corrupt the internal RAM, and also the schematics of both mainboard revisions don't indicate this might be the case.

However, in the case of an external +3K RAM expansion (which couldn't be accessed by VIC), yet still pointing VIC to that address range, there might be a remote chance of corrupting the external RAM with the 2-prong version. A change how the VR/W signal is generated prevents this from happening with the CR (DIN power) version. You find a detailed analysis in the thread 'Anyone know what this board mod is?'.

Greetings,

Michael

[Wilson]

When the VIC accesses unconnected space on the VIC-20 and instead takes its pattern data from the instruction and data stream of the CPU, this is another mechanism at work. There are no known cases this would corrupt the internal RAM, and also the schematics of both mainboard revisions don't indicate this might be the case.

Well, that's good! Though if the whole demo looks wrong I don't know if that's a whole ton better. But I suppose the patterns are mostly recognizable between boards(?), and at least it's not a showstopper.

However, in the case of an external +3K RAM expansion (which couldn't be accessed by VIC), yet still pointing VIC to that address range, there might be a remote chance of corrupting the external RAM with the 2-prong version. A change how the VR/W signal is generated prevents this from happening with the CR (DIN power) version. You find a detailed analysis in the thread 'Anyone know what this board mod is?'.

Thanks for that, really interesting stuff!

[nanoflite]

Nice... really nice!

I think I understand the trick being used in the unconnected space graphics mode. Basically, the VIC reads pixel data from the data bus and with some tricks you can align the VIC reading the databus with the operand of the instruction, not the opcode. With some self modifying code, you can update the operand and hence construct an image.

Last year I acquired a CBM PET 4032, which contains a CRTC controller IC (6545) and I wonder if it could be pushed into the same trick. I still have to closely examine the schematics and the chip itself, but imagine the possibilities if we could break that boundary of a character based display into a bitmapped one

Cheers,
Johan

[Wilson]

Last year I acquired a CBM PET 4032, which contains a CRTC controller IC (6545) and I wonder if it could be pushed into the same trick. I still have to closely examine the schematics and the chip itself, but imagine the possibilities if we could break that boundary of a character based display into a bitmapped one

I'm afraid you're already late to that party.
http://www.pouet.net/prod.php?which=56410

[Mike]

I think I understand the trick being used in the unconnected space graphics mode. Basically, the VIC reads pixel data from the data bus and with some tricks you can align the VIC reading the databus with the operand of the instruction, not the opcode. With some self modifying code, you can update the operand and hence construct an image.

That had been somewhat hinted at in the text 'VIC-20 Frontiers', being further explored in the thread 'VIC-I anomalies in emulation', here in Denial and, for example, used in a WIP with the score display of Edge Grinder for VIC-20 (Format War forums).

However, fetching character data from unconnected memory this way only seems to work, when the instruction stream is located in internal memory. That limits use somewhat - you can't expect, for example, to create bigger bitmap displays than what could already been achieved by standard means (i.e. 160x192 pixels). What works well are vertical zoomers - it is possible to replicate rasters by executing the same instruction stream in several lines. Together with a few different routines you furthermore can produce a pattern of several pixels on/several pixels off, and both ideas together result in a simple checkerboard zoomer - and this is, what you see in the demo.

For bigger bitmapped resolutions, this doesn't work. Instead tokra and me explored the possibilities of CPU emulated DMA from the expansion port. And this one indeed works - see the series 'New Frontiers in VIC-Hires-Graphics'. None of the ideas involved had been tried out on the VIC-20 by those 'demo sceners' before that.

[tokra]

Topic drift: That Edge Grinder WIP looks amazing. How do you find these threads in other forums, Mike? Sadly there hasn't been any news in over a year on that project, or on the VIC20-Giana Sisters port for that matter...

[nanoflite]

The demo "No Pets Allowed" makes use of another technique. The screen size is reduced and the characters are only partially displayed. By choosing the right characters, you can make a bitmap image.

Ah, I will need to read up on the DMA technique then, but I doubt if it is applicable to the CRTC.

Cheers,
Johan

[Wilson]

The demo "No Pets Allowed" makes use of another technique. The screen size is reduced and the characters are only partially displayed. By choosing the right characters, you can make a bitmap image.

Yep, I thought the concept of bitmap graphics was was all you were after. I'm curious to know how else you would go about it. The technique used for the Vic-20 doesn't seem feasible based upon this block diagram, where the character ROM provides the only source for the data fed to the shift register used to output the video signal.