Sprites that can be used from BASIC

[tricky]

It also let's you replace one of the (),y with abs,y - thanks RichTW.

[TobyLobster]

yes - nice! Something like:

Code: Select all

    lda spr_col0,x
    sta mask0+1
.mask0
    lda masks
    and (screen0 + 1),y
    ora mask0+1
.screen0
    sta &ffff,y

[tricky]

I think RichTW allowed his routine to run off the end of zp to make more room for "variables" but had to jump/bit/? Over &FC where the interrupt handler wires A before you get a chance to stop it.

[TobyLobster]

I found the previous discussion: http://www.retrosoftware.co.uk/forum/vi ... f=73&t=932
An 'LDA #' opcode at &FB skips over the problematic &FC memory location.

Which also links to this: https://web.archive.org/web/20150630035 ... ry20101030

[Iggypop]

A character row address: lda spr_y : and #&F8 : lsr A : lsr A : adc #HI(SCREEN) ; if screen is &40000, we could use ora, but it is the same cost here
A row offset in bytes: lda spr_x : and #&FC : asl A ; A=LO(offset), C=HI(offset)

Hi tricky I lost you on these two lines... are you saying that when you have a screen 256x256 HIMEM can be at &4000 in mode 1 ?
And what do you mean by #HI(SCREEN) &40? IF Y would be 67, and X an multiple of 8 for simplicity.... than
01000011 AND 1111100 = 0011 shift richt twice (divide by 4) = 0000 ?????

igor

[tricky]

When changing the screen layout, BASIC doesn't know what you have done and nor does the OS with regard to drawing text etc.
To make BASIC think that memory starts at &4000, you could change to mode 3, then setup the MODE 1 256x256 by setting the registers directly or via VDU commands. This shopuld have HIMEM at &4000, but drawing to the screen would not work correctly as the OS would still think that you were in MODE 3.

The code does and ADC #HI(SCREEN) which with the screen would be ADC #&40 and ass the rest of the address calculated is the offset, it would be less than &4000, so ORing it with #&40 would give the same result as adding &40. It makes no difference here but sometimes it saves a byte and two cycles as you don't need to CLC.

Sorry, most of that was written on my phone, so may not be 100%!
The carry from the second line needs adding to the first result so that X>=128 is in the second page of the char row.

Your AND is missing a 0.
01000011 AND 1111100 = 0011 shift richt twice (divide by 4) = 0000 ?????
01000011 AND 11111000 = 01000000, shift richt twice (divide by 4) = 00010000 = &10 or the first line in the second quarter.

[modboy]

So the kids and I had a bit of a play with some graph paper and felt pens last night. We are going to write a Bruce Lee Vs Ninja's platform game using Trickys BASIC sprite routines.IMG_20201009_094253.jpg

Interesting, how did your kids get on?
I've drawn my graphics for mode 2 manually in assembly line by line after drawing them in an editor on a PC. I've not used sprites or BeebASM. All done on a BBC B. Only just discovered there was this great app called AcornPad and this other great app BeebSpriter. I can do nice animations but the game part will be much harder. I'm trying to hack something together with really good graphics. Treating one screen Bruce Lee as a separate game so you advance with loads to each screen. If I can just figure how to pass data so that it loads from Turbo MMC utilise 16KB RAM blocks on an expansion board too. I could do crazy spiders and robots for the web but all this is another level completely only starting to appreciate how intelligent these 80s hackers were to do so much on so little memory.