Hi Guys...

Just joined up and this is my first post...Posssibly looking at doing some BBC coding.... My friend was demoing his C64 game at Retro Reunited, and some of you guys saw this... the space shootem up....

Now I'm a C64 programmer, and would like to see how easy it is to plot c64 sprite data on a BBC screen.... I think mode 5? is the best choice 160x256 close to the c64 resolution.... Eg... I want to emulate the c64 hardware sprites on a beeb display.....

C64 sprites use blocks of 64 bytes in memory (63 bytes) each.... 12 pixels across (2bit colours, so 4 pixels per byte = 3 bytes ) and 21 pixels deep (21 bytes)... quick sanity check... 12 x 21 x 2 / 8 = 63

This may seem a silly thing for you chaps... BUT myself and my friend have 2 games (mine is 3/4 finished )

All the graphics are done, so if it would be possible to plot just 8 sprites on the bbc screen (plus bullets and stars etc that are done with 4x8 characters - may need to optimise that and make smaller for speed) - Then that would make the convertions fairly straight forward.. and keeping the native graphics - Unfortunately C64 sprites can have their own 4th colour ( clear, colour 1, colour 2, and a unique colour for each), so would have to make them all the same colour....

Anyway.. just a thought, and would appreciate some comments and advice... on how achievable this is.... c64 cpu runs at 1mhz, bbc run at 2mhz ? so there is some overhead for the extra graphics.....

I also appreciate that the sprite data may need to be re-formatted (maybe interleaving all the data to make indexing quick and code efficient) to make plotting more efficient (not sure how the bbc graphics work yet - but I realise its a bitmap screen display) - or might be able to do bit shifts prior to plotting..

(edit - just to make things more complicated - c64 can double the size of the sprites, horizontal or vetical or both - but its rarely used for our two games - so I'd worry about this further along the line)

2nd edit.. I just dumped ALL of the sprites out of one of the games (Jasons) and its 12K worth in a binary file - so thats 192 sprite images.... I'm weighing up if this is workable.. Sprite Data (12k) , plus mode 5 (is that 10K ??), Leaving 10K for the Game code (including some extra graphic data and the zero page and stack ??)... as you only have 32k Ram.. is that right ... does it make sense ?

Cheers, Colin

Hi Colin,



Fairly easy to convert the data in a visual sense, I've used screenshots from C64 games in some of my stuff. You may want to investigate Mode 2 as well which has the same resolution and aspect ratio as Mode 5 but you get 8 colours (well Acorn would have you believe it was 16 but due to crappy hardware in this area.... it's 8 in reality). Downside with Mode 2 is it eats up twice as much memory and sprites can take twice as long to plot for the same size as twice as much data to move about.



Yes, on paper it may seem that the processor being twice as fast would balance out the hardware sprites, in reality the hardware sprites still more than compensate for most bit mapped games on the C64. So for most games it can be challenging to maintain a decent speed. Where the Beebs processor would take advantage would be games like Elite and Chess etc.


Have a look in the advanced user guide for screen layouts, but be warned the layout is a right pain in the arse ! Also on the Swift Wiki page http://www.retrosoftware.co.uk/SWIFT you might find a download PDF explaining common graphic formats used for BBC gaming, if not then it's contained in the main download for Swift.



That's right, but in reality the OS uses up a fair bit as well, but you can scrimp around and (if it's a single tape load) squeeze in code in various areas. Again the advanced user guide can help you here.

Thanks for that.... I've just set up the Swift sytem and using the 'code name droid' as an example.....

for the Main.... I've ripped it out and replaced with.....

Main:

ldx #$00
loop2:
txa
sta $3000,x
sta $7f00,x
inx
bne loop2
loop3:
jmp loop3

rts

This just plots some garbage at the top and bottom of the screen memory....

Quick question....

What do I have to edit in this project to give me a mode 5 screen please ?

For the BOOT... it says....

MO.2
VDU 19,8,0,0,0,0
*MAIN

