Software sprites?
Moderator: Moderators
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Okay, the documentation (PDF format) is completed. All pertinent files, including a demo, are zipped for your downloading pleasure. I posted a 2009 software release announcement -- get the details there.
I did manage to fix the last of the Quikman 8k bugs -- and already added more "features".
I have one last bit of new code I want to add to it, and I will have that released very shortly too. Then comes some new games!
I did manage to fix the last of the Quikman 8k bugs -- and already added more "features".
I have one last bit of new code I want to add to it, and I will have that released very shortly too. Then comes some new games!
I'm reading the PDF docs right now -- very nice job.
I'll try to get acquainted with the whole thing and perhaps start coding a game (I have one in mind since 1984). Unfortunately I'm chronically short of spare time
I also have a problem: I use DASM instead of CC65 for all my VIC projects, so is there any chance to easily convert the source to DASM? Or at least have the API call entry points so that I can call them from the DASM? What do you suggest?
I'll try to get acquainted with the whole thing and perhaps start coding a game (I have one in mind since 1984). Unfortunately I'm chronically short of spare time
I also have a problem: I use DASM instead of CC65 for all my VIC projects, so is there any chance to easily convert the source to DASM? Or at least have the API call entry points so that I can call them from the DASM? What do you suggest?
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
I edited the PDF to have 2 omitted lines in the code block example:
So, the zip file has just now been updated, but only for that omission.
Labels may be more problematic, as I do use the cheap local labels throughout. If DASM does not support such a feature ( switch to ca65! ), then you would have to manually replace each instance with a unique label -- ugh.
Code: Select all
LDA #%00000001 ; don't forget to enable the sprite!
STA SSS
I am not familiar with DASM, but I cannot see why any of the sources included could not be made compatible with any other assembler. There are only a couple of assembler directives (.include, .segment, .global), which should either have a counter-part in DASM, or simply "append" the VIC-SSS.s source directly in with your game source -- and remove ALL directives.I use DASM instead of CC65 for all my VIC projects
Labels may be more problematic, as I do use the cheap local labels throughout. If DASM does not support such a feature ( switch to ca65! ), then you would have to manually replace each instance with a unique label -- ugh.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Ok, you got me looking at DASM ... some more thoughts:
There is a .segment equivalent -- replace with a SEG pseudop. May not be required if you make this a monolithic source.
Instead of linking, you can use its ORG pseudop to specify a fixed address.
There is an INCLUDE pseudop -- to include source -- at least that could keep your program file separate from VIC-SSS.s.
The CONSTANTS rules are compatible with VIC-SSS as-is, that's good.
There is a temporary label/symbol feature, but you must replace all the "@" with ".", so that's good too. I believe I could do that myself, and put an instruction for ca65 to use "." instead of "@". Hmmm...
That line alone got me thinking about switching!- supports several common 8 bit processor models (NOT 8086, thank god!)
That's weird, so there are a few expressions with parenthesis that would need to be changed to brackets. Should not be a problem for you.- expressions, as in C but [] is used instead of () for parenthesis.
There is a .segment equivalent -- replace with a SEG pseudop. May not be required if you make this a monolithic source.
Instead of linking, you can use its ORG pseudop to specify a fixed address.
There is an INCLUDE pseudop -- to include source -- at least that could keep your program file separate from VIC-SSS.s.
The CONSTANTS rules are compatible with VIC-SSS as-is, that's good.
There is a temporary label/symbol feature, but you must replace all the "@" with ".", so that's good too. I believe I could do that myself, and put an instruction for ca65 to use "." instead of "@". Hmmm...
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Let me know how that goes, please? I would very much like to see the "diff" in source formats.... make it work under DASM
I updated the VIC-SSS.zip this morning, as I found an annoying BASIC startup bug in its timer and mishandling of missed frames in SSSIRQ with the VSYNC2 variable. Nothing major, but it affected the Quikman 8K binaries as well, so the fix needed to go it as well.
I use parenthesis with dasm. I assume brackets are only needed if there is a possibility of mis-detecting the addressing type. I.e. in lda [fuubar+1039] the brackets are required, using parenthesis you get a parse error, but lda #<(fuubar+1039) works fine. But for absolute addressing you don't even need the enclosing parenthesis, you can just use lda fuubar+1039, so..rhurst wrote:That's weird- expressions, as in C but [] is used instead of () for parenthesis.
- Mike
- Herr VC
- Posts: 4901
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
With a stable API available, we now could pack SSS into a BASIC extension. Besides the usual lot of commands for sprite definition, and positioning, I already thought about a command like:
(not necessarily in orthogonal directions, btw.) together with a function like:
the last which returns -1, if the sprite is actually moved - in the interrupt - by SPRMOV, and 0, if not.
Code: Select all
SPRMOV <nr>,<x1>,<y1> [TO <x2>,<y2> [SPEED <speed>]]
Code: Select all
MOVING(<nr>)
I gave up converting to SSS to DASM, there are too many minor differences, so I have desisted.
I also have tried to convert myself to cc65 but I can't get used to it, despite being a more powerful compiler that would solve many issues I have with DASM.
In conclusion: I would continue to use DASM and link the SSS library as an include file, previously extracted from binary format (VICSSS.o or similar). I would then set in DASM the library entry points symbols, in other words I would treat SSS as a sort of "kernel" routines with the only difference that I have to physically include its binary image.
Does this sound correct?
I also have tried to convert myself to cc65 but I can't get used to it, despite being a more powerful compiler that would solve many issues I have with DASM.
In conclusion: I would continue to use DASM and link the SSS library as an include file, previously extracted from binary format (VICSSS.o or similar). I would then set in DASM the library entry points symbols, in other words I would treat SSS as a sort of "kernel" routines with the only difference that I have to physically include its binary image.
Does this sound correct?
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
I am warming up to the idea... I wrote a (kludgy) BASIC wedge way back when I had energy to spare -- it was cool extending the friendly computer! I recall some C128 sprite-oriented commands, but please list a syntax you feel would be worthwhile.... pack SSS into a BASIC extension
But before even moving on to BASIC, perhaps VIC-SSS needs a couple of things worked out to make it more friendly and flexible:
- I provided a startup segment for BASIC and game cartridge support, but I resorted to prompting the user whether this is for PAL (or default NTSC) timing -- nbla000 gave me this address $EDE4 (NTSC=$05, PAL=$0C) to use with Mega-Cart, but it falls within the BASIC ROM space -- so is that a fixed VIC 20 value that can be used instead of user intervention?
- improve VIC-SSS usability for programmers with more pre-canned linker configurations for those wanting tighter code and/or for a specific memory layout (that lovely 3k expansion has got to be used for something!)
- create "fixed" JMP vector(s) into the API to allow its "kernal" to be loaded anywhere?
- extend (or allow for) the API to account for screen scrolling.
That's disheartening to hear.I gave up converting SSS to DASM
Inclusion of it as a binary into your DASM project is always an option -- and it's trivial to make a targeted binary to a specific address space. Perhaps it would serve better if I did a better job of providing a menu of pre-linker configurations (like stated above), whereas the programmer can just choose what he wants, have it made with a symbol map for the registers and JSR entries to reference. I should also improve SSS documentation on the ca65/ld65 assembling/linking process -- while it is extremely powerful, it can lead to complexity and confusion -- all it needs are simplified working examples for the limited use-cases on VIC 20.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
yes, it's one the values that is loaded on bootstrap and changes between PAL and NTSC machines.rhurst wrote: is that a fixed VIC 20 value that can be used instead of user intervention?
as for the DASM, I'll compile a version with cc65 and get the binary image with absolute address and then include in dasm (text conversion is needed but that is not a problem). I guess I can get the adresses from the .map file, right?
yes please, examples.all it needs are simplified working examples for the limited use-cases on VIC 20.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Absolutely... onward!I can get the adresses from the .map file
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing