DMA Design - Now part of history.... apparently.

So a couple of years back the old museum in Dundee closed to get a well needed refurbishment, and while shut it got in touch with Realtime Worlds and asked for everything DMA that would could get our hands on. Now the museum is open again and it has a section based on local history, and a selection of the DMA stuff has been put on display. It's very odd seeing something that I've been intimately involved with appear in a museum! Particularly as (last time I checked), I'm not dead yet! But it's very cool to see DMA Design given the same kind of importance as Timex (who made the ZX Spectrum, right here in Dundee) and D.C. Thomson who...well.. own half of Dundee. There's also lots of stuff dealing with life sciences and the like, and to think that we've managed to influence Dundee's past enough to warrent a little display is very satisfying, not to mention a little cool.
The newly opened museum is pretty good, so if your in the area, you should pop in and see it

Update....

So, it's been sometime since I've posted anything and a lot has changed - well, for me at least. I've left Realtime Worlds after some long term disagreements with how the project I was on was being handled, but I wish them all the best and hope they make a go of it. All I can say about the project is that IF they manage to pull it off, then it's gonna be huge! Good luck to all involved, I spent 5 years of my life on it, so I'm still very keen to see it work.

Still onwards and upwards I guess. I'm currently on gardening leave from RTW and have just over a week left before my official end date. It's nice to be able to kick back and relax a bit, although I have been finishing off some freelance stuff I've been doing on the side. I hope this will be announced soon so I can start blogging a little more about it, because it's really interesting in its own right. With luck, I'll have things sorted out in a couple of weeks and everything will become clear.

Because of all this, my retro projects have obviously taken a back seat, and will remain so for some time to come; and the same goes for my electronics. I'd love to get back into them but I have bills to pay like everyone else so I have to concentrate on other things. I'd love to dabble back with my electronics in particular, but it's going to be a while before I can afford to do that again.

Anyways... I hope to announce some stuff in a couple of weeks, and with any luck, you'll all be interested in that as well!


Oh! And you can follow me on Twitter if you REALLY have no life and nothing else to do... I'm on there as MDF200 (which was my old Visual Sciences login ID!

The cool wall

Computers and Consoles
Seriously Uncool	Uncool	Cool	Sub-Zero
IBM PC Tatung Einstine Amiga CDTV New Brain Commodore16 Spectrum+ Vic 20 Oric / Atmos Philips CDi Konix 3DO TI99/4A IBM 360 C64gs TRS80 BBC Micro Amstrad GX4000 Amstrad PCW Sinclair Zx80 Altair 8800 Nintendo Virtual Boy Dragon 32/64 Philips Videopac Elan Enterprise PC 200 Sun Ultra Sun Sparc Mattell Aquarius Cambridge Z88	FM Towns Plus/4 Commodore 116 Atari 400/800/1200xl/130XE/65XE Amiga CD32 Amiga 2000 Amiga 4000 Atari 2800 Atari ST Spectrum 16k/+2/128 Commodore 128 / 128D SAM Coupé Commodore Pet Atari Jaguar Sega Saturn Nintendo Game Cube Atari Lynx Sinclair ZX81 Nuon Acorn Electron Acorn Atom Amstrad CPC MSX Archimedes XBox Sinclair QL Playstation 3 Gameboy Advance PDP 8 Dec Vax PSP NeoGeo Pocket Commodore 64sx Vectrex Nintendo Nes Sega Master System	Atari 2600 Amiga 1000 Amiga 3000 Amstrad 6128 Plus Cray PC Engine Megadrive NeXT NeoGeo Mac Thinking Machine Nintendo DS Playstation XBox360 Dreamcast SGI Workstations N64	Magnavox Odyssey Pong Sinclair Spectrum 48k/+3 Commodore 64 Apple II+ Colecovision SNES Playstation2 Amiga 500 Amiga 1200 Gameboy Wii

A little while back the members of our team during a week of coffee breaks came up with the following cool wall. It was a hard fought list with many arguments about the virtue of each machine, but in the end we had our definitive list of old machines. Fans of TopGear will know all about the cool wall, and know it's nothing to do with how good anything is - just that it's cool or not. So heres our list... let battle commence!

Now remember... it's how COOL they were, not how useful, or powerful. The Plus/4 is a great little machine, but I'm not gonna pretend its cool. Also machines like the Amiga 4000 were awesome! But too expensive to be cool. So there you go - thats the rules.

Life changing magazines #4

So this one is a little simpler. It's my first published work. I was 16 when I sent it off, so in the 2 years from reading the WORMS program listing, I had learnt basic Z80, gotten a spectrum, written a Database for my Mums work, was without a computer for a almost a year(spectrum went back to my mums work), and then gotten a Plus4 and learnt 6502. I find this frightning as these days, YEARS seem to slip by without anything appearingto happen!

