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.

New video...

I've uploaded a small video showing the current state of the C64 version. I suddenly realised I'd been sitting on it for ages and no one had really seen it.

You'll notice its not quite right, as background stuff isn't animating, and bullets aren't quite right. Still, it looks pretty, and the multiplexor holds up pretty well too!

RetroEdit cleanup

For the lack of any better ideas, I've been cleaning up retro edit into a more consistant state and I've now got the control editing the data in a native format. This means theres no real conversion required when lifting the data out an saving it off - or indeed loading data into it.

I still need to go through the application itself as I've changed my mind on several things. For example while its perfectly valid to allow you to edit HiRes and MultiColour more sprites together I'm not going to allow it. This means you dont have to run through a hundred sprites and switch them all to Hires or MCM, and in reality this would hardly ever happen anyway.

I can now draw a sprite okay so what I really need to do is add colour palette selection to let me pick which colour I want to paint with. Once I've done that I can add the features that make editing fun.

I'll need to extend the editing control to allow for character and bitmap mode because I want to use the same control to do all editing. That said, I'm still not sure what I'll be spending my time on over the Christmas break, but for now I'll carry on with this...

RetroEdit

I was looking through the source of retro edit and wondering what I'd do to change it, and came to the conclusion that actually, its not as bad as I thought. The only major change I want to do is how the data is stored internally. You see when I started this I decided to store the data in a basic INT[] array, where each 0 or 1 was actually a BIT, and I would then process the data for editing and drawing. However, this is a bit yucky, and I now think it would be better to just store the data in a more native format. Thats not to say I'll store it in boxes, or colums etc. but as a simple X by Y row of bytes. This makes plug-ins to save the data in a custom format easy.

So I think I might have a little play and see if I can reorginise things so they are more to my liking, and this will (I hope) then allow me to use the custom control to actually do real graphics work.

The way I've gone about this is to have a custom control that deals with retro graphics. So you load it up with the data (in a simple rowxcolum format, and you can then select colours and plot pixels. The idea is that once its released (if ever!) then you could use the control yourself outside of retro edit to do other things. I have no idea if this would ever happen, but it might.

So I've decided to give it a few days and see how I get on. If I feel like Im getting somewhere, I'll carry on - if not, I'll bin it.

Change of direction.

So with Christmas comming up it's almost time for my anual direction change. I was hoping that my ATmega devkit would arrive in time, but its looking less likely as time goes on - pooh. Oh well. I've pretty much completed what I wanted to do with Minus4j, although I'd like an option to pick a file fom the ZIP to switch to or load, but until Plus4world allows real access to ZIP files, this isn't that important. I'll probably wrap up what I've got into another release and leave it there for now, although I've yet to look at the sid filters but that may also be defered until later.

As to what project I'll do at Christmas time, well I'm not sure. I'd love to get back into electronics a little, but theres also my debugger and getting it running on a C64 and emulator. I'm also starting to think I need to restart RetroEdit. When I started it I hadn't done much C#, and over the years I've learnt how to do things properly. This means I could make a real stab at a proper system but as i've seen with the debugger, this means some serious effort. That said, I'd love a very simple interface so that I could draw tiles/graphics for myself.

I also really need to get a basic MAP editor togther even if its a very simple interface so that we can make levels for Xeo3. The old one works but is a little crude in paces - it would be nice to fix that.

So I have a few things I'd like to play with, I guess time will tell if I actually GET to...

uniracers_credits

uniracers_credits
Originally uploaded by mikedailly

So someone was asking who was who... so here we go (hope I remember it right!) Clockwise fomr the top-left.

Robbie Graham - Artist
Malcom Scot Maxwell - Game coder and project leader
Dave Jones - Boss, Big cheese, and all round pest.
Andrew Innes - Front end, stats and general coding.
Martain Good - CG artist (did all the unicycles!)
Steve Hammond - Manual
Mike Dailly (Me!) - Level Editor, Uniracer compression, SNES framework and tools.
Colin Anderson - Music and effects.
Craig Arbuthnott - Head of testing
And I cant remember the last two. Testers I think....?