I just changed it to MO.5 amd it seems to work ??

Presumably the VDU thing is quite important.... I guess... ???

I'll then see if I can plot a C64 format sprite onscreen..

I'm a complete noob to the BBC arcitecture... so really havent a clue... I just know how to code 6502 (and microchip Pic)...

Ohh... another Stupid question.... IS it OK, just to store directly to screen memory... or will this bugger me up on different models ???

Cheers, Colin

I should have commented these bits. I can't remember what sprite plotter I implemented in the Codename Droid example but it sounds like it's a routine that can plot with a mask. This is because

VDU 19,8,0,0,0,0

Redefines logical colour 8 to display as actual colour 0 (black). If you remember Mode 2 is a 16 colour mode (4 bits per pixel). I use %0000 as the mask and to get a true black I use colour 8 and redefine it to show as black and not the horrible flashing colour that it would normally display as.

The mask issue aside, the screen layout is the same for mode 2 as it is for mode 5 so your actual code to shift sprite data from memory to screen is basically the same. Just your sprite data in memory will be different.



No question is stupid You've no worries writing directly to screen memory, in fact if you don't you'll never get the speed you want (depending on your game). Across the 8 bit range you can rely on the screen start address's being the same for each mode on all models.

Cool.... would have coded some more by now but been sidetracked with other issues....

What is the 19 referring to..... ? Memory location 19 onwards in VDU memory map ? and what are the 4 '0's at the end ? (Yes I know... RTFM, lol)

EDIT - Dooh...

http://www.compulink.co.uk/~rrussell/bb ... html#vdu19

Haven't read it fully yet.... but that should keep me busy for the time being, lol


I think I read that there is something in the harware that will clear the screen, very fast, and not down to the cpu...Is that right and if so, how do I kick that off ?

Thanks for your help... Its great that I've got some code running so fast, but still not a clue what's happening elsewhere.... we will come to that soom....

Regards, Colin

Next up is syncing to the screen refresh...... but I must get a sprite plotted first (and worry about overlaps,masking and stuff much further down the line, lol)

Say I wanted to change something half way down the screen (like the pallet), I guess I would have to sync up to the screen refresh at the top and use a timer to generate an interupt further down the screen ?

The C64 has a raster line register that you can read, or set up to generate an interupt as you please. But I'm guessing theres a lot more to this on the BEEB....

Lets see if I give up and throw the towel in, plotting sprites first, though !!

Cheers, Colin

No such thing I'm afraid, perhaps it was referring to setting all the colours to black which would blank the screen (as apposed to clearing to 0). This technique can be used to set all colours to display as black whilst you build up a level and then allow you to instantly display it by setting all the colours back to normal.


Easy to do, look up FX19 or OSBYTE (passing param 19) in the advanced user guide or a quick google revealed this page http://central.kaserver5.org/Kasoft/Typ ... /Ch42.html


Spot on, the Beeb has hardware timers on it's 2 6522 chips, so not to hard to implement. More advanced games use these timers for such effects.



Oh, a raster line register for interrupts, that'd be good on a beeb but alas.... Basically you've to use the 6522 timers to get the interrupt to occur where you want. A experienced commercial games writer on the Beeb and other platforms (RichTW) is a good source of knowledge in this area and is currently working on some even tighter interrupt driven display code.


No don't give up. I think you will be in for a shock on just how 'fiddly' (not necessarily hard) it can be to get games and sprites going on the Beeb. The Beebs big strengths were in many other areas that were better than the other Micros of the day, but when it comes to the display hardware.... well (hope I'm not lynched for this) the C64 IMHO had the edge (apart from lack of high resolutions). Despite it's slower processor the hardware sprites and other goodies (sound for example) made games generally easier to knock up and look good. Games like Elite however were not very good at all on a C64 due to the maths involved and the fact that the hardware sprites couldn't be used for that type of game.

You seem to have some good experience and it'd be great if you can use that on the Acorn platform too, which is under represented in the new games department. Look forward to seeing some of your work