So here is the letter I wrote, the reply I got, and the final article. I was well miffed that they didn't put my name on it however - everyone else got that! Story of my life that.... everyone's always taking credit for my work in some shape or form....

From now on, they're not that "life changing"... just important, or funny. There was one other one, but I appear to have lost that. It was a turbo loader for the Commodore Plus/4 which I used a lot, but I then adapted it to be an interrupt driven one on the C64, which then allowed me to play a game while things were loading. Aside from this one, the rest were all after I "turned pro", and so weren't important, just funny/cool/etc.

Life changing magazines #1

I guess every programmer has a genesis moment. One where everything starts to make sense and it's the true begining of their love of programming. This was mine. I was 14 and must have had my ZX81 for about 6 months or so when I bought this magazine. I was at my grans in reading this and suddenly all those HEX numbers I'd been typing in made sense. There in front of me was a true assembler listing. I suddenly realised what all the codes at the back of the manual meant, and how you used them. I poured over this article for days, playing with it, trying new values, changing little bits to see what would happen. Up until now I'd been doing ZX81 BASIC and was getting on okay. However when I got this article I saw the routine that drew the border and called it directly.

BANG!

Unlike Basic, it popped up instantly. I was gob-smacked! It was SO quick. Basic would have taken over second to print that much! I played around with it, changing the character it drew and so on.

This showed me just what computers were capable of, and how these games I bought actually managed to do what they did. Now I could see how it all worked, I started to learn it all...

Put it simply... this is what got me hooked.

Life changing magazines #3

So, I got this I think around 1985, second hand again. This was very cool though, it showed how to make your own turbo loader! Now I still didn't really understand it at this point, but I was able (with the aid of an amazing tape deck) to make a screen grab load at an amazing 6,000 baud! This is microdrive speed; from a NORMAL tapedeck! It just blasted in! I was also able to load data in via a slightly odd pattern so the screen would come in backwards, and even from both directions at once! Normal spectrum turbos were 3,000Baud (with the original ROM routine at 1,500), so I had great fun fiddling with these routines.

I've still to track down the No.1 magazine. I do still have it, but I've no idea where!

Life changing magazines #2

Yes I know... I'm starting at #2, I need to track down the No.1 magazine. So this one was published when I was just 13, and it had the key equations for doing very basic 3D and perspective. I used these equations for years before real full matrices were possible, but it still holds a special place in my heart. And yes... theres a chunk missing from it. I got it 2nd hand, and someone had sent off for something ripping a big bit out of the article. Fortunately, it wasn't important as I didn't really care about the program, just the method and equations.

ZZap64!

I've just received my original Oli Frey ZZap64 artwork! And I'm pleased as punch! It's from issue 9 of ZZap64 and it's a beauty! It's actually draw at the original size (or very close) to that of the magazine, which I'm astounded at! Normally artists will draw x2 or larger so they can get the detail in, but he hasn't! How the hell did he do that! The detail is amazing on it. I've also discovered I have that magazine, so I'll now get them framed together and it'll take pride of place in my workroom.

I can't wait to see what other ones he'll put up for sale, who would have thought all those years ago I could own an original! Very cool....

You can go buy your very own original at the ZZap superstore: CLICK HERE!

(must now stop using exclamation marks to end every sentence...!)

KISS - Keep it simple, stupid.

I'm a big fan of simple code, probably because anything more complex confuses me and I'll never understand it. This is a hard lesson which I learnt when I was about 15 or 16. I had written a very clever platform routine in assembly on the spectrum. It would draw a Manic Miner level using likes and some king of direction control. However, it was so clever, that after I had written it, debugged it and it was fully working - I had NO idea how it worked. Not a clue. Now, I'll cut myself a little slack here... I was only 15 or so, and had hadn't been doing assembler that long really. Still, I had written it, so I should have understood it! Since then, I've followed the KISS philosophy. Keep it Simple, Stupid. Although the original was apparently Keep it simple and stupid, I prefer the newer interpretation, as you really don't have to be clever to be an engineer these days (particularly a software engineer), and we love to complicate things; so I prefer the insult. If you haven't kept it simple, then you're stupid.

I see this everyday at work, coders who think the latest shiny blog posting about some cool new method is the absolute BEST way to code, and anyone that doesn't is mad! MAD I TELL YA! Well, thats obviously rubbish. If you follow every posting by some new publicity hound, then you're codes going to be terrible, plain and simple. The only real rules for coding is that its got to be clean, readable, fast (enough), maintainable and extendable.

Outside of these simple guidelines, nothing else matters, and it's simple a personal choice. You can throw other things into this mix, like testable, abstracted etc. but these can cloud the code to the extent that its none of the things it should be. I've see code thats been abstracted so much, it's beither readable, fast, maintainable OR extendable. A little abstraction is a good thing, but only when you need it. If you're writing a bit of code for windows, and it's never gonna be moved onto any other platform, then why abstract windows calls? If your going to add value to them (but having them do more, or make the API easier), then thats fine. But never add layers for the sake of them. You should never end up with an API that just passes things through directly unless theres a damn good reason (moving platform it a good reason, as you're wanting to hide the underlying OS calls).

