VIC-I anomalies in emulation

Basic and Machine Language

Moderator: Moderators

carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

VIC-I anomalies in emulation

Post by carlsson »

This thread continues from the one about Diamond Hunt in Games section. I feel we went a bit off-topic there. Although I'm a moderator, I could no longer find the button to split or move a topic, only to delete posts? I suppose this thread to some extent would fit in Hardware too, and there is no section exclusive about emulation.
Mike wrote:There is an if-clause which checks for char_set being at $1E00.
Boo! :wink:

Code: Select all

Block   VIC address   CPU address   contents
16..19  16384..20479  32768..36863  ROM char set (mirror copy)
Well, the block can never exceed 15, so it should be doable in another, simpler way. I'll have a look too and wait for any VICE team responses.

It doesn't surprise me that there are other glitches. It was not until version 1.7 of VICE that had a semi-decent emulation, and unless I'm mistaken, no major improvements have happened since it was rewritten and verified among the contemporary demos.

Your colour RAM experiment program fails terribly on a real VIC:

Image

POKE 36869,244 (screen at $1E00, chars at $9000) or POKE 36869,4 (screen at $9000, chars at $8000) makes funny things happen with the other register values. One may be able to POKE the display back, but it has to be in a certain order. The memory at $9000 corresponds to the VIC-I registers + the two VIA registers, among other things.

POKE 36869,245 (screen at $1E00, chars at $9400) yields garbage, but the screen behaves correctly. This equals colour memory.

POKE 36869,246 (chars at $9800) also yields garbage, being unused I/O block 2.

POKE 36869,247 (chars at $9C00) is identical to the one before, but pointing into I/O block 3 instead.

Here's another mildly interesting mode:
POKE 648,28:POKE 36866,22:POKE 36869,255

It sets both video matrix and chars to 7168 ($1C00), meaning that each character definition depends on what is on screen at that position. Dunno if it useable, but it works as expected in the emulator. :)
Anders Carlsson

Image Image Image Image Image
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

I see that Jim Butterfield continued his series about VIC-20 video in issues June - July - August 1983, of which I have neither issue. Maybe someone else has them and it would be worth reading and scan, although I doubt he would know anything that isn't already known by today. The July issue has an article about bitmapping too.
Anders Carlsson

Image Image Image Image Image
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

what are the odds!?