Head over to the staff pics on the Flickr account for better (all be it older!) pictures of some of us.

Past tools.

I've just my old SNES framework source, so if I get a chance I'll clean it up and release it. Not sure who its of use to but its always fun to look at others code so... It does have a nice squareroot function in it, so you could always steal that. Its also (of course) 65816 based, so C64 SuperCPU users could steal more from it. If its of immediate interest let me know and I'll try and do it sooner....

Speaking of SNES.... I found this video on youtube ( YouTubes great! ) of the end sequence to Lemmings II. I had pretty good fun doing this. Theres actually a single pixel on the front end screen that if you click it, you get to the end sequence without playing the whole game - see if you can find it. ;-)

Plus4 world lives again!

Plus4 world now has a new home!! Although it still has some way to go in terms of files etc, you can now at least log on and use it again.

http://www.plus4world.com

Thanks again to Csabo for all his hard work!!

Plus4 world gone....

Well, it would seem that yet another problem has hit plus4world, emucamp has had many problems reciently and now it seems its domain name has expired! I'm not sure where all the plus4 folk have gone to talk/complain about it, but I think now is the time to bite the bullet and move the site - enough is enough. Emucamp was okay, but its so incredibly unreliable now it's not funny, and I'd hate to lose the site because of some badly maintained server.

I tried to mail Lando, but he appears to have changed email addresses since I last spoke to him - which is a bugger....

Alive and kickin'

Well, I appear to be back in the world of the living again. I finally had to take a couple of days off to try and kick this cold and it appears to have worked, so after a reasonably lazy couple of days I'm finally sitting in front of my machine again looking back at the debugger.

When I started this I thought it would be a reasonably small job, and one I could quickly do and get it out there so I could progress with more interesting things, but alas... this was not to be. It's turning into yet another mamoth task, and one thats eating up yet more of my limited free time. Sure, once its all working things will be great! But that still looks like being a long way off for now. I may have to scale my initial release back a little so I can at least release something and not have this as yet another project that never seems to appear.

What I'll probably do is finish the Plus4 debugging so that its pretty good to use, and then do the emulator (TCP/IP) stub for everyone else, then release that. I know I wanted to get the C64 version done first, but that will take ages, and since it requires a real machine hooked up, I can only do it in my work room at home. Once I get TCP/IP support for emulators, I can carry on doing debugging features using my laptop anywhere I like using Minus4 (or my C64/Spectrum emultor for that matter).

I gave Russell my spectrum emulator and he's be rewriting it in C# with the idea of playing with Silverlight, but this means he's doing a Z80 debugger and will use the plug in interface to support his emuator.

So....thats where we are just now, lets hope I can kick things up a gear and do some actual work! Of course...I go away on holiday to Florida in two weeks, so that's gonna get in the way, although I've bought an extra battery for my laptop, so hope to do some stuff on the plane there.

Wikipedia

I was reading through some wikipedia entry's on DMA and their games, and it staggers my just how bad community editing can be. I look at these every now and then to see if anyone's discovered anything cool, but what strikes me the most is how bad the editing is.

Uniracers for example. About a year or so ago it had a fairly large entry and was pretty factual, but now its a tiny stub as editors trim bits they don't like. If you look back through the history far enough, you'll find additions by me where I talked about the split screen system having to be verified by Nintendo R&D. This was because I got the guys to use an old C64 trick of ripping sprites to get perfect splits. However some over zealous editor started asking for citations and verifications and it eventually got cut. It pisses me off a bit since they really know nothing about it, and any citations would have come from me in the first place.

The problem with only putting down things they are 100% sure of because its been in print somewhere else, is that there's never anything new. Its just a duplication of what's out there already. This is stupid. It means no one could EVER use wikipedia to publish a new theory or idea, because some little Hitler will come along and nuke the whole thing just because they have never heard of it.

Community editing is good, over all the right thing gets out there. Bits you've never heard of you leave, bits your sure about you add or fix. But at some point you get some kind of community editor, and they have too much power to kill things they don't like or don't understand. They are usually appointed because they've spent lots of time adding content, but it doesn't means they know what the **** they're on about.