Right..... made a little progress, although I haven't spent very much time on it....

I stuck a C64 sprite into a data table, and copied it over to the screen memory... It came out all horrible.....

Now... I didn't realise that the BBC stores its colours in the hi/lo nybles, while the C64 stores in pairs of bits... eg c64 Pixel1, HI, Pilel 1, LO, Pixel2, HI, Pixel 2, lo etc.... While BBC is Pixels 1-4 High Nyble, Pixel 1-4 Low Nyble....

Wrote a quick bit shifter.... and it now displays.....

I've got a LOT more work getting it moving around the screen, and as mentioned above, its going to be VERY cpu intensive (and thats even before doing any masks and stuff)... Will have to use some look up tables and stuff, which sounds from what I gather pretty normal for the BBC...

I'll be just moving it up/down the screen for now.... which should be easy to do, but I think it wll be tricky getting it moving smoothly left and right....

Cheers, Colin

Well.... I've got the data converted, and it plots.... but only in multiples of 8 pixels on the screen.... so I've got a lot of work to do yet for smoothe movement ..... and its not doing any or's or xors' or anything... however its pretty quick !!

What I might try to do is expand the code so it plots 4x4 char sprites instead of 3x3 chars (using the same code base idea) and move the sprite around in the sprite memory 'before we plot' data.... I'm not quite sure yet... how to approch..

Up and down should be reasonably straight forward, but not sure about left / right..... I am really going to have to compromise on the amount of sprite data, due to the limits of how this machine works.....

Anyway... heres the code I've knocked together... and it must be run in mode 5..... At the moment, you need to copy the 64 bytes to the sprite, and then call the plot.... so there will be an overhead.... This is my first method, more may follow..... once I start to find limitations or bottlenecks...

Comments appreciated.....

Cheers, Colin

.org $1900 ; load a traditional Beeb start address for a disk system
; we'll load in other code lower than this after we've started

.require "Macros"
.require "AcornConstants"

Main:

Jsr fixsprites ; Takes the c64 sprite (sprite) , reformats it , copies/unshuffles data to worksprite, them copies it back to Sprite

mainloop:

ldx #$58
ldy #$00 ; screen plot starts at 5800
stx $73
sty $72

ldx #$00
ldy #$00

disploop:

tya
pha
jsr spritesub ; spritesub only uses Y and A , no need to save X
pla
tay

lda $72 ; this just adds an offset to the next sprite plot
clc
adc #$20
sta $72
lda $73
adc #$00
sta $73

inx
cpx #10 ; plots 10 sprites
bne disploop
ldx #$00

lda $72 ; adds another offset so line moves down a little
clc
adc #$88
sta $72
lda $73
adc #$02
sta $73

iny
cpy #9 ; does this 9 times
bne disploop

inc working+3 ; This is just to test the speed of the plot
lda working+3
and #$01 ; we just alternate between plotting good sprite data and blank sprite data
bne blank

ldx #$00 ; copy a nice sprite to sprite
copy:
lda worksprite,x
sta sprite,x
inx
cpx #64
bne copy
jmp mainloop

blank: ; blank the sprite for blank plot
ldx #$00
txa
bloop:
sta sprite,x
inx
cpx #64
bne bloop
jmp mainloop

; sprite is in 'native' c64 format data
Sprite:
.byte $00,$00,$00,$00,$d7,$00,$01,$55
.byte $40,$05,$55,$50,$35,$55,$5c,$15
.byte $ff,$54,$d7,$aa,$d7,$de,$82,$b7
.byte $7a,$3c,$ad,$78,$d3,$2d,$e8,$c3
.byte $2b,$e8,$cf,$2b,$7a,$3c,$ad,$7a
.byte $82,$ad,$de,$aa,$b7,$d7,$aa,$d7
.byte $15,$ff,$54,$35,$55,$5c,$05,$55
.byte $50,$01,$55,$40,$00,$d7,$00,$00

; used for un-shuffling data
Worksprite:
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00
.byte $00,$00,$00,$00,00,$00,$00,$00

