Retrochallenge 2015/07 – Debugging the 6502 Machine Code

With time rapidly running out for this challenge I’m hoping to at least get a simple animation working on the Electron.  Once I had written my first simple test code I discovered that the “calcscrloc” code had a couple of bugs.

Below is the debugged Calculate Screen Location Routine:

.calcscrloc
NOP ; CALCULATE MEMORY LOCATION
NOP ; STORE IN &70,&71
NOP ; A 0/1 FOR EVEN/ODD
TYA ; READY TO PROCESS
LSR A ; DIVIDE BY 2
LSR A ; DIVIDE BY 2 (4)
LSR A ; DIVIDE BY 2 (8)
STA &70 ; USE AS TEMP STORE
ASL A ; MULT BY 2
ASL A ; MULT BY 2 (4)
CLC
ADC &70 ; ADD ORIG VALUE (X5)
CLC
ROR A ; SHIFT RIGHT BIT 0 IN C
STA &71
LDA #0
ROR A ; SHIFT C INTO BIT 7
STA &70
TYA ; ORIGINAL Y COORD
AND #7 ; BITS 0-2
ORA &70 ; ADD 0 TO 7
STA &70 ; STORE
LDA &71
CLC
ADC #&30 ; ADD SCREEN BASE
STA &71 ; STORE
TXA ; READY TO MULT BY 4
AND #&C0 ; TOP 2 BITS
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; BITS ARE NOW 0-1
CLC
ADC &71 ; ADD TO MS BYTE
STA &71
TXA ; READY TO CONT MULT BY 4
AND #&3E ; BITS 1-5
ASL A ; MULT BY 2
ASL A ; MULT BY 2 (4)
CLC
ADC &70 ; ADD TO LS BYTE
STA &70
LDA #0
ADC &71 ; ADD CARRY TO MS BYTE
STA &71
TXA ; NEED ODD / EVEN
AND #&01 ; WE JUST NEED BIT 0
RTS
.incscrrow
NOP ; INCREMENT SCREEN MEM ROW
PHA ; PRESERVE A
TXA ; TRANSFER TO PRESERVE
PHA ; PRESERVE X
TYA ; TRANSFER TO PRESERVE
PHA ; PRESERVE Y
INC &70
LDA &70
AND #&7 ; USE BITS 0-2
BEQ incscrrow_1
.incscrrow_2
PLA ; POP (Y)
TAY
PLA ; POP (X)
TAX
PLA ; POP A
RTS
.incscrrow_1
DEC &70 ; DECREMENT BACK
LDA &70
AND #&F8 ; MASK OUT BITS 0-2
CLC
ADC #&80 ; ADD THE LS OF &280
STA &70
LDA #0
ADC #&2 ; ADD THE MS OF &280
CLC
ADC &71 ; ADD EXISTING MS BYTE
STA &71
JMP incscrrow_2

So I now have the following BASIC code creating a very simple animation moving the ball down the screen:


OLDX%=-1
OLDY%=-1
FOR A%=0 TO 251 STEP 2
IF OLDX% <> -1 THEN X%=OLDX%:Y%=OLDY%:CALL removeball
X%=79
Y%=A%
Z=USR(displayball)
OLDX%=X%
OLDY%=Y%
NEXT

It is however very flickery and so I may need to see if doing the remove within the assembly is going to be faster than doing it in BASIC.

Retrochallenge 2015/07 – 6502 Assembly Slow Progress

It seems I have underestimated the time I needed to develop the 6502 Machine code routines that will allow me to start the game development.  The perils of “learning on the job” I suppose.

As all programming goes, and especially so with machine code, the art is breaking it all down to very small pieces and working on each piece individually.  With the limitations of the Acorn Electron’s line editor this is even more the case.

My aim is to write some machine code routines that allow me to easily draw the sprites onto the display as the built in BASIC just wont be fast enough.  The first bit of code I required was to convert a X and Y screen coordinate into the mode 2 memory location so I can easily ‘poke’ into the screen memory.

I thought this would be trivial but proved more challenging than I expected.

however I do now have the following code which appears to work though it will likely change especially how I return odd / even (currently in the A register).

