Lunchtime Atic Atac

Snap taken using “Retrotechys Speccy Graphics Viewer/Editor”

After a few boring lunchtimes at work with nothing to do, I started tinkering around with a ZX Spectrum .sna file of Atic Atac, the aim being to be able to read some sensible data from the file and display some atic atac screens, using Blitz3D.


Prep Work:

  • firstly I obtained a 48kB .sna file of Atic Atac. I figured that as I have paid for the game twice in my life (ZX Spectrum and Xbox One Rare Replay), I was entitled to peep at the code.
  • I downloaded a decent free Hex Editor.
  • I had a good look at Icemarks Atic Atac data format page, as this gives a lot of guidance on specific areas of the data that pertain to drawing the screen.
  • I added 16kB of padding onto the front of the .sna file so that Icemarks memory offsets matched the file that I had.


Dev Program 1 – Find enough data to draw the outline of each type of room.

Atic Atac has 13 different room types, including the last room when you escape the haunted house, and the room when you are falling down a trap door.

The actual X and Y points for drawing each room are stored in two sections for each type room. The first part lists each X and Y co-ordinate for every line required to draw the room and the second part is a list of points so that these X and Y co-ordinates can be connected using lines to draw the room.


The First part of data looks like –  186,42,186,186,42,186,42,42. It is read as Point 1 X co-ord = 186, Point 1 Y co-ord = 42, Point 2 X co-ord =186, Point 2 Y co-ord=186 and so on.

The second part of the data looks like – 1,2,255,3,2,4,255,255. This i read as “Go to the X and Y co-ords of point 1 and draw a line to the X and Y co-ords of point 2. Then 255 means end of that draw function. Next go to the X and Y co-ords of Point 3 and draw a line to the X and Y co-ords of point 2, then go back to the X and Y co-ords of point 3 and draw a line to the X and Y co-ords of point 4.” Then two 255’s in a row means end of drawing that room.

Dev Prog 1 Input:

Type in which type of room you want to draw (0 to 12) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 1 Output:

Room Type 2, Scale Factor 4

Room Type 1, Scale Factor 3

It all looks pretty good with the exception of room type 7 which has an X co-ordinate error on one of the draw points. After some looking it turns out that room type 7, a sideways stairway, isn’t used in the game so the error wouldn’t ever have shown up.


Dev Program 2 – Draw the outline of each game room with room attributes.

Rather than just calling up a type of room, I wanted to be able to call up a room number from the game itself and have it display the correct type of room in the correct colour.

The Atic Atac .sna has a table in it with each room listed as room colour and type, so the data looks like 66,3,68,0,64,5 and is read as:

  • Room 0, Colour 66, Room Type 3
  • Room 1, Colour 68, Room Type 0
  • Room 2, Colour 64, Room Type 5

The room numbered order itself is a bit haphazard to say the least. Room 0 is the start screen, Room 1 is the screen above, Room 2 is screen left of that… and so on through the various rooms/floors.

Dev Prog 2 Input:

Type in which room from the game you want to draw (0 to 148) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 2 Output:

Game room 33, Scale Factor 4

Game room 69, Scale Factor 4


Dev Program 3 – Add Room objects to the each room rendered.

The game has an object table. This lists all of the objects in the game along with varous object attributes including the type of object the room number its in, the X and Y position it should be drawn in the room and its orientation.

This object table doesn’t seem to be in any specific order so if you walk into room two, you have to scan the entire table to list what objects are in room 2.

Once you have confirmed that the object belongs in the room that you’re in and you have  the object type, you can then jump to the offset of that specific object which contains the X width of the object in bytes, the Y height of the object in pixel rows and then the bitmap of the object itself, and start to draw it in the correct X, Y and orientation.

Dev Prog 3 Input:

Type in which room from the game you want to draw (0 to 148) and what scale factor you want to use (1 to 4, 1 being original size)

Dev Prog 3 Output:

Game Room 0, Scale Factor 4

Game Room 3, Scale Factor 4

Game Room 6, Scale Factor 4

So with all of this dev work done… “WHAT IS IT GOOD FOR… ABSOLUTELY NOTHING!!” but fun nerdiness all the same.



BBC Micro Screen Viewer

I’ve Finally got my BBC Micro screen viewer working…mostly…ish. Whilst it’s not really massively useful to anyone, it was a brain exercise for me to understand how the Acorn Beeb got the 1s and 0s from the memory to the screen and made an interesting lunchtime project.


I started with a Beebem .uef snapshot/memory dump of BBC Micro game and then I read lots of webpages about where the screen info is stored in the Beebs memory.


