Preppie

FastBasic, and TurboBasic, can handle sprites fine using the MOVE command to shift data around. Even standard Atari Basic can do it with a little trick where you point a string to the same area as the PMG and then shift the data using normal string commands.

Fully abbreviated FastBasic is now harder to read than a hex dump 😂

I was supposed to be writing a quick little game for ABBUC and I got side tracked - I need to put this on the backburner

I was just thinking 'why the hell don't I unroll that inner loop' My answer was 'because I can't adjust all those absolutes', to which my reply was 'you should have used indirect indexed from the start you moron' 😄 You live and learn, I'm just an assembler noob so I've learned a lot doing that routine as it is and now I get to rewrite it - woohooo!

Ok, that did the job I'm now matching Jankovic's (popmilo by the look of the photo i guess ) 14 sprites at 25fps (or 7 @ 50fps ofc) - video is his not mine. I guess I could have asked for the code but where's the fun in that? Don't think I can push it any further but I'll have another look later.

edit: nah, that doesn't work lol

Just to clear up a little confusion, the screen uses 4 character sets interleaved and the code self-modifies so I can use absolute addressing in the central loop instead of Indirect Indexed. Although it's a little heavy in the outer loops those 1 cycle savings payoff due to the number of times the inner loop runs. Therefore change_font & change_bck point to the absolute addresses that I'm modifying here. ldx character lda tab_lo,x sta change_bck+1 lda tab_hi,x clc adc change_font+2 sta change_bck+2 I think this should do the job if I don't mind throwing away some more RAM (isn't that always the case). Although won't I need 2 pages for the tables as each character could be 0-255 due to the fifth color. I could add an AND #%01111111 at the start and just use 1 page for the table I suppose (edit: MaPa pointed this out) I think I can do away with the CLC too as long as it's clear going into the main routine. Thanks everyone, especially popmilo who got in first with that solution.

I've wrote a soft sprite routine and think I've got it nice and fast but I'm trying to squeeze every last bit out of it. Here's the bit of code i'm trying to squeeze: lda character ;load the character value (0-255) tax ;save character in X-reg and #%01100000 ;isolate the hi bits asl ;shift left ensuring carry is clear rol rol ;rotate the bits to be in bits 0 & 1 rol adc change_font+2 ;add bits to hi-byte (MSB) sta change_bck+2 ;store the resulting value txa ;Get character value back from X into A asl asl ;3 asl = multiply by 8 asl sta change_bck+1 ;store the result in lo-byte (LSB) Note: it's in antic 4 so although I'm not interested in bit7 of character it may be set. Basically it's adding 0-3 to the hi-byte depending on bit6&7 and then mulitplying the lower 5 bits by 8 to get the place in the font set. I've wracked my brains and come up with nothing better, even tried a little table in ZP to turn 0,32,64,96 into 0,1,2,3 but it was no faster the way I coded it. Maybe there's some bit wizardry that could do it. I work this out to 36 cycles, it needs to run 9 times per sprite for a total of 324 cycles. I know it's not a lot but every cycle saved helps

oh, didn't realise it was a necro

Fantastic bit of coding, more than I could dream of doing - but, I hate flicker If you can design a game around the flicker limitations then you've hit gold.

I have that one too But I thought they were just showing the single tape boxes.

gee, thx 😊

Here's what's in my collection: Sorry about the flash, it's a bit early to light it naturally edit: found 2 more:

Sorry, I'm a fool. Was using a ZP myself in a loop - d'ho!

I'm using MADS and was confirming the page zero I can use. According to memory maps the top half of the page should be available but if I store anything in 219/220 the system crashes, and this also makes me question the other 4 bytes in this area: Memory maps seem to be a bit uncertain on this, anyone know what it is?