Software sprites?

Basic and Machine Language

Moderator: Moderators

rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

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". 8)

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! :D
User avatar
amramsey
Vic 20 Hobbyist
Posts: 117
Joined: Sat Apr 14, 2007 9:38 pm

Post by amramsey »

I'd just like to say thanks for this. It has inspired me to pick up my Vic again and finally learn some 6502 assembly so I could make a game or two with this. All the time I used my vic and 64, assembly always scared me off and I stuck with Basic. Now, 20 odd years later, I guess I'm finally ready. :D
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

amramsey wrote:...and I stuck with Basic.
That's all I really need. :wink:
High Scores, Links, and Jeff's Basic Games page.
nippur72
de Lagash
Posts: 574
Joined: Thu Sep 07, 2006 8:35 am

Post by nippur72 »

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?
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

I edited the PDF to have 2 omitted lines in the code block example: :oops:

Code: Select all

LDA #%00000001 ; don't forget to enable the sprite!
STA SSS
So, the zip file has just now been updated, but only for that omission.
I use DASM instead of CC65 for all my VIC projects
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.

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! :P ), then you would have to manually replace each instance with a unique label -- ugh.
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

Ok, you got me looking at DASM ... some more thoughts:
- supports several common 8 bit processor models (NOT 8086, thank god!)
That line alone got me thinking about switching! :lol:
- expressions, as in C but [] is used instead of () for parenthesis.
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.

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...
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

Labels ending with $ also are local in DASM, or so I believe.
Anders Carlsson

Image Image Image Image Image
nippur72
de Lagash
Posts: 574
Joined: Thu Sep 07, 2006 8:35 am

Post by nippur72 »

Ok, let's see if I'm able to make it work under DASM.

To be honest I prefer it to cc65, because it is much simpler and more direct when used from the command line (no linking, automatic .prg format and so on). But I guess it's a matter of taste.
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

... make it work under DASM
Let me know how that goes, please? I would very much like to see the "diff" in source formats.

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. :roll:
a1bert
Vic 20 Dabbler
Posts: 96
Joined: Mon Jan 23, 2006 12:49 am

Post by a1bert »

rhurst wrote:
- expressions, as in C but [] is used instead of () for parenthesis.
That's weird
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..
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

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:

Code: Select all

SPRMOV <nr>,<x1>,<y1> [TO <x2>,<y2> [SPEED <speed>]]
(not necessarily in orthogonal directions, btw.) together with a function like:

Code: Select all

MOVING(<nr>)
the last which returns -1, if the sprite is actually moved - in the interrupt - by SPRMOV, and 0, if not.
nippur72
de Lagash
Posts: 574
Joined: Thu Sep 07, 2006 8:35 am

Post by nippur72 »

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?
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

... pack SSS into a BASIC extension
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.

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.
I gave up converting SSS to DASM
That's disheartening to hear. :(

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
nippur72
de Lagash
Posts: 574
Joined: Thu Sep 07, 2006 8:35 am

Post by nippur72 »

rhurst wrote: is that a fixed VIC 20 value that can be used instead of user intervention?
yes, it's one the values that is loaded on bootstrap and changes between PAL and NTSC machines.

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?
all it needs are simplified working examples for the limited use-cases on VIC 20.
yes please, examples. :)
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

I can get the adresses from the .map file
Absolutely... onward!
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
Post Reply