Software sprites?
Moderator: Moderators
Re: Software sprites?
No reason, you can't call it from 'c' or BASIC.
Would just need to import the data structures, sprite register locations and calls in the appropriate form. No-one has done this to my knowledge though.
I thought about using it to write an *enhanced version of 'blue-meanies' in 'c' as a example/bootstrap project, but never got around to it
* The enhancements I had in mind were:smooth movement, better graphics and not pausing when you fired the lasers.
Would just need to import the data structures, sprite register locations and calls in the appropriate form. No-one has done this to my knowledge though.
I thought about using it to write an *enhanced version of 'blue-meanies' in 'c' as a example/bootstrap project, but never got around to it
* The enhancements I had in mind were:smooth movement, better graphics and not pausing when you fired the lasers.
Re: Software sprites?
I've created a C bridge or wrapper around the SSS by Robert Hurst. It can be downloaded from the following location:
https://drive.google.com/open?id=0BypVx ... DRwVE9BUWM
The link is a .zip file that unpacks to a hello world project....
Everything is setup up to get you up and running quickly - it includes a copy of CC65 and VICSSS (but not VICE).
Inside the folder is a COMPILE.BAT that generates the above .PRG file. You will just need to change the path to the location of VICE on your machine
at the bottom of this file.
e.g.
The guts of the program is in the file main.c and should be self explanatory with the //COMENTS and reading the included SSS pdf docs and a smattering of C knowledge.
A brief explanation some of the other files that are not documented in SSS:
data.s - you can put sprite data etc in here
RasterSync.s - [Assembler SSS] IRQ handler for flicker free sprites
vis-sss-bridge.s -C compatible assembly wrappers for SSS
vis-sss-bridge.h - C header file for SSS function definitions and SYMBOLS
vic20-16k.cfg - linker configuration file. Describes the memory layout and where to put each code file.
You may find an IDE type environment useful. I use Notepad ++ [with NppExec / Explorer plugins] so I can edit files and save/compile/run with a simple Ctrl+F6. You may wish to use Visual Studio code or similar...
You may find my Screen Designer will be useful for generating sprite data using the bitmap function...
There are plenty of tutorials for C on the web.
This zip file was developed under windows, but should be easy to change to other platforms. If anyone would like to produce and share a unix/mac variant that would be great...
Hoping this will encourage some people to progress from BASIC programming - those that don't want the tedium of writing assembly or writing a sprite library.
[I haven't tested all of the SSS API functions from C, but they should work. Let me know if you find a problem]
If there is enough interest I might extend this Hello World into a small game with some background music etc..
Any questions shout up..
https://drive.google.com/open?id=0BypVx ... DRwVE9BUWM
The link is a .zip file that unpacks to a hello world project....
Everything is setup up to get you up and running quickly - it includes a copy of CC65 and VICSSS (but not VICE).
Inside the folder is a COMPILE.BAT that generates the above .PRG file. You will just need to change the path to the location of VICE on your machine
at the bottom of this file.
e.g.
Code: Select all
"c:\MyViceFolder\xvic.exe" -moncommands %~dp0\obj\%TITLE%.sym -memory 16k bin\%TITLE%.prg
Code: Select all
void main (void)
{
BYTE bigDudeSprite = 0;
BYTE idx = 0;
// Set the screen colours
textcolor (COLOR_RED);
bordercolor (COLOR_BLUE);
bgcolor (COLOR_BLACK);
// Init Vic SSS
SSSINIT();
// Start IRQ routine for optional frame rate lock
IrqSetup();
// Create the sprite
bigDudeSprite = SSSCREATE(16,SPRITEDEF_HEIGHT_16
| SPRITEDEF_WIDTH_16
| SPRITEDEF_FLOATY_FLOAT
| SPRITEDEF_FLOATX_FLOAT
| SPRITEDEF_ENABLED);
// Clear screen
SSSCLEAR(SSSNULL);
// Hello text..
SSSPRINTTEXT(4,10,"HELLO SSS-C \0");
SSSPRINTTEXT(2,12,"(SSS BY R.HURST)\0");
// Select sprite
SSSUSE(bigDudeSprite);
// Set sprite bitmap
SSSANIM(COLOR_RED, BIGDUDEBITS);
// LOOP forever..
while(TRUE)
{
for (idx = 16; idx < 192; idx++)
{
// Move sprite to x,y cords
SSSUSE(bigDudeSprite);
SSSMOVEXY(idx, idx);
SSSFLIP(1);
}
}
}
data.s - you can put sprite data etc in here
RasterSync.s - [Assembler SSS] IRQ handler for flicker free sprites
vis-sss-bridge.s -C compatible assembly wrappers for SSS
vis-sss-bridge.h - C header file for SSS function definitions and SYMBOLS
vic20-16k.cfg - linker configuration file. Describes the memory layout and where to put each code file.
You may find an IDE type environment useful. I use Notepad ++ [with NppExec / Explorer plugins] so I can edit files and save/compile/run with a simple Ctrl+F6. You may wish to use Visual Studio code or similar...
You may find my Screen Designer will be useful for generating sprite data using the bitmap function...
There are plenty of tutorials for C on the web.
This zip file was developed under windows, but should be easy to change to other platforms. If anyone would like to produce and share a unix/mac variant that would be great...
Hoping this will encourage some people to progress from BASIC programming - those that don't want the tedium of writing assembly or writing a sprite library.
[I haven't tested all of the SSS API functions from C, but they should work. Let me know if you find a problem]
If there is enough interest I might extend this Hello World into a small game with some background music etc..
Any questions shout up..
Last edited by beamrider on Tue Aug 15, 2017 6:21 am, edited 1 time in total.
-
- 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
Re: Software sprites?
That's killer ... modern tools and APIs for VIC? Incredible.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
Re: Software sprites?
This is great. Thanks. I'm looking forward to giving it a go. It might make it possible for me to continue a project a started ages ago but stalled on as I couldn't work out how to implement sprites that didn't tear and flicker.
- Mike
- Herr VC
- Posts: 4858
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Software sprites?
Just curious: is there a specific reason you insist on this spelling of C (other than, possibly, that cc65 doesn't implement the full language)?beamrider wrote:'c' [...] 'c' [...] 'c' [...] 'c'
Re: Software sprites?
nope, you got me there.
I must have seen it written like that somewhere and it stuck.
Post corrected.
[Also noticed that there was a missing \0 after (SSS BY R.HURST) - must have worked by luck.]
Will update the download zip to match.
I must have seen it written like that somewhere and it stuck.
Post corrected.
[Also noticed that there was a missing \0 after (SSS BY R.HURST) - must have worked by luck.]
Will update the download zip to match.
-
- Vic 20 Drifter
- Posts: 35
- Joined: Sat Oct 11, 2014 3:25 pm
Re:
Mr. Hurst, I am a big fan of your work on the VIC. Finally, I found this thread. The above links are not active anymore. The new link is https://robert.hurst-ri.us/files/vic-so ... ite-stack/rhurst wrote:Ok, first ALPHA release DEMO of these "software sprites" is available.
Download it here:
DEMO cartridge @ $A000
... and its assembler source code using cc65 project.
It supports NTSC (default) with a startup override to switch to PAL timing. Press RUN/STOP to pause frame.
Still 8x8 only, and just the "fixed" and "vertical" modes supported -- "horizontal" and "float" modes to follow. Then the double-width, double-height, double-both will follow that.
I am very pleased with its progress. The API is coalescing into something that might be useful for rapid implementation within video games, or even just to add some animated effects.
Feedback is always welcomed.
-
- 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
Re: Software sprites?
You can fetch/follow these projects on GitHub.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
- AndyH
- Vic 20 Afficionado
- Posts: 370
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Software sprites?
This library is amazing, many thanks for putting it together all that time ago.
I'm working things out along with the documentation and I have a version working nicely with CBM PRG Studio. I've created several sprites for use as missiles and intend them to be 1x1 pixels and using the SPRITEDEF recommended for them. This is how I've got it set up:
LDA #%11000000 ; 1x1 missile
LDY #$01 ; 1 pixels high
JSR SSSCREATE
LDA #YELLOW ;
LDX #<SPRLASER ; points to
LDY #>SPRLASER ; char with one dot at top left
JSR SSSANIM
Can I check I have this right, I have pointed reg x and y to a character that has a single pixel in the top left and this seems to behave correctly. Have tried other patterns while experimenting of course and this works as I'd expect. Is that correct for this SPRITEDEF?
I will need to figure out collision detection next, as I want to detect collisions with other sprites and background graphics. I've un-commented SPRITEDEF6 - $40 and I've set bit 6 on the missiles and the enemy sprites which I assume is the correct first step? Any advice of common gotcha's I need to watch out for when working with collisions?
Anyway, big thanks once again Robert for making this library. Here's what I've got so far (minus the missiles):
https://twitter.com/Hewco64/status/1053943735107678208
I'm working things out along with the documentation and I have a version working nicely with CBM PRG Studio. I've created several sprites for use as missiles and intend them to be 1x1 pixels and using the SPRITEDEF recommended for them. This is how I've got it set up:
LDA #%11000000 ; 1x1 missile
LDY #$01 ; 1 pixels high
JSR SSSCREATE
LDA #YELLOW ;
LDX #<SPRLASER ; points to
LDY #>SPRLASER ; char with one dot at top left
JSR SSSANIM
Can I check I have this right, I have pointed reg x and y to a character that has a single pixel in the top left and this seems to behave correctly. Have tried other patterns while experimenting of course and this works as I'd expect. Is that correct for this SPRITEDEF?
I will need to figure out collision detection next, as I want to detect collisions with other sprites and background graphics. I've un-commented SPRITEDEF6 - $40 and I've set bit 6 on the missiles and the enemy sprites which I assume is the correct first step? Any advice of common gotcha's I need to watch out for when working with collisions?
Anyway, big thanks once again Robert for making this library. Here's what I've got so far (minus the missiles):
https://twitter.com/Hewco64/status/1053943735107678208
Re: Software sprites?
Looking at it, I can't see how you obtained the smooth movement as you haven't enabled FLOATX or FLOATY. I use definitions instead of just putting in the binary values like this:
so you could define yours as SPRITEDEF_SMALL_FLOAT_XY above. The rest of the code looks okay to me.
I didn't use the collision detection personally and just tracked the positions of things myself.
Code: Select all
; SPRITEDEF constants
SPRITBIT_ENABLE = <$80
SPRITBIT_COLLISION = <$40
SPRITBIT_GHOST = <$20
SPRITBIT_REPEAT = <$10
SPRITBIT_FLOATX = <$08
SPRITBIT_FLOATY = <$04
SPRITBIT_WIDTH = <$02
SPRITBIT_HEIGHT = <$01
; Sprite defines
SPRITEDEF_SMALL_FLOAT_XY = SPRITBIT_FLOATX | SPRITBIT_FLOATY
I didn't use the collision detection personally and just tracked the positions of things myself.
- AndyH
- Vic 20 Afficionado
- Posts: 370
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Software sprites?
That looks really helpful. In the case of the Float_XY I believe you only need that if you are creating a sprite that will use 2 columns and/or rows to render it. The documentation states that the SPRITEDEF I have used creates a 1x1 character and is useful for missiles. This is what confused me initially as the docs say no float but after testing with different patterns, if I used anything but %10000000 as the character pattern, I would see it being truncated as it moved from position 8 to 15 before being fully visible at position 16. So was wanting to check I had this correct.beamrider wrote:Looking at it, I can't see how you obtained the smooth movement as you haven't enabled FLOATX or FLOATY. I use definitions instead of just putting in the binary values like this:
so you could define yours as SPRITEDEF_SMALL_FLOAT_XY above. The rest of the code looks okay to me.Code: Select all
; SPRITEDEF constants SPRITBIT_ENABLE = <$80 SPRITBIT_COLLISION = <$40 SPRITBIT_GHOST = <$20 SPRITBIT_REPEAT = <$10 SPRITBIT_FLOATX = <$08 SPRITBIT_FLOATY = <$04 SPRITBIT_WIDTH = <$02 SPRITBIT_HEIGHT = <$01 ; Sprite defines SPRITEDEF_SMALL_FLOAT_XY = SPRITBIT_FLOATX | SPRITBIT_FLOATY
I didn't use the collision detection personally and just tracked the positions of things myself.
In that GIF animation I included, I am using an 8 x 8 pixel sprite and a spritedef as you describe. I've not captured the version where I am now shooting my missiles but will do that later
Thanks again for the tip on the Sprite def constants, that will make it more understandable for sure!
I think perhaps you are right about the collision detection - I don't really need pixel precise collisions in my game and detecting a point within a bounding box is pretty straight forward for my missiles.
Is there a good way (optimised for speed) to detect an overlap of two rectangles in 6502?
Edit: Here's the missiles in action - Twitter video
-
- 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
Re: Software sprites?
Yup, a single character is used for a 1-pixel high missile sprite, and it still has the net effect of the full pixel coordinate system with any other larger sprite. If that pixel is only moving left-right, you can make it wider, say 2-pixels wide and move it 2-pixels at a time, or 4-pixels wide and move it either 2 or 4-pixels. You can see collision-detection in action with code snippet:
But assume you're looking to detect if the 1x1 missile hit another sprite's 8x8 matrix?
if abs((objectX) - (missileX)) > 8 nope, move on
if abs((objectY) - (missileY)) > 8 nope, move on
hit!
With collision-detection enabled, it's easier like in Sprite Invaders and in the demo:
...else keep moving the missile until it reaches firing limit range, off-screen or some other decrementing register.
If the hit-bit was detected, then check which play field character cell it "touched":
Omega Fury uses a more complicated bounding box collision detection (not pixel collision), because the objects it can hit can be either 8x8 or 16x16:
Code: Select all
xvic -memory all -autostart ca65-primer/demos/demo.prg
if abs((objectX) - (missileX)) > 8 nope, move on
if abs((objectY) - (missileY)) > 8 nope, move on
hit!
With collision-detection enabled, it's easier like in Sprite Invaders and in the demo:
Code: Select all
LDA SPRITEZ
AND #%1000 ; collision?
BNE @hit
If the hit-bit was detected, then check which play field character cell it "touched":
Code: Select all
@hit:
LDA SPRITEBACK ; which character code did it hit?
CMP #$7A ; matrix codes below this # are any of the enemy ships (score) or their missiles (cancel)
BCC @invader
JMP @mothership ; else, it's the bonus mother ship
Code: Select all
@cont:
LDX #$00
STX LOOPX
@loop:
LDA NME,X
BNE @ck
JMP @next
@ck:
LDA #$01 ; adjustment for EOR operation
STA ACOPY
LDA #$08
CMP SPRITEH+8,X
BEQ @nme
LDA #$F9 ; adjust for carrier collision (-7)
STA ACOPY
@nme:
LDA SPRITEX+8,X
SEC
SBC SPRITEX+12
BCS @nov1
EOR #$FF
CLC
ADC ACOPY
@nov1:
CMP #$08
BCS @next
LDA SPRITEY+8,X
SEC
SBC SPRITEY+12
BCS @nov2
EOR #$FF
CLC
ADC ACOPY
@nov2:
CMP #$08
BCS @next
LDX SPRITEX+12
LDY SPRITEY+12
JSR NEWHITMARK ; player hit
LDA #$E0
STA HIT
LDX LOOPX
DEC NMEHP,X ; scratch the enemy's hull paint
BNE @paint
; killed enemy by ramming it -- no score
LDA #$00
STA NME,X
LDA SPRITEDEF+8,X
AND #$7F ; disable sprite
STA SPRITEDEF+8,X
DEC OBJECTIVE
@paint:
LDA SPRITEH+8,X ; bigger the ship, the bigger the hit
CLC
ADC SPEED ; and the faster you were going
LSR ; half
JSR FURYHIT
LDA FURYHP
BEQ @xnme
LDA #$08
STA SPEED
LDA #$38 ; 56-frames of immunity
STA COLLISION
LDA INERTIA
EOR #$08 ; reverse direction
STA INERTIA
LDA #100
JSR RND
AND #$0F
JSR FURYNAVI
JMP @xnme ; go!
@next:
INC LOOPX
LDX LOOPX
CPX #$04
BEQ @xnme
JMP @loop
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
- AndyH
- Vic 20 Afficionado
- Posts: 370
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Software sprites?
Hi Robert, many thanks for replying with all of that information. I'm really loving your sprite library (did I say that already?), it is allowing me to relive my childhood ambitions of making something as good as Omega Race on the humble Vic.
ACOPY is being set to $01 or $F9 for a carrier and is added on to the result before comparing - what is that for?
I've done exactly that with a 2 pixel wide missile. Works a treat.rhurst wrote:Yup, a single character is used for a 1-pixel high missile sprite, and it still has the net effect of the full pixel coordinate system with any other larger sprite. If that pixel is only moving left-right, you can make it wider, say 2-pixels wide and move it 2-pixels at a time, or 4-pixels wide and move it either 2 or 4-pixels. You can see collision-detection in action with code snippet:Code: Select all
xvic -memory all -autostart ca65-primer/demos/demo.prg
I've ended up with something similar, although I've just checked the upper and lower bounds.rhurst wrote: But assume you're looking to detect if the 1x1 missile hit another sprite's 8x8 matrix?
if abs((objectX) - (missileX)) > 8 nope, move on
if abs((objectY) - (missileY)) > 8 nope, move on
hit!
Code: Select all
lda gamePlayerX
clc
sbc enemyX
cmp #PLAYER_CLEFT
bcs @collisionOnX
cmp #PLAYER_CRIGHT
bcs @noCollision
@collisionOnX lda gamePlayerY
sbc enemyY
cmp #PLAYER_CTOP
bcs @collision
cmp #PLAYER_CBOT
bcc @collision
@noCollision lda #8
sta VICCOLOR
rts
@collision lda #9
sta VICCOLOR
rts
I haven't spent any more time on the collisions part of the library just yet, how much of an overhead do you find it adds to the speed? For my first game I can safely use the bounding box collisions using the code above and a slightly smaller hitbox for the player.rhurst wrote: With collision-detection enabled, it's easier like in Sprite Invaders and in the demo:...else keep moving the missile until it reaches firing limit range, off-screen or some other decrementing register.Code: Select all
LDA SPRITEZ AND #%1000 ; collision? BNE @hit
If the hit-bit was detected, then check which play field character cell it "touched":Code: Select all
@hit: LDA SPRITEBACK ; which character code did it hit? CMP #$7A ; matrix codes below this # are any of the enemy ships (score) or their missiles (cancel) BCC @invader JMP @mothership ; else, it's the bonus mother ship
Ah, that is really helpful - highlighting some general things I have overlooked (I'm still learning the library and 6502 at the same time ). One question on this snippet in your example:rhurst wrote: Omega Fury uses a more complicated bounding box collision detection (not pixel collision), because the objects it can hit can be either 8x8 or 16x16:Code: Select all
@cont: LDX #$00 STX LOOPX @loop: LDA NME,X BNE @ck JMP @next @ck: LDA #$01 ; adjustment for EOR operation STA ACOPY LDA #$08 CMP SPRITEH+8,X BEQ @nme LDA #$F9 ; adjust for carrier collision (-7) STA ACOPY @nme: LDA SPRITEX+8,X SEC SBC SPRITEX+12 BCS @nov1 EOR #$FF CLC ADC ACOPY @nov1: CMP #$08 BCS @next LDA SPRITEY+8,X SEC SBC SPRITEY+12 BCS @nov2 EOR #$FF CLC ADC ACOPY @nov2: CMP #$08 BCS @next LDX SPRITEX+12 LDY SPRITEY+12 JSR NEWHITMARK ; player hit LDA #$E0 STA HIT LDX LOOPX DEC NMEHP,X ; scratch the enemy's hull paint BNE @paint ; killed enemy by ramming it -- no score LDA #$00 STA NME,X LDA SPRITEDEF+8,X AND #$7F ; disable sprite STA SPRITEDEF+8,X DEC OBJECTIVE @paint: LDA SPRITEH+8,X ; bigger the ship, the bigger the hit CLC ADC SPEED ; and the faster you were going LSR ; half JSR FURYHIT LDA FURYHP BEQ @xnme LDA #$08 STA SPEED LDA #$38 ; 56-frames of immunity STA COLLISION LDA INERTIA EOR #$08 ; reverse direction STA INERTIA LDA #100 JSR RND AND #$0F JSR FURYNAVI JMP @xnme ; go! @next: INC LOOPX LDX LOOPX CPX #$04 BEQ @xnme JMP @loop
Code: Select all
LDA SPRITEX+8,X
SEC
SBC SPRITEX+12
BCS @nov1
EOR #$FF
CLC
ADC ACOPY
@nov1:
CMP #$08
BCS @next
Re: Software sprites?
Forgive me, I'm a noob to assembler...
This is regarding the VIC-SSS API and a question of use within a different assembler.
Whilst I've coded in a number of languages over the years, I wanted to write a game in assembler for the VIC.
Looking through, I realised that I'd need to write routines for software sprite mapping and double buffering. Then I came across VIC-SSS by Robert Hurst / theflyingape which does all that. Rather than reinvent the wheel, I'd go with that.
I want to use CBM prg Studio to write assembler. It's a nice IDE with all built in. The vic-sss documentation says that its code is designed to be used with cc65, I don't want to write in C mind.
Is it possible to take the VIC-SSS-MMX.h and VIC-SSS-MMX.s files, add them into CBM prg Studio as .asm files, changing any assembler directives then build with my code?
https://github.com/theflyingape/vic-sss
Or am I missing something?
Any help would be gratefully received.
TIA
BigJinge
This is regarding the VIC-SSS API and a question of use within a different assembler.
Whilst I've coded in a number of languages over the years, I wanted to write a game in assembler for the VIC.
Looking through, I realised that I'd need to write routines for software sprite mapping and double buffering. Then I came across VIC-SSS by Robert Hurst / theflyingape which does all that. Rather than reinvent the wheel, I'd go with that.
I want to use CBM prg Studio to write assembler. It's a nice IDE with all built in. The vic-sss documentation says that its code is designed to be used with cc65, I don't want to write in C mind.
Is it possible to take the VIC-SSS-MMX.h and VIC-SSS-MMX.s files, add them into CBM prg Studio as .asm files, changing any assembler directives then build with my code?
https://github.com/theflyingape/vic-sss
Or am I missing something?
Any help would be gratefully received.
TIA
BigJinge
- Mike
- Herr VC
- Posts: 4858
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Software sprites?
Welcome!
beamrider wrote a wrapper to be able to call functions in the SSS library from C, but use of C isn't mandatory. Originally, the client source code was supposed to be written in assembly language, in the source format of ca65.
Greetings,
Michael
Note the source code of SSS primarily is written for ca65, the symbolic assembler that comes with the cc65 package.BigJinge wrote:I want to use CBM prg Studio to write assembler. It's a nice IDE with all built in. The vic-sss documentation says that its code is designed to be used with cc65, I don't want to write in C mind.
beamrider wrote a wrapper to be able to call functions in the SSS library from C, but use of C isn't mandatory. Originally, the client source code was supposed to be written in assembly language, in the source format of ca65.
That is possible for sure, and adapting source is normal business if someone wants to use source code written for one assembler for another assembler.Is it possible to take the VIC-SSS-MMX.h and VIC-SSS-MMX.s files, add them into CBM prg Studio as .asm files, changing any assembler directives then build with my code?
Greetings,
Michael