Hexapelago (working title)

[jubber]

Well, we don't have a really good conversion of Crysis on the beeb

That's an FPS isn't it? It seems highly unlikely at the moment. I'm trying to avoid clones, I don't do FPS (with the odd WWII exception), and I don't think the Beeb does FPS either Never say never though, eh?

Hex grids are great. Think you can stuff Civ IV into 19.5K?

Hex grids are great. Civ IV is probably great (my Civ days were earlier instalments though). But that would be another clone.

No shortage of ideas anyway. Looks like I'm making five or six games then.

Heh - I'm not actually suggesting you make Civ IV or Crysis, those were just dumb jokes, considering the huge hardware requirements of each. Crysis is famous for being horribly demanding even on modern PC hardware. There's a well-worn joke that turns up on any forum discussing the latest supercomputer - "yeah, but can it run Crysis?"

I'm glad to hear my kids might eventually give me some free time back - it's nice to dream - but my youngest is just weeks old, so I'm not holding my breath!

[cola5pandex]

Heh - I'm not actually suggesting you make Civ IV or Crysis, those were just dumb jokes, considering the huge hardware requirements of each. Crysis is famous for being horribly demanding even on modern PC hardware. There's a well-worn joke that turns up on any forum discussing the latest supercomputer - "yeah, but can it run Crysis?"

I'm glad to hear my kids might eventually give me some free time back - it's nice to dream - but my youngest is just weeks old, so I'm not holding my breath!

I did wonder if you were joking or just crazy. Hard to tell when I can't see your face, you're not using smilies and I've never played either of those games.

[ChrisB]

Good to see another project starting! Good luck with getting it to completion. As far as suggestions go I think your turn based XCOM/Frozen Synapse type game might be interesting. I don't recall anything like that BITD. I presume the enemy AI is the hard part here. The "Farming Simulator" like stardew valley/Harvest moon is also not something I've seen either - although that's going to be a lot of graphics.

[tricky]

I don't know if it is your kind of game, but I've thought a couple of times about a fantasy themed laser squad game.
Personally I write arcade comes, so I'm not likely to do it.
PS yes, I used ~= as a short hand for x = ~x.

[cola5pandex]

the 6845 has a hardware cursor apparently.

I've only just noticed this. You were obviously getting to the bottom of it before I even offered my explanation. The CRTC does indeed control the cursor (position, size, etc), although it is the VIDPROC that is responsible for the colour changes that fooled you into thinking it was mode 1. I have a little update on this but I'll come back to that.

[cola5pandex]

Unless you get very fancy with beebasm-specific features, you would probably be able to port the source over to another assembler later on without too much pain.

And although the SSD output makes beebasm extremely convenient for BBC users, it can also save its output to regular files on the host machine, which you would then be able to package up as a C64 disc image using the relevant tools, so if you did create a C64 port you could still build it from beebasm source files.

That said, you can obviously use any "modern" 6502 assembler. acme seems quite popular (other assemblers are available!) and assembles to regular files on the host machine, which you could package up into an SSD from a build script using something like sweh's MMB_Utils.

The nice thing about beebasm is it's a kind of "one stop shop" for Beeb development. It can tokenise BASIC, which is handy if you want to write loaders or other non-performance critical code in BASIC, as well as produce an SSD with no extra effort. But once you have a build script set up, using a generic assembler like acme works just as well (and you can use beebasm just to tokenise BASIC, or use something like basictool). It's just setting up the build script and associated tools in the first place that is a bit of a faff if you don't use beebasm.

PS Very cool looking project, by the way!

Thanks for all that Steve. I've made significant progress in this department now, thanks to all the advice I got here. Update coming shortly.

[cola5pandex]

The best 6502 assembler I've used is 64tass: https://tass64.sourceforge.net/ - really excellent, with loads of great features. I've also found the author very helpful when filing bug reports or feature suggestions.

It has no BBC Micro support whatsoever, though, so for Beeb stuff you're a bit on your own! For ROMs, its flat file output is fine; for files to go on disk (where load/exec address is relevant), I use Python scripts to convert the C64 PRG output files into something the BBC can use. See prg2bbc and ssd_create here: https://github.com/tom-seddon/beeb/tree/master/bin

