I though I ask since most things on Vic-20 have been done at least 3 times already. The thing I want to do is a sprite on an unexpanded Vic-20. I want to have all of the character set available and only change a few bytes using 0-1024 area and specifically the tape-buffer. I have already been able to make a IRQ that triggers each 8'th line and position it correctly in the y-position. E.g. I change $9005 so that only two bytes on a line show the characters I want. I do this on two lines so I get a 16x16 "map" for an overlay. I then copy the bytes that are in that screen area into this bitmap and ora the sprite gfx into it (the sprite is only 8x8). Tape buffer is 828-1019 which spans characters 104-126 in the 0-1024 area. Those 23 characters can also be used for a 4x4 map (16 characters) to make a 32x32pixel "map" for an overlay. But for now I want to use a 16x16 pixelmap.
The timing to get the correct x-position is not so easy to get going. For a specific line I can get it to stay were I want, but when I move the y-position it tends to jump around a little bit.
My question is if anyone has seen some sourcecode for such a project before? Or maybe even made a routine that works.
VIC programmer's reference guide, 6th Edition:
That explained to be why I only saw garbage when I tried to move chars to $0000. Switched to $1000 then, to get it to work. But I was being asked how to use a computer and a mouse every couple of minutes…
BTW, the Wiki is also wrong on the multi-colour codes. Exterior border is %01, foreground is %10.
Back to topic: going all-out like this normally would only be necessary, when the sprite display routine has no control whatsoever over what happens in the background under the sprite. That given, I don't see however the need to trigger an interrupt every 8 rasters.
Rather, a periodic interrupt in T1 is fired shortly after the display window has ended. It latches the sprite coordinates, sets up T2 in one-shot mode to trigger *cycle-exact* a few lines before the sprite is shown, and possibly also prepares the pre-shifted data in the 16x16 pixel matrix.
When T2 has triggered, a *constant* time is used to read off the characters beneath the sprite, OR in the pre-shifted data, and then replace those 4 bytes on screen with 124..127, which point to $03E0 .. $03FF.
Now, during display of those 16 pixel lines, mostly the normal screen is shown, except at the sprite's position, where the character set is quickly shifted to $0000 for 4 cycles (=2 characters!) and back again to default. That's easily done with STA $9005:STX $9005, a lot of NOPs and a loop counting Y from 16 down to 0. And, as I wrote above, with a careful cycle-exact positioning.
After this, clean-up: restoring the original 4 bytes in the text screen, and then exit from interrupt.
In the end, the foreground process is totally in the dark about the fact a sprite had been displayed at that place. You can change the background under the sprite at will, move the text cursor below it, scroll the screen - the sprite will remain at place, unchanged. However, colour clash will still occur. Best bet is probably to let the sprite take precedence of the colour attribute - again, only during its display - when the rasters are done, and before exit from the T2 interrupt, the colour RAM is restored.
...
Implementing this would probably take me a good weekend for a working prototype. Thus far I didn't find it necessary, as sprite routines on application level have total control over what happens in the screen background: you remove the sprite, change the background and then display the sprite again. I do it like this for the cursor display in MINIPAINT, and Robert's Triple-S system works quite the same way.
Finally, there's a big obstacle that remains for the interrupt based sprite display: like all 'active' graphic modes, which rely on interrupts to change VIC registers during display, it is rather difficult to keep a stable display during disk I/O. But then, I suppose you already knew that.
Yeah you can totally use a lot of that first block for sprites. My Astro Nell game a while back has the map chars at $0284 and the softsprites at $338 onwards. (I had 4 of them up to 3x2 char size I think, didn't ORA the background because they were hires and I had to shift the X position in real-time anyway) I had the source sprite gfx in the stack and used the zero page for variables. Rest of memory was code and map data until the character screen at $1e00.
Updated link Feb 2017: New version Vic-20 with NEOS mouse that also run on VICE (2.4.23 or later) with NEOS emulation enabled.
It basically adds a mouse pointer so that you can move the cursor around by clicking on the place you want it. Scrolling now works, but inserting new lines may garble the pointer it a little bit.
This version ACTUALLY works with pin 4 removed from the NEOS mouse (to prevent keyboard interference on a real Vic-20). Use an joystick extension cable if you don't want to modify the mouse (you can find them on ebay). Tested and confirmed.
Update: New version source code is HERE. It leaves you with 2268 bytes free for basic. The sprite data now resides in cassette buffer from 828-843 and 852-867 (leave 820-827, 844-851 and 868-875 as zero).
Happy unexpanded coding!
Last edited by Kakemoms on Sat Feb 04, 2017 5:53 pm, edited 3 times in total.
could you perhaps provide some code that has only the NEOS mouse stuff and just shows some numbers/coordinates on screen? because recent VICE snapshots actually support the NEOS mouse (also with vic20) - but this code doesnt work for some reason (which could be fixed, i guess)...
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
groepaz wrote:could you perhaps provide some code that has only the NEOS mouse stuff and just shows some numbers/coordinates on screen? because recent VICE snapshots actually support the NEOS mouse (also with vic20) - but this code doesnt work for some reason (which could be fixed, i guess)...
Sure.. I'll add it at the bottom of the Vic-20 mouse driver tread when I get home. The driver part is only a few bytes of code. Actually I will add two, one for the standard NEOS mouse and one for the modified with pin 4 connection removed (they work a little differently, but you barely notice any difference).
Well, as long as it works on a real Vic-20 with a NEOS mouse I am happy. I haven't seen any options for a mouse on the VICE_Vic-20 version I am running. It is a developer release? What OS are you running it on?