All in all, Wikipedia is going downhill fast. Rant over....Grrrr...

New we're getting some where!

So with most of the ground work done I've now managed to get registers from the client and can dissassemble the current view (as shown). I'm using a rich text box (after some head scratching) and it appears to work fine. I have a stack of new interfaces and classes that people will use to write their own debugging aids, and Russell says he wants to do a Z80 one and plug it into my noddy spectrum emulator. (which I had forgotten all about). This means when I get the basic one going, he's going to write a TCP/IP (or UDP) version and that can be given away free for folk to include in their own code. These stubs will be in C++ so most emulators should be able to use them.

I did start to port my spectrum emulator over to C# but never got around to finishing it - perhaps something to do on my next holiday.....

So the current state of play is I can stop the target, run it again, and get its registers and a dissassembly view of it. Next I need to be able to STEP an instruction, and then things will get really interesting! While you're using a PC to debug the Plus/4, its easy to forget that it's a slow beasty and the more watches, memory windows and the like you have, the slower its going to go! downloading all that memory will take time! So if its too slow, closing a memory window will probably speed things up quite a bit!

The debugger is also designed so that one day I can add source level debugging as well. This means you can step through your actual source code and not just some abstract view. It also means you'll get all your comments while stepping and viewing code. This will be pretty cool indeed. Minus4Dos actually did this. It was the last feature I added before stopping its development, and it was pretty cool so I'm looking forward to getting that feature back. I'll need to expand SNasm's output support so that it does index files which will eventually enable me to do this, but that should be pretty easy....

Slow going....

You know C# is great and all, and you do code things faster, but the ground work reall does take some time to lay. I've found this at work as well where I use C# all the time, it just takes longer. When we started out current project it took us much longer than we thought it would to get the base application framework running. Of course once thats done you really do go quicker, and a few things are quicker right off the bat! I implemented a symbol table last night using my ISymbolTable interface, and using a few Dictionarys I was able to write it in about 15 minuets. In the past I've had to do a binary tree so I can do symbol lookups quickly, but Dictionarys in C# are very quick so I just dont have to worry about it.