Next I knocked up a simple proof of concept black and white bit viewer where you could manipulate the column width and row height of all of the 1’s and 0’s in the Beebs 32kb memory dump with the .uef header still attached.
I stepped through the memory until I found an area with something that looked like a black and white distorted version of the screen of the game that I’d taken the snapshot of.


I then did a lot of reading up on the Beebs memory map and on the different screen modes the Beeb had.
After finding out that the screen mode that the Beeb is running the game in is stored in the memory and which memory location it was, I made several different snaps of beebem in the same screen modes.
I wrote a program to step through each byte and list all of the locations that contained the same number as the screen mode the snapshot was in. Comparing this with the other snaps in the same mode, I was able to narrow the screen mode location down to one byte. As I knew where this byte was in the Beebs memory, I was able to then trim off the UEF header and leave just the 32kb of Beeb memory.


Whilst doing my research, I saw that the Beebs memory contained a lot of data in various locations about the screen properties and reading these properties from the snapshot, I was able to get a screen that looks spot on using a lot of different game snapshots.



There are still some issues with this program though.

1. It wont do multi mode displays.
2. Despite the screen start location being clear in the memory, the actual screen doesn’t always start here and sometimes some manual bit/byte stepping is required to get the screen correct.

Some very clever programmers of the day used some neat tricks to make a decent looking display fit into a smaller amount of memory so that the saved memory could be used for more game code and learning these tricks is taking a while….
e.g. the atic atac title screen displayed above uses double width pixels, so that you get a full screen full colour display but only use half the memory normally required. It was easy to spot this as normally a character is 8×8 pixels, 64 in total. You can calculate this from Beeb memory locations using “bytes per character” x “pixels per byte(+1)”. If the pixels are normal this will come out at 64. In the case above, it comes out as 32 and means that the pixels are stretched.
Ultimate used the stretched pixel method in several of their title screens however sometimes its easy to spot with the method above, other times a different method has been used to stretch them, one that’s not so obvious…

Anyway, good nerdy fun all the same and an interesting lil lunchtime coding project. Thats BBC Micro and ZX Spectrum memory to screen decodes done. Next…. Might take a stab at the Commodore 64…..

Castle Quest – Micropower – BBC Micro – Remake in Blitz3D

After a while of inactivity, I’ve been tinkering with a 2D in 3D remake of Castle Quest using the now free Blitz3D. It all started when I was playing around with Blitz 3D’s different lighting effects. A flaming wall torch and a brick wall was all it took.


This has been going on for a bit to be honest, but Blitz 3D’s abysmal 3d object collision detection routines really put a stall on it, in that they either work badly or not at all. I even used the full tutorial example program to try and understand my errors, only to find out that that didn’t appear to work properly either. Anyway after some frustration I built my own collision routines and they actually seem to work so can crack on with the game. At this stage have an old vs new screenshot. Will post more if the project continues…





Two items for Silicon Heaven….

Well the Sharp Pocket PC has turned out to be a duffer after all. The microprocessor in there has had it…

And after several weeks of toying with Omnibot 2000, I’ve declared him scrap also.

Despite all of the individual parts tested and working, the remote seeming to work, the tray working, all moving parts working…pop it all together and try and run the robot and it just doesn’t happen.

I guess there is some issues with the main board, and at this point I’m not prepared to start stripping and testing components to try and figure out whats up.

I may do an EZRobot number on him instead and fit him out with some up to date innards instead..

RIP Omni 2000 and Sharp Pocket PC

For now… I hate throwing old tech away, even if it is a bit buggered! I guess its up to the loft.

Time to bring in a new candidate for testing / overhauling…

Robie Sr


A nice geeky retro tech find….. A Sharp PC-1360

Found in the “Box of Crap” in the corner of stores at work this afternoon….


A Sharp PC-1360. An old 80’s pocket computer, and a serial port interface stuck on the side of it.


Have thrown some battery’s in and it works, although at some point it appears that someone spilt a pint of glue over it, so will need a strip and clean before going into use.



Retrotechy Speccy Graphics Viewer / Editor

I’ve been tinkering with this ZX Spectrum graphics viewer/editor for a while now so I thought it was time to put it up for download. You can find it here.


The last thing that has been added is the TV screen view mode.
Basically you would normally rip graphics by arranging the bits in the file into rows of 8 bits / 16 / 24 / 32 etc. until you find the right width column to display the stored graphics as in the picture below:



You can see that the rows have been adjusted to 24 bits wide and the graphics become evident hidden within the file. When the programmer wants to use the graphics they are written into the display area of the memory in a certain way and they come up on your TV screen.