However, desire for coders (especially a novice/junior) to complicate things is pretty high, as is the desire to make a perfect API. Take it from me, thats an impossible dream. You might think it's great, but others will always want something different. The idea is to make an API as good as you can right now, and adapt as time goes on. In the world of professional development, it's all about getting products out the door, not going back over API's trying to make them absolutely perfect. They have to perform the job, and do so with an API that was as good as you could make at the time, otherwise, you'll simply never finish and go bust.

In the end, there's 2 types of coders.... Those that want to get things done and out the door (and this doesn't automatically mean bad code!), and those that want to polish things and write docs, and make things pretty, but ultimately cost you dearly.

Oh...and if you've never seen the second kind, then your one of them!

Designing a good API

So I've been doing some work porting some code to another platform (which I'll speak about later), and it's showing a severe lack of API design. Now I design APIs for a living I thought I'd quickly go over what I think makes a good API, not just from a users point ov view, but internally as well.

Simple and Fast. And we're done. Thanks for reading.

Okay... I'll go into a litte more detail. Now, API's are usually there to give a coder simple access to a more complex system. Take DirectX. The underlying hardware and systems are pretty complex these days, what with interrups, DMA chains dynamic memory management and all the rest of it, yet the API is (reasonably) simple. So... here goes.

Simple. An API must be simple, in fact as simple as you can get away with. This isn't to say you should make it basic, no. You should make it do everything a coder will normally have to do, but don't over complicate it by using 1,000,000 calls for each function. Take DirectX texture creation... Now, whenever I do a graphics engine I have a single CreateTexture() function where as DirectX has several. Textures, Surfaces, DepthBuffers and Cube Maps, the list goes on. Now why? Theres really no reason for that kind of split. You could just as easily use flags and paramaters to allow the various types of selection. This means the coder only has a single function to learn, and if you follow this kind of rule for the whole API, then the entire system becomes much smaller. After all, would you rather a 1,000 call API where you have to set the width and height of a texture indavidually, or 10 functions that can do everything! The smaller the API, the more control you can keep over it. If you give access to every single function and variable, then it becomes a nightmare to change or upgrade.

So, keep an API simple. It's less to maintain, and the programmers that use it will thank you for it.

Speed. This is obvious. It has to be fast. If your management code gets in the way, then the API will become too expensive for coders to use properly, and they'll end up writing support functions themselves. This is really bad. You want the programer to have confidence in the API, not only that it'll do what you say it'll do, but that it won't slow him down. Streamline as much as possible, remove as many if's and but's as you can inside performance critical areas.

Now, a quick word about abstraction. It's important to abstract certain types of API so that it's clean and portable. Now theres a few of reasons for that. First you expect the API to change under you. If your using some open source interface, you never know when the latest buzz word is gonna take hold and your whole API is gonna change, so a simple layer of abstraction will protect you. Next, it will allow you to add value to an underlying API. Take DirectX texture management, if you add a simple layer to your API, you could then now keep track of all your textures, and it'll allow your to manage things like device resets (when you resize the window etc.) as since you own all the texture pointers you can free/reallocate things like render targets automatically. Lastly... Portability. Now most hobby projects don't care about this, but you never know when your project might take off and someone else might want to port it for you to a Mac, or a ZX81...or something.

The program I'm currently working on was hard coded for windows, using not only MFC, but DirectX calls and enums directly. So, being someone that designs APIs, I know all about abstraction. Being someone who's worked on lots of multi-platform games, I know all about how to make an API platform independent. So, thats what I'm doing. All calls to DirectX and being put through a layer of abstraction, each ENUM is being changed to be platform agnostic. This means the API can translate (very quickly) to whatever rendering API I want, without the main application knowing, or caring. The classic case is DirectX and OpenGL. Doing this would allow this program to run on the Mac, without the main program changing. I'd only have to port the (now pretty small) API, and not the whole program.

If you've done your job correctly, you'll have to port a handful of API's. Sound, Graphics, Networking and simples file systems and memory management. All games can be based on these simple API's, and then be made to run on other platforms (reasonably) easily.

Theres obviously lots of ideas for each API. Designing graphics APIs is an art in itself. I've used the same API for the last 10 years. The underlying graphics systems have been PS2, XBox 1, DirectX 8&9 and I know it would work just as well on a PS1, XBox360 (never seen a Ps3 SDK), and DX10/11. A well designed API will work on any platform and be a pleasure to use.

So there you go... Keep an API simple - don't get sucked into the latest fad. Keep if as fast as you possibly can. And abstract to reasonably protect yourself from underlying systems and to allow simple porting.