working:
.byte 0,0,0,0

Spritesub:

; works out the 9 characters that we need to copy the data to.....

lda $72 ; add 08
clc
adc #8
sta $74
lda $73
adc #$00
sta $75

lda $72 ; add 16
clc
adc #16
sta $76
lda $73
adc #$00
sta $77

lda $72 ; add 320
clc
adc #$40
sta $78
lda $73
adc #$01
sta $79

lda $72 ; add 328
clc
adc #$48
sta $7a
lda $73
adc #$01
sta $7b

lda $72 ; add 336
clc
adc #$50
sta $7c
lda $73
adc #$01
sta $7d

;#######################

lda $72 ; add 640
clc
adc #$80
sta $7e
lda $73
adc #$02
sta $7f

lda $72 ; add 648
clc
adc #$88
sta $80
lda $73
adc #$02
sta $81

lda $72 ; add 656
clc
adc #$90
sta $82
lda $73
adc #$02
sta $83

;#######################

; plot 3 chars of sprite into two rows...

ldy #$00
sloop1:
Lda Sprite,y
sta ($72),y
Lda Sprite+8,y
sta ($78),y
Lda Sprite+21,y
sta ($74),y
Lda Sprite+29,y
sta ($7a),y
Lda Sprite+42,y
sta ($76),y
Lda Sprite+50,y
sta ($7c),y

iny
cpy #8
bne sloop1

ldy #$00 ; plot last row (not so tall - only 5 pixels high)
sloop2:
Lda Sprite+16,y
sta ($7e),y
Lda Sprite+37,y
sta ($80),y
Lda Sprite+58,y
sta ($82),y
iny
cpy #5
bne sloop2
rts

;#####################

fixsprites:

ldx #$00
loop1:
lda sprite,x
sta working
sta working+2
lda #$00
sta Working+1
sta working+2
ldy #$04
Looprol:
asl working
rol working+1
asl working
rol working+2
dey
bne looprol
asl working+1
asl working+1
asl working+1
asl working+1
lda working+1
ora Working+2
sta sprite,x
inx
cpx #64
bne loop1

; alter all the bits in the graphics to bbc format

ldx #$00
ldy #$00
scon1:
lda sprite,x
sta worksprite,y
inx
lda sprite,x
sta worksprite+21,y
inx
lda sprite,x
sta worksprite+42,y
inx
iny
cpy #21
bne scon1

ldx #$00
scon2:
lda worksprite,x
sta sprite,x
inx
cpx #64
bne scon2
;Sprite now nicely converted to a kind of bbc workable format.....
rts

That's quite a nasty way of plotting sprites. Though fast, the 8 pixel limit and the shifting of sprite data you describe will cripple it. It would probably pay off to have a slightly more complex inner loop, eg :



