Ah, cool. That should of course be much more straightforward.Mike wrote:No, I'm using a much simpler clock slide instead.
Raster split and $9002
Moderator: Moderators
- pixel
- Vic 20 Scientist
- Posts: 1357
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Raster split and $9002
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Raster split and $9002
The article will construct the whole topic on first principles, i.e. with the exception of four constants/parameters everything can be derived on white paper.
There are two relevant constants - the timer 1 period; and the "phase" value, which is used for the interrupt delay/jitter compensation - which both can be derived either empirically or - more stringent, by exact analysis of the 65xx interrupt behaviour in conjunction with the KERNAL ISR. There's a relevant quirk in the 65xx interrupt behaviour mentioned on 6502.org.
The two other parameters, raster line and X-position, are most easily fine-tuned empirically. For palette register applications, that can be done within VICE without any foreseeable troubles - VICE *is* accurate in that regard. For other uses that change timing or counter instances inside the VIC-I chip, checks against real h/w are still necessary.
There are two relevant constants - the timer 1 period; and the "phase" value, which is used for the interrupt delay/jitter compensation - which both can be derived either empirically or - more stringent, by exact analysis of the 65xx interrupt behaviour in conjunction with the KERNAL ISR. There's a relevant quirk in the 65xx interrupt behaviour mentioned on 6502.org.
The two other parameters, raster line and X-position, are most easily fine-tuned empirically. For palette register applications, that can be done within VICE without any foreseeable troubles - VICE *is* accurate in that regard. For other uses that change timing or counter instances inside the VIC-I chip, checks against real h/w are still necessary.
Re: Raster split and $9002
By timing or counter instances, I assume this means modification of the screen geometry or switching character and/or screen memory?Mike wrote: For other uses that change timing or counter instances inside the VIC-I chip, checks against real h/w are still necessary.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Raster split and $9002
Changing the base pointer of character memory *should* work out even up to the point where the screen text byte has already been fetched. It *might* be possible, that it is better to change it one cycle earlier, so there's a guarantee that the address calculation into the character generator is correct in any case - that is at least one point to clarify.beamrider wrote:By timing or counter instances, I assume this means modification of the screen geometry or switching character and/or screen memory?
Similarily, VIC-I holds an offset into the screen memory, and adds the offset to the screen base just before doing the text RAM fetch, so if you change the base address of the screen, it *should* work up to the point where the character data of the preceding text RAM byte has been fetched. Once again, if you change the screen base right after the character fetch up you can be sure it applies to the next character.
If you change both at once, one of the fetches *might* forcibly use the old base address. That will have to be investigated further.
Altering the screen geometry is much harder to understand in terms of the internal VIC registers. Tokra went quite tricky with the FLI104 mode, there he made sure, that the register changes happened early enough so it had the intended result. The recent VICE builds have became increasingly accurate in modeling the internal counters and timers of the VIC-I, but I suppose there's still room for improvement.
In any case, the stable raster routines are an invaluable tool to find out all about this (and thankfully, the VIC-I has no badlines!) - at first I'll concentrate upon making this routine bulletproof. Then we can follow up with all possible investigations regarding exact register write positions.
Note, that tlr has done quite extensive tests regarding the lightpen registers in the past, and the behaviour more or less matches that of real h/w (there's still a subtle difference in VICE, it allows for 2-pixel accuracy in the horizontal register whereas real h/w only delivers 4-pixel accuracy), which was anyhow good enough to design MINISKETCH in VICE.
Re: Raster split and $9002
Is there already a bug-report for this? I'm sure this would be an easy fix in VICE. Regarding the original issue of this thread I think we need a good test-case that can be reproduced on original hardware and VICE. This should also go in the testprogs-repository on VICE.Mike wrote:(there's still a subtle difference in VICE, it allows for 2-pixel accuracy in the horizontal register whereas real h/w only delivers 4-pixel accuracy), which was anyhow good enough to design MINISKETCH in VICE.
Which reminds me: I still need to file my bug-report for the Restore-key which made my MaxiEdit crash on real machines sometimes due to a bouncing RESTORE-key.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Raster split and $9002
Mike wrote:(there's still a subtle difference in VICE, it allows for 2-pixel accuracy in the horizontal register whereas real h/w only delivers 4-pixel accuracy), which was anyhow good enough to design MINISKETCH in VICE.
No...tokra wrote:Is there already a bug-report for this?
![Embarassed :oops:](./images/smilies/icon_redface.gif)
Re: Raster split and $9002
Coming back to the original problem, I get different effects on the real machine, VICE and yet another different output on z64k.com - the newest VIC-20 emulator. Something real odd is going on here obviously, as the VIC-emulation of VICE has been spot-on until now and all of PWP's demos work fine.
beamrider: Can you post the source code to you example program, so we might all have a look at it and compile it for ourselves to experiment with?
There must be a REASON why the real machine acts differently than the emulators and this is what we need to find out. Maybe you found a quirk in the hardware that can be used for [enter really cool demo-effect here].![Very Happy :D](./images/smilies/icon_biggrin.gif)
beamrider: Can you post the source code to you example program, so we might all have a look at it and compile it for ourselves to experiment with?
There must be a REASON why the real machine acts differently than the emulators and this is what we need to find out. Maybe you found a quirk in the hardware that can be used for [enter really cool demo-effect here].
![Very Happy :D](./images/smilies/icon_biggrin.gif)
- pixel
- Vic 20 Scientist
- Posts: 1357
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Raster split and $9002
Exactly! Am driveling on the keyboard already. There HAS to be something novel IMHO.tokra wrote:There must be a REASON why the real machine acts differently than the emulators and this is what we need to find out. Maybe you found a quirk in the hardware that can be used for [enter really cool demo-effect here].
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
Re: Raster split and $9002
I've played around with ex4.prg a little and found that when using the VICE-monitor to change the value you write to $9000 a little I get a result which looks a lot closer to the real machine.
Specifically you write $3f to $9000 at $2257. If I change this value to $44 in the VICE-monitor (>2256 44) there will be eight lines skipped before that text-block is displayed and the bottom text-line flickers during joystick-movement. This looks pretty similar on the real machine (although the text-block itself is still positioned elsewhere horizontally).
So, the different behaviour seems to have to do with the value in $9000. I see you have set up a 31 chars-wide screen ($1f in $9002) and start this at position $04 in $9000. So when you write $3f to $9000 during that line this is still within the displayed area (since $9000 is increased in half-chars). Only when you write values larger then or equal to $44 the change will be outside the displayed area and this seems to add the 8 extra-lines in VICE only then. However on the real machine this happens also with the change to $3f (while still inside the display-area). I assume the VIC sees the start of the line, checks if the internal row-counter is zero and increases the display-area by the value in char-height ($9003). VICE seems to do this only when the displayed area has been finished before.
Still this is just a wild theory, maybe you care to do a test-program for this behaviour?
Specifically you write $3f to $9000 at $2257. If I change this value to $44 in the VICE-monitor (>2256 44) there will be eight lines skipped before that text-block is displayed and the bottom text-line flickers during joystick-movement. This looks pretty similar on the real machine (although the text-block itself is still positioned elsewhere horizontally).
So, the different behaviour seems to have to do with the value in $9000. I see you have set up a 31 chars-wide screen ($1f in $9002) and start this at position $04 in $9000. So when you write $3f to $9000 during that line this is still within the displayed area (since $9000 is increased in half-chars). Only when you write values larger then or equal to $44 the change will be outside the displayed area and this seems to add the 8 extra-lines in VICE only then. However on the real machine this happens also with the change to $3f (while still inside the display-area). I assume the VIC sees the start of the line, checks if the internal row-counter is zero and increases the display-area by the value in char-height ($9003). VICE seems to do this only when the displayed area has been finished before.
Still this is just a wild theory, maybe you care to do a test-program for this behaviour?
Re: Raster split and $9002
Apologies, sounds like you are getting closer...
Yes, will try and knock up a test case as soon as I can, been a little busy this week....
Yes, will try and knock up a test case as soon as I can, been a little busy this week....
Re: Raster split and $9002
I couldn't resist and wrote a test-program for the $9000 phenomenon:
Download
Download Source
PAL-VIC20 with at least +8K required.
First the program fills the screen with the characters from 0 to 255 twice (just 506 visible, screen ratio still 22 x 23 chars)
Then it synchronizes with the raster bream and changes $9000 to 0 at cycle 13 of rasterline 114. At cycle 26 of rasterline 132 it resets the value of $9000 to 12 and then loops with constant synchronization to the raster beam, so what you see on the screen is stable.
Then after pressing SPACE the value written to $9000 at cycle 13 of rasterline 114 is increased by one (so now 1 is written) and will increase further after each press of SPACE. This way you can see what changing the value of $9000 to different values will do to the screen. Furthermore the value which $9000 is changed to will be poked to $1000 (the first byte of the video-RAM), so you can see by that at which point of the experiment exactly you are the moment.
I've put the resulting pictures on my webpage since there are too many pictures to show in this post:
Results of $9000-test
The first two pictures are from the recent version of VICE at values 26 and 68 which are really the only two interesting values regarding VICE. From value 26 onwards a blank line appear instead of the top-line of the next char-line. And from position 68 onwards suddenly the last char-line is being repeated. This stay the same until value 127.
Now for the real VIC the result are very different! At value 24 the line below the split looks a little garbled. At value 25 suddenly the same char-line starts with a lower char (Y instead of Z). At value 26 it even skips to start with W! At least the blank line appears at the some position as in VICE at value 26. Position 27 starts with V, and then at position 28 it suddenly jumps to the pound-sign just to go back to S at position 29. It continues to skip a character or two back which each next step, until suddenly at position 36 all bets are off, as it seems to jump FORWARD about 140 chars, just to go back at position 37. The next jump like that is at position 52 (36+16), until finally with position 68 (36+16+16) finally the real machine catches up with VICE and from then on they look the same.
I am really puzzled as to what goes on in the VIC-chip from values 24 to 68 in those cases and why there are those skips at position 28,36,44 and 52. Obviously there must be some kind of logic behind this, that is not yet implemented in VICE, however since VICE displays the same as the original machine from value 68 onward it must be on the right track already.
Feel free to try this for yourselves and check if you can reproduce what my PAL VIC shows. If you have an idea that might explain this behaviour please share![Very Happy :D](./images/smilies/icon_biggrin.gif)
Download
Download Source
PAL-VIC20 with at least +8K required.
First the program fills the screen with the characters from 0 to 255 twice (just 506 visible, screen ratio still 22 x 23 chars)
Then it synchronizes with the raster bream and changes $9000 to 0 at cycle 13 of rasterline 114. At cycle 26 of rasterline 132 it resets the value of $9000 to 12 and then loops with constant synchronization to the raster beam, so what you see on the screen is stable.
Then after pressing SPACE the value written to $9000 at cycle 13 of rasterline 114 is increased by one (so now 1 is written) and will increase further after each press of SPACE. This way you can see what changing the value of $9000 to different values will do to the screen. Furthermore the value which $9000 is changed to will be poked to $1000 (the first byte of the video-RAM), so you can see by that at which point of the experiment exactly you are the moment.
I've put the resulting pictures on my webpage since there are too many pictures to show in this post:
Results of $9000-test
The first two pictures are from the recent version of VICE at values 26 and 68 which are really the only two interesting values regarding VICE. From value 26 onwards a blank line appear instead of the top-line of the next char-line. And from position 68 onwards suddenly the last char-line is being repeated. This stay the same until value 127.
Now for the real VIC the result are very different! At value 24 the line below the split looks a little garbled. At value 25 suddenly the same char-line starts with a lower char (Y instead of Z). At value 26 it even skips to start with W! At least the blank line appears at the some position as in VICE at value 26. Position 27 starts with V, and then at position 28 it suddenly jumps to the pound-sign just to go back to S at position 29. It continues to skip a character or two back which each next step, until suddenly at position 36 all bets are off, as it seems to jump FORWARD about 140 chars, just to go back at position 37. The next jump like that is at position 52 (36+16), until finally with position 68 (36+16+16) finally the real machine catches up with VICE and from then on they look the same.
I am really puzzled as to what goes on in the VIC-chip from values 24 to 68 in those cases and why there are those skips at position 28,36,44 and 52. Obviously there must be some kind of logic behind this, that is not yet implemented in VICE, however since VICE displays the same as the original machine from value 68 onward it must be on the right track already.
Feel free to try this for yourselves and check if you can reproduce what my PAL VIC shows. If you have an idea that might explain this behaviour please share
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Raster split and $9002
so ... make a bug report
and then convince tlr to have a look at fixing it =D
![Smile :)](./images/smilies/icon_smile.gif)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Re: Raster split and $9002
Would be interesting to see how the FPGA implementations behave when running this if anyone has access..
- pixel
- Vic 20 Scientist
- Posts: 1357
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Raster split and $9002
We need a "VIC raster explorer"…
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
Re: Raster split and $9002
Sounds like your next projectWe need a "VIC raster explorer"…
![Very Happy :D](./images/smilies/icon_biggrin.gif)
To be fair: The VICE-emulation is already 99.9% perfect, apart from the interlace-modes of the NTSC-variant [*] it has no issues with any existing software of the last 36 years that I know of. It's quite astonishing that beamrider found this quirk in the first place. The next step would be to investigate this further with more test-cases and come up with some sort of theory what the VIC-chip is doing. Then a comprehensive bug-report can be filed and tlr (or someone else) can try to apply a fix to the VICE-sources. Would certainy like to try this myself, however I understand the VIC-emulation part only like 30% right now (not a C-guy), but maybe with help from some forum-members (are you listening, Mike?) this could be tackled eventually.
[*] For NTSC-interlace-emulation see the Z64K-emulator at http://www.z64k.com