--Tom

Thanks a lot Tom. I'm trying out Beebasm for now but I will bear this in mind if that doesn't suit my needs. I assume you're a C64 head first and foremost. I've never programmed one of those babies. I've never even owned one. But that needs to change (the programming part at least). And if/when I'm ready to port there's a good chance I will be calling all C64 heads.

[cola5pandex]

Good to see another project starting! Good luck with getting it to completion. As far as suggestions go I think your turn based XCOM/Frozen Synapse type game might be interesting. I don't recall anything like that BITD. I presume the enemy AI is the hard part here. The "Farming Simulator" like stardew valley/Harvest moon is also not something I've seen either - although that's going to be a lot of graphics.

Thanks Chris. Enemy AI is probably the impossible part here. It makes me think of my favourite Russian (Garry Kasparov) and my favourite chess player (Deep Blue). And that's chess, where the number of options is relatively limited, allowing Deep Bluey (as she's affectionately known) to use brute force to beat a world champion on a level playing field. The Beeb's best chance is probably weight of numbers. The AI gets six queens and 300 pawns. The other notoriously tricky one with games like that is getting the balance right (before everyone is playing with one class, one build, one weapon, etc.) We like a challenge though, don't we?

My tiles are 16x16px (plus a top and bottom row that are always the same so they don't need to go in the tile sheet). I was aiming for something like 128 tiles total. That's 4k of RAM. Not enough for Stardew Valley but I could still manage a scaled down version of something like that.

My hands are not tied yet though. And as I said to someone else... Ten games are better than one.

[cola5pandex]

I don't know if it is your kind of game, but I've thought a couple of times about a fantasy themed laser squad game.
Personally I write arcade comes, so I'm not likely to do it.
PS yes, I used ~= as a short hand for x = ~x.

Well Laser Squad is right up my street. I don't know if you read what I said about XCom. Maybe you did but it doesn't ring any bells (too many games, not enough time). But yeah... One of my all-time faves (XCom) basically started life as Laser Squad 2 and then morphed into something slightly different at the hands of the same programmer (Julian Gollop). It's British too (at least it was to begin with). The original was called UFO: Enemy Unknown over here (XCom was its US title) so maybe you know it by that name instead. I'm guessing the XCom name just stuck for later sequels because of how well it did across the pond. You could probably even refer to Laser Squad as XCom Zero. It just depends which way you look at it.

As for your x=~x that makes perfect sense now. My next post will be a quick update on this for anyone who might be interested.

[tricky]

I never played any of them much, but a friend with a spectrum was playing laser squad when I went over a couple of times so I got a couple of demos. I think I tried xcom on the ps1 but I think it got a bit too involved for three time I had. Later I did see others playing later versions and seen to remember a podcast where they talked about the history.

[cola5pandex]

Cursor Colour Update

So by pure coincidence I stumbled across this yesterday...

Video_ULA_serialisation_block_diagram.png (20.31 KiB) Viewed 469 times

That's the VIDPROC chip and those three XOR gates just before the RGB output lines... They are the colour changing culprits.

Not that I was right and Tricky was wrong. It's just that Tricky is talking about code that uses conditional branching, while the VIDPROC is a circuit that needs a different kind of switching mechanism. I could elaborate but you probably all get that straight away. Suffice to say... There's more than one way to skin a cat and both approaches have the same effect (some nice catskin slippers ).

Free beer for anyone who can explain that INVERT input though. I'm guessing it controls the flashing but yeah... That's a guess. I have no idea what it's connected to.

[cola5pandex]

I never played any of them much, but a friend with a spectrum was playing laser squad when I went over a couple of times so I got a couple of demos. I think I tried xcom on the ps1 but I think it got a bit too involved for three time I had. Later I did see others playing later versions and seen to remember a podcast where they talked about the history.

Yes indeed. XCom will steal your life. Especially if you're like me and you spend 30 minutes contemplating each move.

[cola5pandex]

Assembler / IDE Update

So... I went with Beebasm and VSCode, got them set up, converted the code and, after a bit of teething trouble... I am absolutely, definitely winning at life. So far, so good anyway. Everything is working and I've even managed to add a bit more. I can even insert my graphics using binary literals (handy with 1bit pixel art) instead of having to convert to decimal or hex (which is a right royal pain). That will really help. At least until I have an editor that can save in the right byte order.

Thanks guys. I really appreciate all the advice. I am cooking on gas now and should have some half tidy, half readable code for you lot to scrutinise pretty soon.

[cola5pandex]

Week Two

Added another tile, mainly just to test pointer arithmetic at the moment. The screenshot is from the new Beebasm version...

The source code is also half presentable now so you might as well have a look and point out my mistakes before I repeat them...

Code: Select all

tilePointerL=$70 : tilePointerH=$71
tileOffsetL=$72 : tileOffsetH=$73
screenPointerL=$74 : screenPointerH=$75
tileCount=$76 : tileByteCount=$77 : mapColCount=$78 : mapRowCount=$79
OSBYTE=$FFF4 : OSWORD=$FFF1 : OSWRCH=$FFEE

ORG $3000
.start

; Select MODE4
LDA #22 : JSR OSWRCH : LDA #4 : JSR OSWRCH

; Set all logical colours to black (so we can't see)
LDX #LO(lightsOff) : LDY #HI(lightsOff) : LDA #$C : JSR OSWORD
LDX #LO(lightsOff+5) : LDY #HI(lightsOff+5) : LDA #$C : JSR OSWORD

; Initialise some counters
LDA #15 : STA mapRowCount
LDA #0 : STA tileCount

; Loop through each row of the map
.nextMapRow

; Load map row counter into X via A (for subsequent ASL)
LDA mapRowCount : TAX 

; Double it (because 2 bytes per element) and transfer to Y
ASL A : TAY

; Get number of tiles in current row from precalculated table
LDA tblColCount-1,X : STA mapColCount

; Get screen address where current row starts from precalculated table
LDA tblRowStart-2,Y : STA screenPointerL
LDA tblRowStart-1,Y : STA screenPointerH

; Loop through each column in the row
.nextTile

; Draw the first row of 16 pixels using bitwise OR to mask the
; corners of each tile because they overlap. No need to store in
; the tilesheet because it's always the same
LDA #%00000001
LDY #0 : ORA (screenPointerL),Y : STA (screenPointerL),Y
LDA #%11000000
LDY #8 : ORA (screenPointerL),Y : STA (screenPointerL),Y

; Increment screen address. No need to worry about carry or
; character block boundary as first row is always even
INC screenPointerL

; Initialise counter
LDA #32 : STA tileByteCount

; Get start address of tile sheet
LDA #LO(tileSheet) : STA tilePointerL
LDA #HI(tileSheet) : STA tilePointerH

; Load tile counter into X and then increment ready for next
; iteration (keeps track of map location)
LDX tileCount : INC tileCount

; Load tile number for current map location 
LDA tileMap,X

; Skip tile sheet offset arithmetic if tile number is 0
BEQ nextTileRow

; Otherwise multiply tile number (in A) by 32 (no. of bytes per tile)
; to produce tile sheet offset
STA tileOffsetL : LDA #0 : STA tileOffsetH : LDX #5
.nextShift
CLC : ASL tileOffsetH : ASL tileOffsetL : BCC tileOffsetNoCarry
INC tileOffsetH
.tileOffsetNoCarry
DEX : BNE nextShift

; Add offset to start adddresss of tile sheet to produce absolute
; address of tile data
CLC
LDA tilePointerL : ADC tileOffsetL : STA tilePointerL
LDA tilePointerH : ADC tileOffsetH : STA tilePointerH

; Loop through each row of pixels (except the last)
.nextTileRow

; Draw current row of 16 pixels using bitwise OR to mask the
; corners of each tile because they overlap.
DEC tileByteCount : LDY tileByteCount : LDA (tilePointerL),Y
LDY #0 : ORA (screenPointerL),Y : STA (screenPointerL),Y
DEC tileByteCount : LDY tileByteCount : LDA (tilePointerL),Y
LDY #8 : ORA (screenPointerL),Y : STA (screenPointerL),Y

; Skip screen address arithmetic if last row has been reached
LDA tileByteCount : BEQ endTile

; Increment low byte of screen address
INC screenPointerL

; Loop back to draw next row of pixels if screen address is not
; a multiple of 8 (which means we've crossed a character block
; boundary and may also need to carry)
LDA #7 : AND screenPointerL : BNE nextTileRow

; Carry to high byte of screen address if low byte is now zero
CMP screenPointerL : BNE screenPointerNoCarry
INC screenPointerH
.screenPointerNoCarry

; Add 312 to screen pointer because we have crossed a character
; block boundary and want to move down not right
CLC
LDA #LO(312) : ADC screenPointerL : STA screenPointerL
LDA #HI(312) : ADC screenPointerH : STA screenPointerH

; Loop back to draw next row of pixels
JMP nextTileRow

; The last row of pixels now draws itself because it's always
; blank and so we can just end this loop there
.endTile

; Increment low byte of screen address because blank rows still
; count. No need to worry about carry because mathemagic :D
INC screenPointerL

; Skip screen address arithmetic if this was the last column
DEC mapColCount : BEQ endMapRow

; Subtract 625 from screen address to bring us to the start of the
; next tile in the row
SEC
LDA screenPointerL : SBC #LO(625) : STA screenPointerL
LDA screenPointerH : SBC #HI(625) : STA screenPointerH

; Loop back to start next tile in the row
JMP nextTile

; End map row loop
.endMapRow

; Exit loop if last row reached
DEC mapRowCount : BEQ endMap

; Otherwise loop back and start the next row
JMP nextMapRow

; End outer map loop
.endMap

; Set logical colour 1 to reveal
LDX #LO(lightsOn) : LDY #HI(lightsOn) : LDA #$C : JSR OSWORD

; Back to BASIC (or whatever)
RTS

.tblColCount ; number of tiles in each row of the map (for speed)
EQUB 8,9,10,11,12,13,14,15,14,13,12,11,10,9,8

.tblRowStart ; screen address where each row of the map begins (for speed)
EQUW $77A4,$751E,$73D0,$714A,$6EC4
EQUW $6C3E,$6AF0,$686A,$65F4,$637E
EQUW $6240,$5FCA,$5D54,$5ADE,$59A0

.lightsOff ; parameter blocks for OSWORD &C (like VDU19)
EQUB 0,0,0,0,0
EQUB 1,0,0,0,0
.lightsOn
EQUB 1,2,0,0,0

.tileMap ; what it says on the tin
EQUB        0,0,1,1,1,0,0,0
EQUB       1,0,0,1,1,0,0,0,1
EQUB      0,1,1,0,1,0,0,0,0,0
EQUB     1,0,0,1,0,1,1,0,1,1,0
EQUB    0,0,1,0,1,0,0,0,0,1,0,1
EQUB   0,1,1,0,1,0,0,0,1,0,0,0,1
EQUB  0,0,1,1,1,0,0,0,1,1,1,0,0,0
EQUB 1,0,0,1,0,1,2,0,0,1,1,0,0,0,1
EQUB  0,1,1,0,1,2,2,0,0,0,0,0,1,0
EQUB   1,0,0,1,1,2,2,2,0,0,0,1,1
EQUB    0,0,0,1,2,2,2,0,0,0,1,1
EQUB     0,0,1,2,2,0,0,0,1,0,0
EQUB      0,0,1,1,2,2,2,0,1,0
EQUB       1,0,0,1,0,1,1,0,1
EQUB        0,1,1,0,0,1,0,0

.tileSheet ; technically not but misnomers are us. Rows in reverse order.

EQUW %0000000111000000
EQUW %0000011111110000
EQUW %0001111111111100
EQUW %0111111111111111
EQUW %1111111111111111
EQUW %0111111111111111
EQUW %1111111111111111
EQUW %0111111111111111
EQUW %1111111111111111
EQUW %0111111111111111
EQUW %1111111111111111
EQUW %0111111111111111
EQUW %1111111111111111
EQUW %0111111111111111
EQUW %0001111111111100
EQUW %0000011111110000

EQUW %0000000111000000
EQUW %0000011000110000
EQUW %0001111000111100
EQUW %0111000000000111
EQUW %1110101010101011
EQUW %0101110101010101
EQUW %1101111010101001
EQUW %0101111101010101
EQUW %1101111110101001
EQUW %0101111111010101
EQUW %1101111111101001
EQUW %0101111111110101
EQUW %1110111111111011
EQUW %0111001111100111
EQUW %0001110000011100
EQUW %0000011111110000

EQUW %0000000111000000
EQUW %0000011111110000
EQUW %0001111111111100
EQUW %0111111011001111
EQUW %1111111100011111
EQUW %0111110110110001
EQUW %1101111011100011
EQUW %0110111101000111
EQUW %1111010010001111
EQUW %0101100011010001
EQUW %1110110111100011
EQUW %0111011111000111
EQUW %1111101110001111
EQUW %0111110100011111
EQUW %0001111000111100
EQUW %0000011101110000

.end

SAVE "hex",start,end

And you might as well have the ssd too...

hex.ssd

(1.5 KiB) Downloaded 6 times

[lovebug]

screenshot looks great, keep up the good work

[cola5pandex]

screenshot looks great, keep up the good work

Thanks. The graphics and map layout are a bit of a botch right now as I focus on technicalities and mechanics but I am pretty pleased with how it looks so far. Your YouTube channel has a new subscriber anyway. Thanks again for the feedback.

[lovebug]

thanks, ive been lazy and havent uploaded a video of the newer ladybug builds ! now on build 3392 but the latest video is 3350

[cola5pandex]

thanks, ive been lazy and havent uploaded a video of the newer ladybug builds ! now on build 3392 but the latest video is 3350

Well it does say final build. I assumed you were finished with it anyway.

[tom_seddon]

Thanks a lot Tom. I'm trying out Beebasm for now but I will bear this in mind if that doesn't suit my needs. I assume you're a C64 head first and foremost. I've never programmed one of those babies. I've never even owned one. But that needs to change (the programming part at least). And if/when I'm ready to port there's a good chance I will be calling all C64 heads.

Actually, rather the opposite... I've only ever done BBC Micro stuff! I've just found 64tass very good. It's a bit annoying having to put 1 instruction per line, but I got over it. It's full of great stuff:

* https://tass64.sourceforge.net/#sections - sections let you define the layout of the code separately from the code itself
* https://tass64.sourceforge.net/#list-tuples - lists and tuples give you numerous options for constructing tables
* https://tass64.sourceforge.net/#scopes - convenient syntax for labels inside nested scopes. You can also define scopes that will get stripped out if unreferenced
* https://tass64.sourceforge.net/#branch-long - automatically convert "bcc XXX" to "b(opposite cc) YYY:jmp XXX:.YYY" if the branch would be too far. Extremely convenient for the times when you don't care too much. (There's also syntax for forcing the short form when you want it)

And that's without even mentioning .cerror, .cwarn, .page/.endpage, the numerous text encoding options (.shift/.shiftl/.null/.ptext), and the comprehensive (if admittedly ugly) macro language that will let you do pretty much anything else you want if the built-in stuff doesn't apply! It'll do as many passes as necessary to make the code build, so you can demand a lot from it in terms of forward references and it'll just sort itself out.

The listing files are also very comprehensive. On the rare occasions something weird has happened, the listing file has revealed all, without being much effort to disentangle. I've never worried about getting too clever, because as a last resort it's always there to show me exactly what got built.

--Tom

P.S. I really like the pixelly monochrome Mode 4 graphics!

[tricky]

First thing that looked odd

Code: Select all

CLC : ASL tileOffsetH : ASL tileOffsetL : BCC tileOffsetNoCarry
INC tileOffsetH
.tileOffsetNoCarry

could be

Code: Select all

ASL tileOffsetL
ROL tileOffsetH

You may want to CLC afterwards, if that was being relied on but your code looks cleaner than that.

[cola5pandex]

So thanks to a lovely private message from a lovely person (to the best of my knowledge ) I now have a new title for my game. I think it's brilliant and will probably be sticking with it but I'd love to hear what others think of it too.

[cola5pandex]

First thing that looked odd

Code: Select all

CLC : ASL tileOffsetH : ASL tileOffsetL : BCC tileOffsetNoCarry
INC tileOffsetH
.tileOffsetNoCarry

could be

Code: Select all

ASL tileOffsetL
ROL tileOffsetH

You may want to CLC afterwards, if that was being relied on but your code looks cleaner than that.

Of course. I completely forgot that ROL shifts C in too. I told you I was rusty.

As for the CLC I think that's just an artifact from an earlier approach when I only had two tiles and was doing a simple add instead. It is obviously superfluous now because ASL ignores C.

Nice one.

[cola5pandex]

Another one I've spotted myself is right at the start where I select mode 4 and then change colour 0 to black. That isn't strictly required considering that colour 0 would already be black. So if anyone else spots that you can just ignore it.

[cola5pandex]

Actually, rather the opposite... I've only ever done BBC Micro stuff! I've just found 64tass very good. It's a bit annoying having to put 1 instruction per line, but I got over it. It's full of great stuff:
...

P.S. I really like the pixelly monochrome Mode 4 graphics!

Thanks Tom. Some of that does sound very useful. The problem I have here is that with my limited experience of the setup I'm using I have no good way to compare or weigh up the pros and cons. It doesn't surprise me that there are (overall) better assemblers out there though. The Beeb is not as popular as some other machines, especially on the global stage. I will keep all of this in mind. I'm still experimenting at the moment.

As for the graphics... I am fairly pleased with them myself, although I have seen 1bit pixel art that makes mine look completely amateur. Here's my latest screenshot with a few more additions (with a 1:1 pixel ratio this time too)...

screenshot3.png (9.4 KiB) Viewed 211 times

[cola5pandex]

One small problem with that... It's too small. And the magnify option seems to apply some kind of smoothing (making it look blurry).

Try again...

[SteveF]

That looks lovely!

A small suggestion which I'm not sure I even like myself, but I might as well mention it while it's still early: seeing those ship tiles makes me wonder if they would be better to have a black hex with just a green border round them, to indicate they are "sea" instead of "land". I appreciate this might mess up the code, and it's not even certain it would look good even if the code handled it trivially, but FWIW.

I do like the new title too. Congratulations to whoever came up with it!

[cola5pandex]

That looks lovely!

A small suggestion which I'm not sure I even like myself, but I might as well mention it while it's still early: seeing those ship tiles makes me wonder if they would be better to have a black hex with just a green border round them, to indicate they are "sea" instead of "land". I appreciate this might mess up the code, and it's not even certain it would look good even if the code handled it trivially, but FWIW.

I do like the new title too. Congratulations to whoever came up with it!

I see what you mean Steve. Ships on dry land probably do look a bit odd at first glance. They are however intended to represent ports (for travel) and/or trading posts (for buying and selling) as things stand. Think of them as abstract icons rather than figurative representations of actual ships and they should make more sense. A lot of the graphics will have to be like that given the limitations of using just 256 pixels in two colours. And the same kind of thing applies to proportions too. Trees bigger than castles also look a bit odd but I've basically given up on trying to make it all totally realistic. I'm not too concerned though anyway. Abstraction can be a good thing in games. Wait until you see my knights in shining armour. They look like decapitated horses. I also have a fish and a shark (on green backgrounds) but they may not make the final cut because it was the kids idea to include pets. I'm just playing with ideas.

I appreciate the feedback though. It's not like you can read my mind so from your point of view that's a perfectly reasonable suggestion and I'm not knocking it.

[cola5pandex]

I've added some more code (sort of a main loop) if anyone wants to tear it to shreds.

It basically just reads from the keyboard to allow movement but as it stands it just outputs characters for testing purposes. It currently responds to cursor keys (for movement) and Esc (so I can return to BASIC for debugging if needed). The main reason I'm posting is because I know there are other ways to do this. I'm just using OSBYTE 129 because that's what I'm most familiar with. But I am open to alternatives so I thought I'd put it out there for scrutiny and (hopefully) feedback. This isn't the complete thing. Just the new bit. If anyone wants it all then just ask.

Code: Select all

; Variables for drawMap
tilePointerL=$70 : tilePointerH=$71
tileOffsetL=$72 : tileOffsetH=$73
screenPointerL=$74 : screenPointerH=$75
tileCount=$76 : tileByteCount=$77
mapColCount=$78 : mapRowCount=$79

; OS subroutines
OSBYTE=$FFF4 : OSWORD=$FFF1 : OSWRCH=$FFEE

; SHEILA offsets
CRTC=0

ORG $3000
.start

; Select MODE4
LDA #22 : JSR OSWRCH : LDA #4 : JSR OSWRCH

; Disable cursor editing
LDX #1 : LDA #4 : JSR OSBYTE

; Write to SHEILA (internal hardware) using OSBYTE 151 (the clean way)
; because if Steve Furber catches me poking her then I'm a goner :D
; This is for a Stardot in-joke so what it does is a secret :D 
LDX #CRTC : LDY #10: LDA#151 : JSR OSBYTE
LDX #CRTC+1 : LDY #96 : LDA#151 : JSR OSBYTE

; Draw map
JSR drawMap

.keyboardLoop

; Read keyboard with (almost) zero delay using OSBYTE 129 (aka INKEY)
LDX #0 : LDY #0 : LDA #129 : JSR OSBYTE

; If nothing pressed then keep listening
CPY #255 : BEQ keyboardLoop

; If Escape pressed then GTFOH
CPY #27 : BEQ escape

; If left arrow pressed then branch accordingly
CPX #136 : BEQ keyLeft

; If right arrow pressed then branch accordingly
CPX #137 : BEQ keyRight

; If down arrow pressed then branch accordingly
CPX #138 : BEQ keyDown

; If up arrow pressed then branch accordingly
CPX #139 : BEQ keyUp

; If non of the above then keep listening
JMP keyboardLoop

.keyLeft

; PRINT"L"; (temp)
LDA #76 : JSR OSWRCH
JMP keyboardLoop

.keyRight

; PRINT"R"; (temp)
LDA #82 : JSR OSWRCH
JMP keyboardLoop

.keyDown

; PRINT"D"; (temp)
LDA #68 : JSR OSWRCH
JMP keyboardLoop

.keyUp

; PRINT"U"; (temp)
LDA #85 : JSR OSWRCH
JMP keyboardLoop

.escape

; Acknowledge Escape condition
LDA #126 : JSR OSBYTE

; Enable cursor editing
LDX #0 : LDA #4 : JSR OSBYTE

; Back to BASIC (or whatever)
RTS

.drawMap
...

And here's the ssd for anyone who wants to play...

hex.ssd

(1.5 KiB) Downloaded 4 times

See you in the morning.

[tricky]

Reading keys via the os can be slow for a 50 FPS game, but fine for a turn based game.

Some things are better all or nothing, so in my games I kick out the os, grab all the ram and hit the hardware directly.

This is ok for my games as they are all single load, but not great if you want to save or multi-load.

[cola5pandex]

Reading keys via the os can be slow for a 50 FPS game, but fine for a turn based game.

That's what I was thinking. It's just that OSBYTE 129 is not the only option even if I do stick to OS routines. But if you don't use any of them for your games then I guess you can't help with that one. No biggy. You have been a huge help anyway.

Some things are better all or nothing, so in my games I kick out the os, grab all the ram and hit the hardware directly.

I have a theory about borrowing from Peter to pay Paul. For example... How much RAM can I actually grab? How much RAM will it cost me to write routines that are already sitting in the ROM ready to do the job as long as I don't steal their workspace? How does that balance out? I don't really know so I'm playing it safe for now. That might change when things start to get tight though. That's when I might get ruthless. Does that make sense? Or am I playing it too safe?

I'm also behaving myself with things like Sheila because of our conversation about an enhanced version that might be able to exploit another CPU with another 64k of RAM (with its own independent address space). That's about paying Paul on time to keep my credit score up so that Peter will give me a mortgage. Maybe I've got that wrong too though. Perhaps it makes more sense to cross that bridge when I come to it.

This is ok for my games as they are all single load, but not great if you want to save or multi-load.

I have considered both save and multi-load. It is shaping up to be that kind of game. Horses for courses is what you basically seem to be saying and that sounds about right to me.

The other thing to consider... This is my first proper game for the Beeb (catch the pound sign doesn't count ). It's probably best if I don't bite off more than I can chew. I mean... Who's going to dig me out of that one? I'm already keeping you busy enough as it is.

Cheers again Tricky