I've also been slowly adding the basic 6502 dissassembler while at the same time trying to make it more C# than all the last versions. I've more or less just cut-and-pasted if from the old version (which is the same one I've been using since Minus4 DOS days!), so I want to make it a little prettier.

I decided a little while back that I just dont want to use C/C++ anymore unless i really have to, as C# and managed code is just so much nicer. I'm stuck with things like SNASM and Minus4 of course because they are pretty old and would be a major task to rewrite, and thats not something I want to do just now.

Anyways..... I'm slowly laying all the groundwork and I'm almost ready to start dissassembling stuff to the screen. Once I have that then steppng code will be the next big thing, but that appears to be a long way off for now. I'm actually looking forward to adding support for this to minus4 since while the debugger in Minus4 is actually one of the best in emulators, its still pretty poor. Also, once I have the module to do tracing in Minus4, I'll release that and see if i can't get someone to implement it in VICE and YAPE which would make my day.

(I also secretly hope that I can do a PC Engine module and get it added to Magic Engine, and possibly do a proper remote debugger for the real hardware too - one day!)

Come and get it!!

I've now added the C64 frame work (and sample app) to the downloads links on the right, scroll down a bit and you can't miss it!

So to recap what I've given you to play with in the framework....

Initialisation, mainloop and interrupts all setup and ready to go.

Production quality multiplexor

Three seprate switchable sorts.

Simple collision detection system

General sprite animation system.

Game based keyboard and joystick routines.

Simple player control framework.

Lightning fast 8x8bit multiply routine.

Simple random number routine.

Built in MMC64 FAT16 file loader.

Simple example platform engine showing the framework in action.

And there you go. As a little aside, the example also has a byterun decompression routine built in that you can use as well. Its all very simple really, but if you have any questions (or find any bugs) feel free to bug me about it.

Hope its of use to you and gets you going on your next great game!

MMC64 loader finished

I've now completed V1.0 of the loader complete with PRG file loading. Its shot up a little to about 900 bytes but it's now functionally complete. The only thing missing (which isn't vital just now) is error checking on initialisation. Its not important because if youve done a game thats supposed to load from an MMC card and its not there, then you have bigger problems! I've just ordered a retro replay so I can check all is well with that too (okay, okay...Coz it's cool...)

So tomorrow night I'll try and knock up a new downloads page somewhere and get all this up for you lot to play with. I'm not sure what I'll work on next but I like the idea of using the MMC card loader in the C64 version of XeO3.

I also want to do a proper Super CPU version of the loader so I can start playing more with that. I'd love to see how many software sprites I can pile on a bitmap screen, and I'd love to try that Lemmings idea too...

MMC64 Progression...

I've progressed quicker than I figured I would and have almost got files loading from it. It also supports directorys and will load a file from a full path+filename (just about). It only uses 8.3 filenames so far, but I suspect it will get expanded to do more in the future.

It takes arond 2k to add this although 600 bytes of it is data and a sector buffer. I suspect this will shrink a little once its all working properly, but to have fast access to 4Gb's of data is probably worth the extra space.

I also plan to put in a recursive directory search, allowing you to search for a game directory and then load from there. That means people won't be forced to put everything in the root directory.

I will also write a full Super CPU version allowing you to load megs directly into memory, and MUCH quick than a floppy could.

Life after floppies....

I've spent a little time trying to chat up my MMC64, but it just won't respond to my tender words, at least I wasn't having much luck until about 5 minutes ago. I was following the documentation completely - cut and paste actually - but with very little to show for it. It then occured to me that since I'm loading from it, it must already be enabled and ready to go. So I've dispensed with the full initialisation and jumped straight in with sector reading, and what do you know! It works! I'm not quite sure what would happen if you have to re-initialise the thing as I can't seem to get that going at all, but as long as the cards in and you've just loaded the main program from that, its all funky.

For a first pass, not having any error state is probably fine, after all its not like you have to swap disks (err...MMC cards) during a game or anything, and if you remove the card then its probably your own fault. Still sometime down the line doing a better fault tolerant system is desirable - but lets get the bugger working first! I still expect this to be released in V1.1 of the framework, but its good to see it shouldn't be too difficult.

I've also added a simple animation system to the framework even though I said I wouldn't. I figured you can always rip it out, and in the end the ones I write are almost exactly the same over and over again so sod it. This means theres now the multiplexor, a few sorts, basic collision, animation, joystick and keyboard input and a very simple test app - which is a good start. Actually, theres 2 test apps. The Frame work has code to bounce sprites around in a simple manner, and then theres the playformer framework which gives a little more realistic usage. Still the more the merrier.

I'll now have to do another web page to download all this rubbish, and expand my wiki page to have some simple documentation...and I mean simple...

C64 framework V1.1?

I've thought of one more thing I'd like to add, but its not a quickie by anymeans so I'll leave it till version 1.1 so that I can get this version released. After speaking about using the MMC card as a loader, I suddenly realised that it would be awesome to have a proper file loader built into the framework. That way these no excuse as to not use it, and it'll make development MUCH simpler. Simply bung your files onto an MMC card in a folder or something, then load them - how simple would that be! It might also mean we would start getting some more games that load directly from the MMC rather than floppy/tape, which would be very cool.

I also suspect V1.2 will be when I start to add remote debugging features through RR-NET. As I've mentioned in the past I do have the beginings of a remote debugger on the Plus/4 and would like to get that onto the C64 but using the ethernet adapter rather than the user port. Although since the upload/download part is prett much GetByte()/SendByte() I can probably have both in case people don't have an RR-NET. It would be good to get a proper devkit again as I was reading about the old PDS system I used to use and starte getting a little homesick for it...

You can read about it HERE if you wish although its in spanish. HERE'S a translated version via Babelfish. It really was an amazing little system and I miss it hugely.


Oh and as a little side note, I've managed to get WWW.XEO3.COM again. I'd let this expire and some bugger pinched it which is why I went to the .ORG, but I've now got it back again so I'm happy.

C64 framework and sample

I've now finished the sample app that I was doing for the frame work; well, as much as I intend to. As you can see its a platformer in bitmap mode, and you run around collecting the bombs. Its basically a simple version of the first level in bomb jack (without the baddies). It uses the built in player-2-sprite collision routine as Ive been lazy and done the bombs as sprites, but it does help to show how to use the framework better. Also remember that I've only really spent a couple of days on the sample, so dont expect too much.

I've done it in bitmap mode because platformers should never really be restricted by character count or colours, so having a full bitmap is nice. It also let me have a pretty background, although it turned out to be harder than I thought at the time. I had to rip the bitmap off an old Ballistix floppy and then I discovered that I had stored it compressed! So I then had to rip the decompression code from Ballistix into the sample. Still it was only byte run so it was easy enough.

Anyway, with this done, I now only need to clean both up, write some very basic doc's and then upload it somewhere. Perhaps someone will even finish the platformer sample... who knows... It would be cool if you did a built in MMC loader and you could load each levels bitmap from an MMC card really quickly. I think any games you do these days should take advantage of new tech that everyone's buying, and that in turn would help sell more and move things along. If nothing uses a new bit of hardware, no one will buy it!

Last chance for anything to be added though. I can't think of anything, but feel free to suggest. I'm not sure when this will get released, but I dont expect it to be long now. Hope you all enjoy it, or at the very least have fun looking though the source...

Super CPU ideas....

Theres been several comments on the last post so let me go through them here...

First parallax scrollers. Games that have done these in the past have been limited to character blocks to do it's parallax effects and these have worked pretty well for the most part, but perhaps if you actually MASKED a full bitmap onto another you could produce something pretty special looking. Of course doing this would negate the use of the full attibutes as you would get colour clash... still dual playfields is always nice. You COULD stick to doing character based parallax and do a full bitmap scroller which would look pretty good, but not THAT much different from a stock C64 game using characters i suspect. This is what MetalDust does (I think) and its...okay... but we've come to expect games doing that kind of parallax.

Sprites. Now its true that anything I do I'll immediately load it up with as many software sprites as I can, and that I expect the screen to be crawling with baddies+effects. C64 games do this usually with lots of cheats, but if you can draw large sprites, you can push the boat out a little. However these will obviously suffer from colour clash again, which is never good. I suspect that if I arrange the bitmap better (straight rows rather than the funny character mode way) I can seriously increase the number of sprites I can actually draw. I'd then convert the screen on the fly as its copied down the VIC memory. Since the SuperCPU has a 1 byte write cache that gives me 20 cycles to get the next byte, and thats more than enough to convert the straight row format into the silly Commodore one. Of course on top of that, I now have 16bit registers allowing me to load and mask things on better, and upto 4Mb RAM (although mine has 16Mb, I think 4Mb is a good limit - anyone have less?) allowing me to pre-rotate everything at the start.

Now its also been suggested that you could do a full PROPER Lemmings game, and this is also true. You wouldn't be able to get the lemmings as the blue/white/green we all now and love, but a full white would be possible. In fact the best way (and to avoid colour clash) would be to use the full bitmap mode for the backgrounds and multiplex Hires-expanded sprites (on X at least) for the lemmings. That would have MCM resolution but it hires. Thats doable and gives a full dual playfield for drawing sprites + explsions easily. Not only that but because the SuperCPU can quickly multiplex sprites, you're only going to lose a few scanlines making this new playfield. On top of that... It only takes 7 sprites to do the playfield, leaving 1 hardware sprite for the cursor! Using the Commodore mouse you could finally replicate the proper lemmings game on the C64 - complete with the full 100 lemmings!

Lastly.... I suspect this will become a pet project and would be the ULTIMATE game for a SuperCPU, as theres no WAY a stock machine could even hope to do it.... GTA. Yup, I've been giving it some thought, and I think I could replicate the graphics engine I did on GTA1 on the SuperCPU. Im not sure I'd zoom in and out in the same way, but I think I can certainly do the perspective buildings... They may or may not be textured though... that Might be asking too much, but you would certainly get the effect GTA had of zooming around a 3D city... now that WOULD be cool....