.calcscrloc
NOP ; CALCULATE MEMORY LOCATION
NOP ; STORE IN &70,&71
NOP ; A 0/1 FOR EVEN/ODD
TYA ; READY TO PROCESS
LSR A ; DIVIDE BY 2
LSR A ; DIVIDE BY 2 (4)
LSR A ; DIVIDE BY 2 (8)
STA &70 ; USE AS TEMP STORE
ASL A ; MULT BY 2
ASL A ; MULT BY 2 (4)
CLC
ADC &70 ; ADD ORIG VALUE (X5)
CLC
ROR A ; SHIFT RIGHT BIT 0 IN C
STA &71
LDA #0
ROR A ; SHIFT C INTO BIT 7
STA &70
TYA ; ORIGINAL Y COORD
AND #7 ; BITS 0-2
ORA &70 ; ADD 0 TO 7
STA &70 ; STORE
LDA &71
ORA #&30 ; ADD SCREEN BASE
STA &71 ; STORE
TXA ; READY TO MULT BY 4
AND #&C0 ; TOP 2 BITS
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; MOVE RIGHT
LSR A ; BITS ARE NOW 0-1
CLC
ADC &71 ; ADD TO MS BYTE
STA &71
TXA ; READY TO CONT MULT BY 4
AND #&3E ; BITS 1-5
ASL A ; MULT BY 2
ASL A ; MULT BY 2 (4)
CLC
ADC &70 ; ADD TO LS BYTE
STA &70
TXA ; NEED ODD / EVEN
AND #&01 ; WE JUST NEED BIT 0
RTS

I still have lots of machine code routines to write, and it is looking like I am up against in regards to the Retrochallenge deadline of the end of the month!  However I am determined to keep pushing forward and at this stage I think I will be happy if I can just demonstrate basic sprite animation on the Electron.

Retrochallenge 2015/07 – Printing the Assembly Listing

I forgot how difficult it was to develop code on a line based editor.  Often the port of call here was to print out and use a pen or pencil to scribble, and note things.  It gives that bigger overview you sometimes need when developing.

As I didn’t have a printer I could connect up to the Electron, I decided to investigate how I could extract a listing directly from the 3.5″ floppy disk (a 3D save icon to our younger readers!).

One of the tenets I tend to live by is never throw anything away, especially in regards to electronics.  This has proved more than useful over the years with my Retro Computer collection and luckily would come to the rescue now.

I needed a PC with a built in floppy drive, running an old version of Windows (XP), and some old software I had collected over the years.

Software item one is OmniFlop.  There is a version of this that installs a driver to directly access the Floppy drive.  This is why the drive needs to be built in and not an external USB type.

Note: There may be newer versions of OmniFlop about, I’m not even sure where I got mine from as it was a long time ago, but I keep it because it works!

OmniFlop is very easy to use and in no time I had a .adf file with a dump of my disk.

Next stage was to extract the file(s) from the disk, I tried various software I had around for BBC / Electron disk dumps, but the one that worked for me was a command line program called BBCIM.

Using this utility I was able to extract the tokenised save file, however I needed to de-tokenise in order to print it.  I considered writing my own to extract the text (at least for the assembly code) after looking at a hexdump of the binary file.  However I stumbled upon a Python script that Matt Godbolt had already developed:

BBC BASIC V Format

The downside of this script was the line numbers are lost, however for the purposes of viewing the assembly code this didn’t matter to me.

pen and paper

Now I really need to get moving to get this code working, as we are nearly half way through the Retrochallenge!

Retrochallenge 2015/07 – Mode 2 slow progress

Thanks to @z0m8ied0g on Twitter for pointing me towards the Acorn Advanced User Guide, this explains how the screen memory is laid out for each mode on the Electron.

So my first programming objective was to put together some 6502 Assembly to display a simple sprite.  However this is taking longer than I hoped.  This is probably due to my lack of experience with the Acorn assembler and the fact I haven’t written any 6502 assembly for around 30 years!

As an example it took me a couple of days to realise that you cannot have multiple bytes on an EQUB statement like below:

EQUB 1,2,3,4

Though it didn’t give me an error, I wasn’t getting the graphics I was expecting which I eventually sorted by creating separate EQUB statements for each byte.

EQUB 1
EQUB 2
EQUB 3
EQUB 4

As I currently want to be able to draw the sprite at any pixel location, and not move at the convenient 8 x 8 character positions, I am currently having issues with coding this up in 6502 assembly due to the Mode 2 screen layout.  The issues are the interlaced pixel values, and also the way the memory locations map down in rows of 8 and then back up.

I need to spend some serious time thinking the logic through for this, and how I map it out without using too many memory locations, especially in the scarce Page 0 area.

 

Retrochallenge 2015/07 – Getting to Know the Electron

I have never written a game on a BBC Micro, and especially the Electron so I have no real knowledge of how to go about things.

So using the techniques I would have used on other systems I am trying to get to know how the Electron ticks.  I have managed to read the Paddles which are now fully wired up via 6502 assembly and so I thought I would attack some simple graphics.