The sprite data used is the same format as C64 sprites (but with the Beeb's byte order), rather than interleaved as the screen uses.

Horizontally you'll want to use preshifting but this has an impact on memory... Depending on how the game uses sprites, you may want to keep most sprites compressed in memory, and decompress and preshift them just before they come on screen.

Thanks.... I'm a complete NOOB to plotting stuff on Hi-Res screens, so please excuse the lame code.

I appreciate this will be cool if I'm moving stuff around just 8x8.... and yes.. it is fast...

I've clearly got a LOT to learn at the moment (and get my head around).. As above, not done this ever before, lol !!! - I was spoilt with c64 sprites...

Thanks for the input.

Regards, Colin

I'm chucking an improved Mode 2 plotter (with mask) up in the next couple of days on the Wiki if that's any help. It's all written, just need to improve comments and do some sprites.

Thanks.... I will prolly be way over my head, lol... (as is Tom's code so far)

I can code to a reasonable extent (maybe not the best programmer - all self taught) but I'm struggling to suss all this hi-res stuff... , so I'm fairly pleased that I've got this far, so far, with limited knowledge....

Won't throw in the towel just yet...... (but I've got a lot of other stuff on my plate too, some other projects and real life (tm) stuff, lol...

Edit... This is prolly a fairly reasonable char plot routine (which is what I meant it to be initially) - but I'm learning a LOT along the way.... and struggling, lol (and no... Derren Brown did NOT stick me to my seat, lol) - I've got my first c64 sprite up (as a char plot), so I'm happy so far....

I think you'll be surprised, there's no de-compression or anything like that. Just pumps out raw sprite data to screen as fast as it can. So I'm sure you'll follow it just fine. Keep up the good work.

Thanks.. I'm quite scarred about the memory limits with a mode 2 screen, SO.. I guess, I'll have to start learning about code efficiency, and knocking the number of sprites right back (the game I'm looking at has 12K of c64 sprites) and my own game uses about 10K.... so would have to trim back the animations quite a lot (and resize, redraw so they are a little smaller, so have a smaller footprint too) - if you include the fonts and banners, I'm looking at a LOT of c64 memory, just for the origonal graphics... Yes, I was spoilt a tad.....

Cheers, Colin

Yep, it's tight for sure on a Beeb... very tight indeed. Hope you stick with it though. For compression of sprites and level data (that is not immediatly required, i.e. expand at start of a new level) have a look at this page that DaveF submitted.

http://www.retrosoftware.co.uk/wiki/ind ... _Pu_Crunch

I've not implemented it yet but will be doing.

Ahhh... Tom's code is quite straight forward once read while sober, lol.....

There is definately a trade off for speed / vs code size and other stuff.... you win some and you loose some too..... The bit #$07 is cool...

I'm fairly sure I can work out a faster way (if nasty, lol) of shuffling c64 data (to plot in multiples of 8 pixels) - I'm very very much still in an experimental / mucking about mode at the moment... It will most probably take a Lot more memory though, and more brute force than efficient coding..... damn shame they only did the zero page adressing using Y.... and not x.....

eg... you could have some smallish efficient code... but repeat it 8 times with differnet variants, depending upon which line it was on..... it would speed up things, but be more memory hungry....

Might just end up using for 'setting up a screen' and not for sprite plotting as such.... but its certainly opened my eyes with the differences, and challenges involved...

The pixel based sprite plotting/masking stuff is still way way over my head though, so well done chaps....

Cheers, Colin

Finding this a little frustrating..... Grrrr , lol

I've use a slightly modified screenposition code (to work in mode 5)

and am using Tom's example sprite plotter code...

Seems to be having an issue with the page boundary wrapping around... but I can't get my head around it.....(its mostly working, but sprite 6 is giving jip !!)

I've either screwed up modding the screen pos calculation, or there is a page bug in the sprite plotter....

Heres the code...... any comments appreciated please...... Cheers, Colin

;############################################

.org $1900 ; load a traditional Beeb start address for a disk system
; we'll load in other code lower than this after we've started

Main:
Jsr fixsprites ; Takes the c64 sprite (sprite) , and reformats it
start:
ldx #$00
mainloop:

txa
pha
lda xtable,x
sta $74
lda ytable,x
sta $75
jsr Screenstartaddress
jsr plotmysprite
pla
tax

inc ytable,x
lda ytable,x
and #$7f
sta ytable,x

inx
cpx #$08
bne mainloop

jmp start

;#############################

plotmysprite:

lda #21 ; 21 lines
sta $a2
lda #<sprite
sta $a0
lda #>sprite
sta $a1
jsr pltloop ; toms
rts

;###########################

;toms code................
;$A0/$A1 is sprite data address, data doesn't cross 256-byte boundary
;$A2 is number of lines in sprite
;SWADDR ($78,$79) is dest address on screen

pltloop:

ldy #0
lda ($A0),y
sta ($78),y

ldy #1
lda ($A0),y
ldy #8
sta ($78),y

ldy #2
lda ($A0),y
ldy #16
sta ($78),y

clc
lda $A0
adc #3
sta $A0

inc $78
lda #7
bit $78
bne pltlc

lda $78
clc
adc #$38
sta $78
lda $78+1
adc #1
sta $78+1

pltlc:
dec $A2
bne pltloop

pltdn:
rts

;#############################################

; constants

.alias ScreenStartHighByte $58 ; high value of start of screen

;memory locations used

; entry params
.alias XOrd $74
.alias YOrd $75

; exit results
.alias XYScreenAddress $78 ; and $79 contain the returned calculated screen address

; workspace
.alias Temp $9F

ScreenStartAddress:

lda YOrd ; load A with the value of the Y ordinate
and #248 ; make lower three bits zero (see next paragraph)
lsr
lsr
tay ; we will use register Y to index into the table
; so move the index value into Y
lda LookUp640,Y ; look up low byte value first
sta XYScreenAddress ; and store in low byte of result
iny ; move the index to point to the high byte in the
; table
lda LookUp640,Y ; get the high byte result of the mulitplication
sta XYScreenAddress+1 ; store in the high byte of the result

lsr xyscreenaddress+1 ; halves it for 320 mode !!!
ror xyscreenaddress

clc
lda #ScreenStartHighByte ; high byte value of screen start address
adc XYScreenAddress+1 ; add to current high byte value
sta XYScreenAddress+1 ; store result back in high byte value

lda Yord
and #$07
clc
adc XYscreenaddress
sta XYscreenaddress

lda XOrd ; ignore the 3 lower bits of Xord position
and #$f8

clc
adc XYScreenAddress ; add A (low value of multiply to low value of
sta XYScreenAddress ; store in low value of result

lda XYScreenAddress+1 ; add to high byte of result with any carry
adc #$00
sta XYScreenAddress+1 ; store in high byte of result
rts


fixsprites:

ldx #$00
loop1:
lda sprite,x
sta working
sta working+2
lda #$00
sta Working+1
sta working+2
ldy #$04
Looprol:
asl working
rol working+1
asl working
rol working+2
dey
bne looprol
asl working+1
asl working+1
asl working+1
asl working+1
lda working+1
ora Working+2
sta sprite,x
inx
cpx #64
bne loop1
rts

working:
.byte 0,0,0

ytable:
.byte 0,0,0,0,0,0,0,0
xtable:
.byte 0,24,48,72,96,120,144,168

LookUp640: ; a 640x multiplication table
.byte $00,$00,$80,$02,$00,$05,$80,$07,$00,$0A,$80,$0C,$00,$0F,$80,$11
.byte $00,$14,$80,$16,$00,$19,$80,$1B,$00,$1E,$80,$20,$00,$23,$80,$25
.byte $00,$28,$80,$2A,$00,$2D,$80,$2F,$00,$32,$80,$34,$00,$37,$80,$39
.byte $00,$3C,$80,$3E,$00,$41,$80,$43,$00,$46,$80,$48,$00,$4B,$80,$4D

Sprite: ; sprite is in 'native' c64 format data
.byte $00,$00,$00,$00,$d7,$00,$01,$55
.byte $40,$05,$55,$50,$35,$55,$5c,$15
.byte $ff,$54,$d7,$aa,$d7,$de,$82,$b7
.byte $7a,$3c,$ad,$78,$d3,$2d,$e8,$c3
.byte $2b,$e8,$cf,$2b,$7a,$3c,$ad,$7a
.byte $82,$ad,$de,$aa,$b7,$d7,$aa,$d7
.byte $15,$ff,$54,$35,$55,$5c,$05,$55
.byte $50,$01,$55,$40,$00,$d7,$00,$00

I think once I suss the basics out, I should be able to knock up a simple 'phoenix' type of game (with no, or minimal overlaps of the graphics)... There is a method to all this madness, lol.... I'm NOT worrying about over lap stuff yet (as this will really slow things down)...

Probably WILL go for mode 2, yet, but I need to suss as I said above...

Cheers, Colin

Sorry, for empty post, posted something then realised it was rubbish, will get back to you about this tomorrow.