Reliving VIC20

[thegg]

Hi everyone,
Having just restarted playing with the VIC-20 after a lifetime of work, I wanted to find what I could do with an unexpanded machine and very rusty 6502 assembler knowledge. So I have put together a little technology demo that explores some of the VIC-20 capabilies that interest me.

There is some raster graphics switching using a VIA timer, a concise random number generator, a maze generator, a user defined animated graphic and some simple arithmetic functions.

At the moment I don't have any access to a real VIC-20 so I am running my code on the VICE xvic emulator. The program seems to run pretty well on the emulator at 50 fps. What I would like to know is whether it runs the same on the real hardware. So I would be really grateful if someone could try it out and let me know the result.

timer.zip

CBM prg Studio project

(30.44 KiB) Downloaded 55 times

[srowe]

Runs fine on my PAL VIC with an LCD TV. The screen is slightly off centre, the left border is smaller than the right.

[Mike]

I have put together a little technology demo that explores some of the VIC-20 capabilies that interest me.

Nice! That's quite an achievement for a near 40 years hiatus.

Two points to note though:

• It's not necessary to protect RAM in the BASIC stub with the POKEs to 55/56. Once you leave BASIC with SYS, there's nothing that could be overwritten by the BASIC interpreter. Furthermore, the whole appended machine code already is protected as 45/46 is set behind the loaded data of the file. Actually, setting 55/56 *below* 45/46 (what you do effectively) would confuse the interpreter, if you were to return to BASIC.
• Your NMI timer routine does not 'survive' a press on the RESTORE key. The easiest way to handle this is by first clearing all bottom 7 bits in the IER, re-routing the NMI vector with all possible interrupt sources turned off and then (re-)enabling only Timer 1.

Runs fine on my PAL VIC with an LCD TV. The screen is slightly off centre, the left border is smaller than the right.

I didn't yet check with my VIC-20, but the code uses the same value for XPOS than the (PAL) KERNAL default (12) for the upper part, so the standard display window should also appear off centre on your setup.

[armypavarmy]

Hello.
Runs fine on my PAL VIC with an LCD TV.

Bad on NTSC Vic.

Armando

[thegg]

Thank you all for the very quick response.
Mike thanks for taking the trouble to look at the code. Your comments are appreciated and I shall look into them in some detail.
One thing I've taken note of from all the replies is that I need to think both PAL and NTSC when posting in the future.

Dave

[chysn]

Welcome to the forum!

I tried your program (timer.prg) on an NTSC hardware VIC-20. It looks more-or-less as it does on the NTSC VIC under VICE.

[thegg]

Doesn't really look as intended on NTSC! Not surprising as I was working from the specs for the PAL version.

My understanding from the Denial WIKI is that the NTSC VIC chip is different to the PAL version in screen size, frame rate and lines per frame. Are these the only practical differences I need to consider when developing for both versions.

Also what is the best way to test which chip version is present from software. For example, is it sufficient just to look at the VIC register at $9000.

Many thanks for all responses.

[Mike]

Armando, Jason,

The program relies on the timing of a PAL VIC-20 to do the raster effect. At the moment, there is no provision inside to handle the timing of a NTSC VIC-20 so it simply does not work there!

Dave, it is no big issue to do a NTSC version of the demo. You just need to take the different number of cycles/line (71 on PAL, 65 on NTSC) and different number of rasters (312 on PAL, 261 on NTSC non-interlaced) in account, there's also some idiosyncracy how $9004 changes relative to the HSync position. Finally the XPOS and YPOS default values are different between PAL and NTSC. Using offsets on the VIC register default values at $EDE4 helps a lot here.

You might consider a look how I do things with MG Raster (you'll need at least a +8K RAM expansion). This is an example of a cycle-exact stable raster - it's synced to a given horizontal position, so changes of VIC registers happen at the left and right edge of the display window. Source is included. If you look closely, you'll notice there's still a single pixel delay, but that's due to the pixel serializer in the VIC chip and cannot be avoided.

Greetings,

Michael

[thegg]

Many thanks Michael. I've downloaded your example and will take a look when time allows.

Dave

[chysn]

Also what is the best way to test which chip version is present from software. For example, is it sufficient just to look at the VIC register at $9000.

There's surely a bunch of ways, but

Code: Select all

bit $e475
bmi IS_PAL
; ~ or ~
bpl IS_NTSC

[thegg]

chysn
Thanks, that is what I was seeking, something in ROM specifically identifying the chip type installed.

Using the various advice above (except for disabling the Restore NMI) I have modified the demo to adjust the various timing values according to whether it is running on a PAL or NTSC machine. The update is attached below. I would very much appreciate it if someone can check how it runs on real hardware. It seems ok on VICE.

Dave

timerV2.zip

(31.72 KiB) Downloaded 48 times

[Mike]

that is what I was seeking, something in ROM specifically identifying the chip type installed.

$E475 is a spare byte to define the ROM checksum, the byte which happens to be different for PAL and NTSC KERNALs due to all the differences that need to be accounted for, but it is not especially related to the installed VIC type.

That test is not foolproof either, and would need to be checked against the JiffyDOS KERNAL ROMs at least. If they get the checksum byte right, the test might fail in one or even both cases, i.e. falsely identify both ROMs as either PAL or NTSC, or get it the other way round.

For my part, I prefer checking the default register value for XPOS ($9000) in $EDE4, which is 5 for NTSC or 12 for PAL. Either I make a comparison for changes not directly related to VIC itself (like using different VIA timer values) or I derive values for the VIC registers themselves by applying offsets. In the latter case, the same code can be used for PAL and NTSC, because it then is TV system neutral.

Other people like to test the VIC chip itself, for example by checking for raster values in $9004 that exist in PAL but not NTSC. That's somewhat over-engineered IMO, as the only motivation for this is to guard against the case of someone using a PAL KERNAL with a NTSC VIC or vice versa. Doing this however is no good idea - not only are the VIC registers wrongly initialised, but the jiffy clock also gets wrong timer values, and the timer constants for RS232 are also different!

[Mike]

[...] $E475 [...] is not foolproof [...]

I checked against the Japanese VIC-1001 KERNAL (901486-02). Here, the value at $E475 is $D6, which falsely identifies the VIC-1001 as PAL.

$EDE4 contains the expected value for NTSC, $05.

[thegg]

Michael thanks for the additional information.

Since your last comment I have been chewing over the possibility of roms being different. I accept that your preference is based on loads of experience, but logically is it not possible that a rom replacement such as JiffyDos might move the Vic initialisation code thus changing the content of $EDE4. I am therefore wondering whether there is anything wrong with just inspecting the Vic say at $9000.

Thank you again for your responses.

I am assuming that as nobody has reported any issues, that my test program runs ok on an NTSC machine.

Dave

[Mike]

[...] logically[,] is it not possible that a rom replacement such as JiffyDos might move the Vic initialisation code thus changing the content of $EDE4 [?] [...]

That is actually very unlikely. KERNAL ROM modifications have a long history and a large body of experience. One important lesson is not to move or change code or data (especially not unrelated stuff) unless absolutely necessary for the modifications to work.

So JiffyDOS somewhat deliberately removed the Tape and RS232 routines to make room for the new routines of the faster IEC protocol. Use of tape or RS232 triggers an ?ILLEGAL DEVICE NUMBER error with JiffyDOS. But everything else still is at its old place.

If a KERNAL modification moved the VIC init table at $EDE4 to another place, that would break a lot of programs.

I am therefore wondering whether there is anything wrong with just inspecting the Vic say at $9000.

Some program or the user might change $9000 before starting your program, for whatever reason.