On other systems when coding games it always seems to be best to ‘poke’ the screen memory directly, and that is what I am trying to do here.  Looking through the user guide if I want lots of colours then mode 2 seems the way to go (16 colours!).

Albeit I lose 20K of memory (which may be too much out of the 32K).

I found this page which seems to describe how the modes work, including memory layout.  So I thought I would develop some simple BASIC code just to prove that I can write directly to the display.

However Mode 2 is completely baffling me!

According to the above article the pixels are a simple 4 bit affair, so in my head that is just a hex digit per pixel, so to write a red pixel in the bottom write I should do:
?&7FFF=&01

and to write two next to each other I should do:
?&7FFF=&11

However this is not what I am observing.

The test code I am using is below:
10 MODE 2
20 FOR A=&7FFF to &3000 STEP -16
30 ?A=&11
40 NEXT
50 GOTO 50

So, this is putting me behind, I’m not even sure that Mode 2 is the best for the game.  I need to try some other information sources, plus trial and error to see if I can determine the best way to draw to the display.  Alternatively I may need to try another screen mode.

Retrochallenge 2015/07 – The Paddles

So what I naively thought was going to be a simple process of connecting up the Atari Paddles to the Acorn Electron’s joystick port via a cable adapter turned out to not be.

Though I suspected the Potentiometer’s may not be the same I was expecting to get a range of values that I could at least use (maybe via a calibration).

However it seems I wasn’t getting much range on the pot (only a small amount of it was giving me changing values, and also only a small amount of variation in the numbers).

I decided to ‘breakout’ the wires into a breadboard so I could experiment.

I thought I could overcome this by putting a resistor in parallel to bring the pot value down.  However, again this still only gave a small range of values being read by the Electron.

I then decided to open up the working joystick to see if I could get any clues from how it was wired up inside.  Immediately I noticed that all three wires of the Pot were wired up, not just the two I would expect.  This then reminded me that the Plus/1 pinout had an Analogue ground as well as the analogue reference voltage.

I decided to crack open one of my Atari Paddles and as I suspected this was wired up with just the two wires of the pot.

So it seems the Electron requires the voltage reference to be balanced between Ground and the 1.8V reference.

I so happen to have some old paddles from a long since passed Binatone pong style game.

I had already modded them years ago with a fire button, however they don’t currently have any cable.

The Pots are 10 kOhm as mentioned in the Plus/1 manual so they are a good match.

Once connected up with the 3 wires I managed to get values from 255 to 0.

So next step is to wire up the two paddles in a more permanent manner.

Retrochallenge 2015/07 – Starting out

So it is the 1st of July and the start of the Retrochallenge.

Initially my aim was to get everything gathered up and connected ready to go.

Apart from the Electron and it’s interfaces I needed a 15 pin Male D type connector and a 9 pin male to make up an adapter so I can connect my Atari Paddles to the Plus/1 interface.

While searching I found a BBC analogue joystick which has luckily allowed me to test reading from the Analogue port on day 1!

Once you plug all this in it becomes as big as a BBC Micro!

Once you plug all this in it becomes as big as a BBC Micro!

Retrochallenge 2015/07 – The Next Challenge – decision

So it’s decision time for the Retrochallenge.

Though I have been toying with doing a hardware challenge this time, as my initial idea involved the ZX Spectrum, which I used last time I thought I should really pick another system.

From several choices I have decided that this time I am going to use the Acorn Electron.

My intention is to develop a new game for the Electron using BASIC and maybe some in-line 6502 assembly.

Though I have programmed in BBC BASIC before I have yet to write anything ambitious such as a game so I have a lot to learn about how to do Graphics, Sound etc.!

I haven’t fully decided on what the game will be, but I want it to be paddle based, so I will first need to get some Atari or similar paddles connected up, and secondly I want it to be primarily a two player game.

Retrochallenge 2015/07 – The Next Challenge

I am taking part in the Retrochallenge 2015/7 however I need to decide what project / challenge to set myself.

My favourite retro system has to be the Sinclair machines, and though I favour the ZX Spectrum now, I cut my teeth on the ZX-81 and I am wondering if I should go right back to my roots?

Also I have several new additions to my collection, do I use the challenge to spend some time with them?

Just picking a system isn’t the end of it though, I then need to decide what I want to do, will it be software related? or hardware, or both?

To be continued… (I hope)

 

Retrochallenge 2015/01 – Finished

Publishing of the listing is now complete in both paper and electronic format.

If anyone wants a physical copy then we will be taken some printouts to the Retro Computer Video Game Market 2 in Leeds on February the 7th.

If you would like a copy reserved for collection at the above event then please tweet @oldcomputerclub and let me know.