Reliving VIC20
Moderator: Moderators
- thegg
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Reliving VIC20
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.
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.
Re: Reliving VIC20
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
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Reliving VIC20
Nice! That's quite an achievement for a near 40 years hiatus.thegg wrote:I have put together a little technology demo that explores some of the VIC-20 capabilies that interest me.
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.
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.srowe wrote:Runs fine on my PAL VIC with an LCD TV. The screen is slightly off centre, the left border is smaller than the right.
-
- Vic 20 Hobbyist
- Posts: 107
- Joined: Wed Oct 02, 2013 1:54 am
- Location: Italy
Re: Reliving VIC20
Hello.
Runs fine on my PAL VIC with an LCD TV.
Bad on NTSC Vic.
Armando
Runs fine on my PAL VIC with an LCD TV.
Bad on NTSC Vic.
Armando
- thegg
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Re: Reliving VIC20
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
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
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Reliving VIC20
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.
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.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
WIP: MIDIcast BASIC extension
he/him/his
WIP: MIDIcast BASIC extension
he/him/his
- thegg
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Re: Reliving VIC20
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.
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
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Reliving VIC20
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
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
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Re: Reliving VIC20
Many thanks Michael. I've downloaded your example and will take a look when time allows.
Dave
Dave
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Reliving VIC20
- thegg
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Re: Reliving VIC20
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
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
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Reliving VIC20
$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.thegg wrote:that is what I was seeking, something in ROM specifically identifying the chip type installed.
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
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Reliving VIC20
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.Mike wrote:[...] $E475 [...] is not foolproof [...]
$EDE4 contains the expected value for NTSC, $05.
- thegg
- Vic 20 Amateur
- Posts: 69
- Joined: Mon Aug 30, 2021 4:49 am
- Location: England
- Occupation: retired
Re: Reliving VIC20
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
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
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Reliving VIC20
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.thegg wrote:[...] logically[,] is it not possible that a rom replacement such as JiffyDos might move the Vic initialisation code thus changing the content of $EDE4 [?] [...]
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.
Some program or the user might change $9000 before starting your program, for whatever reason.I am therefore wondering whether there is anything wrong with just inspecting the Vic say at $9000.