Printing Numbers – Part 3

The third system for printing numbers is very similar to the second – where we stored each digit of the number separately.  This gave us complete control over how big the number could be, and removed some of the drawbacks of storing the number as an 8 or 16-bit value.

However… doesn’t it seem a little wasteful to store a single digit – 0 to 9 – using a whole byte?  And doesn’t it also seem a little strange there there appears to be no support for doing this kind of thing in Z80 itself?  Surely it’s not such a ‘custom’ concept?

Well, welcome to Binary Coded Decimal!

Continue reading

Printing numbers – Part 2

So we’ve covered the method required for printing the value from an 8 or 16-bit register, but have found two drawbacks with it – the size of the number we can print, and the time it takes to print it (as it has to keep looping for each value in each numeric ‘column’)  I also hinted that there are at least two other methods you can use for doing this tasks, and both rely on using a more ‘direct’ method for storing the number – just store the digits themselves instead of using binary as the registers do.

Continue reading

Printing numbers – Part 1

Something which is very simple in BASIC is to print a number:

10 LET A = 42
20 PRINT A

Easy as that.  This isn’t quite so simple in machine code however, as you need to work out, and print, each ‘column’ of the number – the units, the tens, the hundreds, and so on.

There are a number of different ways to do this – I can think of 3 which work well – with each having it’s own pros and cons, so will start with the most simple – printing a number from a register.

Continue reading

Rear Gunner XL – Part 6 – SLOW DOWN!!!!

So, have you played it yet?  Yep, it’s complete impossible to control, and there are bugs!  I’m going to cover all the ones I’ve found now, but not initially give you any code to fix them – try to fix them yourself first…

It’s a bit quick eh?!  This is a very graphic demonstration of the difference between BASIC and machine code.  In BASIC if you press a key to move the player it does so after roughly half a second or so?  In machine code, you can move multiple places in that same space of time – so much so that your first attempt at moving is likely to fling the sights completely off the edge of the screen!

Continue reading

Rear Gunner XL – Part 4 – Movement

So far we’ve setup the variables we need, and drawn our sights and the enemy into the screen.  We still can’t really play the game though, as we need to have some way of moving around,  This is handled in lines 90 to 140:

; 90 IF INKEY$=“5” THEN LET B=B-1
; 100 IF INKEY$=“8” THEN LET B=B+1
; 110 IF INKEY$=“7” THEN LET A=A-1
; 120 IF INKEY$=“6” THEN LET A=A+1
; 130 IF INKEY$=“0” THEN GOTO 150
; 140 GOTO 50

Continue reading

Rear Gunner XL – Part 3 – Drawing

Having converted the first five lines of the game in the last post, which setup the positions of the player and enemy, we can move onto the next four lines, which are concerned with drawing both the player’s sights and enemy:

; 50 PRINT AT D,C;”(graphic G)”
; 60 PRINT AT A,B;” + “
; 70 PRINT AT A-1,B;”   “
; 80 PRINT AT A+1,B;”   “

Line 50 is drawing the enemy sights, and 60-80 the player.  It’s interesting to note that the player is drawn in the middle of a 3×3 square, surrounded by spaces, so when the player moves it erases the previous position as it goes.

Continue reading

Rear Gunner XL – Part 2 – Setting up

I think the best way to do this conversion is type in the BASIC listing as comments, and then add our Z80 conversion of each line as we go.  This will all be stored in our main.z80 file.  That way it will be obvious what code each line translates to, and hopefully be easier to follow.

Note that this isn’t going to be the most optimal or efficient solution to converting the game, as optimising everything often leaves the code being somewhat unreadable.  I’ll offer some thoughts on how it can be improved, but I’ll leave that up to the reader 🙂

Continue reading

Rear Gunner XL – Part 1 – Getting started

The development environment for doing ZX81 games is the same as for the Spectrum, just that you need a ZX81 emulator to see the results on.  You can still use whatever text-editor/project solution you are used to, and the same assembler – it’s just Z80 again after all.  For the emulator I’d recommend using either EightyOne – which is very accurate – or No$ZX81 – which is much faster to boot, but not quite as exact.  I personally use No$ZX81 for day-to-day development & testing, given it’s quick turnaround, and EightyOne for final testing.

Continue reading

Going back in time…

I’ve been ask by a few people to write about my experiences with programming the ZX81, and with the grounding of using Z80 on the ZX Spectrum now largely covered it would seem the right time to step back a little in time to the Speccy’s predecessor…

With the Zeddy being based upon the ’81 most of the concepts are actually very similar, if not identical, between the two machines.  Obviously, out of the box, it lacks sounds and colour (so that’s two less things to worry about straight off) but the main differences are really only how the display works, it’s relative lack of memory, and that it’s slower than it’s big brother.  But if, like me, you stick to using the low-res ‘chunky pixel’ graphics that it’s known for then you actually need much less memory to store graphics, and because the screen takes less memory you can fill it faster, so it’s very much swings and roundabouts.

Continue reading