i only have one copy of compute, and it is May 1983 ;(

chris
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

i can scan the arcticle in from may if you want, and cut down on the scanning for someone else who has the other issues.

chris
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Re: VIC-I anomalies in emulation

Post by Jeff-20 »

carlsson wrote:...Although I'm a moderator, I could no longer find the button to split or move a topic, only to delete posts?
There are no little icons at the bottom left? Let me know if your status as a mod was somehow changed. I'll fix it if I can.
High Scores, Links, and Jeff's Basic Games page.
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

Chris: the May 1983 article is already scanned, OCR:ed and put online via the Atarimagazines website linked to in the other thread;

http://www.atarimagazines.com/compute/i ... _Video.php

There may be other COMPUTE! archives on the Internet, I didn't look closer. I have a folder of cut-outs from various issues, and I believe some pages are from the mentioned issues, but the cut-outs are only game listings. Stupid former owner who bought expensive magazines, ripped out the interesting articles and threw the rest of the magazines. My big brother got this folder of cut-outs along with the remaining set of issues the former owner had not had time to go through when he bought his second hand C64 in the mid 80'ties.

And Jeff: no, there are no little icons in the bottom left. I dunno about status (I'm still unmarried and a bit overweight), but I do have the buttons to delete posts and log IP, so it can not be completely lost.
Anders Carlsson

Image Image Image Image Image
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

thanks, i won't bring the magazine to work then.

just to let you know, i do have the little icons on the left.

wonder if boray and schema do too?

chris
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

:oops: That far down to the left? Now I see them. I didn't yesterday. For some reason, I thought the mechanism to split topics etc had one of these buttons on each message. Now the next question, is it possible to split a thread and move some of the messages to another, already existing thread and get them linked before the first?

Update: Nah, that would require database modulation not possible through the forum interface. Maybe I'm too used to advanced conference systems using custom clients which lets the admin and moderators do almost anything.
Anders Carlsson

Image Image Image Image Image
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

Just play around with the buttons for a while. I don't think you can really hurt anything.
High Scores, Links, and Jeff's Basic Games page.
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Post by Boray »

More suggestions. You are welcome to forward them to the VICE developers:::

A smooth option. Just like the Pal Emulation option, but without any change of the colors.

Graininess. A settings file like the palette, but this is a 8x16 table where you enter a value of how much distortion the color combination should have. For example where cyan and white cross, there would be a high value. Where blue and white cross, there would be a zero as there is no graininess in that combination.

Stripes. This could be part of the palette. A value for each color of how visible the vertical stripe pattern should be for this color.

These could be useful in all of the VICE emulators (but in the c64 etc, there would be a 16x16 grid). It could be 16x16 on the vic too, just that all of them not are used.

This could all be implemented as an graphical effect on the picture after the normal emulation process.

/Anders
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
Schlowski
NoMess!
Posts: 892
Joined: Tue Jun 08, 2004 12:20 pm

Post by Schlowski »

Something I found out this evening is that the timings in VICE and on real hardware seem to differ...

It always bothered me if 'external' RAM, i.e. RAm expansions are somewhat slower than the internal 5k, so I made a very small test prog:

Code: Select all

10 ADR=7000
20 T1=TI
30 FORI=0TO255
40 FORT=0TO9
50 POKEADR+T,I
60 NEXT
70 NEXT
80 T1=TI-T1
90 PRINT"TIME:"T1
Then I tested in VICE (PAL emulation) and on real PAL VIC
(columns are MEMORY, ADR value, VICE time result, real VIC time result)
Unexp. 7000 688 693
3k 7000 688 693
3k 2000 698 703
3kSuper 7000 --- 703
3kSuper 2000 --- 713
8k 7000 688 693
8k 9000 687 692
16k 7000 688 693
16k 17000 687 691
24k 7000 688 693
24k 25000 687 691
$A000 40960 687 691

(damned, this should be a nice aligned table :-( )

To be sure I tested again on another PAL VIC and got the same results. So emulation seems to be a tick too fast. Interesting for me was that changing between PAL and NTSC emulation in VICE makes no difference - but as far as I remember the NTSC and PAL VIC have slightly different oscillators and should have different speed!? Not as much as PAL and NTSC C=64, but nevertheless noticable.

Some of the results where expected (Super Expander slows down the execution of basic programs due to expanded keyword recognition, RAM expansions 8,16 and 14k behave identical) and some are not (3k RAM expansion behaves different to other RAM expansions).

Execution of the program in internal RAM (unexp. and 8-24k expansion) and in expanded RAM (3k) makes no difference, but poking in internal RAM (ADR=7000) and external RAM (ADR=9000, 17000,25000) makes a slight difference, poking in external RAM (ADR=2000) a noticable difference. This last difference is in emulation too which seems to indicate a good understanding of some internals.

So what is going on in the 3k expansion area that makes such a difference to other areas?

And can somebody of you check the timing results on a real NTSC VIC? Would be interesting to see these results too...

Björg
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

I presume that most of the differences are due to that adding 1 to 300 needs less time in the BASIC interpreter than adding 1 to 30000[*]. Your program only executes 2560 accesses with POKE during 11 or so seconds. Any differences in access time will be swamped by interrupts and other effects.

You might try this program instead:

Code: Select all

1 FORT=0TO12:READA:POKE673+T,A:NEXT
2 POKE251,0:POKE252,120
3 T1=TI:FORT=0TO15:SYS673:NEXT:T2=TI
4 PRINTT2-T1
5 DATA169,0,170,168,145,251,200,208,251,232,208,248,96
It executes 1048576 accesses to the 256 byte page pointed to by 251, 252 - and needs roughly 11 seconds, too. If there are any differences between the RAM expansions, or to VICE you'll see them here. Can't test it out ATM.

Greetings,

Michael

[*]: to illustrate this point:

Code: Select all

1 A=0:B=300:C=1
2 T1=TI:FORT=0TO999:A=B+C:NEXT:T2=TI
3 PRINTT2-T1
B=300 => prints 176
B=3000 => prints 184
B=30000 => prints 191

Edit: corrected the POKE in line 1 to POKE 673+T, ...
Last edited by Mike on Wed Jan 18, 2006 7:32 am, edited 1 time in total.
User avatar
Schlowski
NoMess!
Posts: 892
Joined: Tue Jun 08, 2004 12:20 pm

Post by Schlowski »

Hi Mike!

I understand what you mean but I can make as much runs as I want, I always get the same results so there is no problem with different timing on a given machine - only a difference between emulation and real VIC.
The precision of my timing method is bound to the 'timer tick' but it's runtime is long enough to be quite accurate, more than 10 seconds...

And the difference for 3k expansion RAM remains unexplained, of course...

Björg

PS: Immer wieder schön, sich mit Landsleuten in Fremdsprachen zu unterhalten ;-)
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Post by Boray »

Yes, the NTSC emulation is not accurate at all in VICE. Try my QBENCH program on VICE and you will see:
http://user.tninet.se/~pug510w/datormuseum/qbench.html

A NTSC VICE is almost as fast as a PAL VIC...

Btw, Why are basic programs running faster when you have expansion ram if the expansion ram in fact is slower? :lol:

/Anders
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
Schlowski
NoMess!
Posts: 892
Joined: Tue Jun 08, 2004 12:20 pm

Post by Schlowski »

Cool link, I totally forgot about your QBench...

Maybe because I like to program myself and only trust my own bugs ...ahm... features ;-)

Timing seems to be very interesting in the VIC, maybe the 3k RAM area is somehow influenced by the VIC-I chip? Areas which will be accessed by VIC chip and processor are slower then other areas, as far as I remember because both chips have to share the same access lines. When one chip accesses screen memory, the other chip is not allowed to do so.

With an oscilloscope and some rough idea what electrons do in computers one could find out, i guess - but not me :-)

Björg
Post Reply