However the display part of the memory writes the graphics onto the screen in a unique way. If you consider a ZX spectrum with attached TV screen with the top row of pixels displayed being row 0, it will stream the bits linearly from the display area however it will draw on screen row 0, row 8,16,24,32,40,48 and 56. It will then jump back to row 1,9,17,25 etc etc. Once its done 8 rows of 8 pixels depth it then starts on the middle of the screen in the same fashion and then the lower part.


So thats just a monochrome screen of pixels on a background. It then reads the colour info from the attributes part of the speccies memory which follows straight after the display area.


Starting from the top left of the screen, each 8pixel by 8pixel block has a byte of attribute info associated with it that is only relevant for that 8×8 square. This byte of attributes contains Paper colour (background colour), Ink Colour (Pixel Colour), a bright bit and a flasher bit, both of which are either off (0) or on(1).


The speccy actually has a 15 colour pallette, not 8 as I thought. It has black, white, Yellow, Blue, Green, Red, Cyan and Magenta however it can also display all but one of these colours in two different levels of brightness, the exception of course being black. Total of 15 colours.


Each 8×8 square has a single foreground colour, a single background colour and both colours must be either from the bright pallette or the less bright pallette, not one from each.


The flasher bit… is a waste in my opinion. If its set to one then the ink and paper colours in that 8×8 square will swap themselves every half second or so. Personally I think having a bright bit for both the paper and the ink would have been a better use for it.
Using this method you can store a whole screen of coloured graphics in a small amount of memory, leaving more memory for better games. On the other hand you can see where the colour clash (Also named attribute clash for the now obvious reason) that the Speccy was infamous for came from.


Anyway you can now switch the display from bit mode to TV mode:



To be fair, the TV screen mode is probably only really useful to look at title screens Looking at the rest of the Speccy file is likely to show you colourful blocky garbage!

Shit Tinted Glasses?? BBC Micro – Beebem Playing Fire Track


Ok, I’ve heard of “Rose Tinted Glasses” a lot in the retro gaming world. Getting a chance to play an old game from your past on an emulator only to find that it was a pile of crap!! It leaves you wondering why yourself and everyone else went totally banzai over it!!

Well time for the old switcheroo….reverse rose tint! I had a quick play of “Fire Track” on BeebEm the other day and was amazed to find that it was a smooth acomplished lil shoot-em-up. From what I remember of playing it “In The Day” on my Beeb B it was gregariously couloured, jerky and generally left you with a headache and some travel sickness!!

Playing it on emulation was a pleasure, and I kept going back for another go! Most shmups on the Beeb were hideous affairs (Some exceptions!) but this lil fella kept me hooked…In fact i want another go right now!!

Kudos to BBC Micro B Fire Track. A kuul Shmup still worthy of todays attention!!!!!

Why is diagonal movement faster than straight movement in old arcade games / 8 bit computer games

I am talking bout real old skool games here, like early 80’s arcade stuff and old 8 bit computer games, but on a lot of them if you had a guy on the screen and you ran straight up, down, left or right you’d move slower than if you moved diagonally.

The issue sounds pretty odd but it’s easily answered and can be proved using Pythagoras Theorem.

If you push the left button, your guy on the screen moves 1 pixel to the left say, and if you push the up button your guy moves 1 pixel up the screen. Pretty straight forward yes.

Now if you push left and up at the same time then your guy moves up-left diagonally. This means he’s moved one pixel left and one pixel up in one move. The actual diagonal distance he’s travelled isn’t 1 pixel though, it’s actually just over 1.4 pixels, just like if you had a right angled triangle and the two shorter sides were 1 metre each then the hypotenuse would be just over 1.4 metres.

This means distance wise that every three straight the guy has travelled 3 pixels, but every three diagonal movements the guy has travelled over 4 pixels, hence why running diagonally gives you an advantage in old computer and arcade games, although usually the enemies had the same diagonal advantage too.

How to fix it? Well when you move diagonally, instead of shifting the guy one to the left and one up, shift him 0.7 to the left and 0.7 up and this will make the hypotenuse about 1. Of course ths screen itself can only display in whole pixels and will round up but as long as you don’t round up the actual x and y co-ordinates of the guy then he’ll skip a move every so often which slows him down to normal pace.

So why wasn’t this built into old arcade and computer games….Well there are three possible reasons:

1. It just wasn’t noticed to start with. (Unlikely)
2. It was noticed but people couldn’t be arsed to add the extra code to make it right.
3. Due to limited memory, there wasn’t enough space to add the additional code so programers just lived with it.