Glove+

Just a reminder that the original Glove is still available on cassette from Cronosoft as well as a large number of cassette games for other systems too!

After clearing the original dungeon, the Mage and the Caveman successfully restored their National Insurance contributions and looked forward to a few more years avoiding work. To be fair, there aren't an awful lot of haunted dungeons left these days and business was terrible. However, it was not to be. New cutbacks meant that anyone who did not make themselves available for 97 hours of work (per day) was not entitled to any support.

Relunctantly, they restarted the old company and were lucky enough to find that there was a contract available. However, it was for the original dungeon they had cleared years ago.

Puzzled, they were told that it was more profitable for the property company to keep the dungeon derelict and claim tax breaks rather than refurbish it into affordable homes.

An inquiry into the practice (which had reduced global GDP by 10%) found that a series of deliberately designed and utterly cynical profit-making schemes had created the biggest threat to humanity since the Ice Age, but that no-one was to blame and there was no need to change anything. A small child was fined 75p, as a token gesture.

Over time, the result had been the rehaunting of the dungeon. To make matters worse, some of the ghosts had been watching DIY programmes and had made a bit of a mess.

This was going to be a bit more difficult than last time, but they had a stroke of luck when they were able to hire a new recruit (on a zero-hours contract, naturally). A Gorgon had made her way to the UK after Greece's economy had crumbled. Her business (making STRANGELY REALISTIC statues) had floundered after a certain Italian politician had lost his job and was no longer able to spend government funds on voluptuous figures for his renowned parties.

She had tried hard to find work, but with no luck. She did well at telephone interviews, but never seemed to receive any response after the face-to-face stage...

Together, the three of them had the combined firepower to take on any (non-fiscal) threat.

And so, in they went...

After a long hiatus (about 6.5 years) I was asked by John Linville about the possibility of fitting Glove into a banked cart (16K pages). The idea was to get it ready for CoCoFest 2016, but sadly it was too much of a task for that deadline. I have continued working on it though.

First of all, a CoCo cartridge immediately loses 256 bytes, as the area at $FF00-$FFFF is always pointing to the built-in ROM. Secondly, the CoCo 3 puts RAM at $FE00-$FEFF, so you lose 512 bytes. THIS HAPPENS PER BANK! You can switch off the RAM section and access the information underneath, but CoCo 3 emulation is patchy and not all emulators support that. Additionally, it could cause a problem if an NMI arrived, although I don't think it could under that circumstance? It might depend on the interfaces attached.

I'm planning a 32K cartridge (2 banks) which means a loss of 1K. Ultimately, that means I really have a 31K cartridge. The original Glove was about 33K of code + data, so that needed some work.

In my spare time, I have optimised the game for size and speed, using techniques that I just hadn't thought of at the time. It is amazing how looking at something with a fresh brain can make a difference. Last time I looked at this code, I was worn down by the endless development and was happy to declare it finished. This time, I was able to take it to the next cliche. Sorry, level.

I found that the passage of time had stopped a lot of my tools from working, some of them date back to DOS and Windows 98. My C prototype and level designer/compressor was written in Watcom C for DOS and now only runs under DOSBox. My graphics converter was compiled under the same tools and could not find the 8.3 filenames it was expecting. One of the emulators I used for development could no longer run natively. The MESS CoCo/Dragon driver had changed dramatically and was somewhat less reliable. :/

I have chipped away at so many routines, instruction-by-instruction so that it is now visibly faster. The speed on a CoCo 3 (emulated, I don't actually own one) is now "ridiculous". I say "ridiculous", but I had forgotten how speedy my original design was and how much my reaction times have slowed in the last 10 years.

As it will be running mostly from ROM, there is the possibility of having an option to use the double-speed ROM POKE for CoCo/Dragon!

I also have 1,500 bytes of free cartridge space, which I could use to speed things up by unrolling some loops and (maybe) improve some aspects of the presentation. It is not Glove 2 (I have some specific ideas for that), so I will call this "Glove+".

Below this point is the old site, covering the development of the original game, from 2005-2009.

This page will display work-in-progress of the 4K entry I am planning for the Minigame Competition 2005. The Tandy Color Computer 2 (16K) was the first machine I ever bought, so I thought I'd try and make a game for it. The question is, is it as powerful as the other 8-bit machines that became dominant in the UK in the '80s? Could it have been happily running conversions of Spectrum, C64 and CPC games if it had been more of a success? I hope to find out.

As there are still a number of technical unknowns on the CoCo side (I've never programmed anything above BASIC on that machine), I may have to move over to a more familiar machine. One that is Z80-based...

I plan to do the game in 128*96 mode (you can use some very low resolutions with this machine) as that would make the screen half the size (therefore twice as quick to update) and would allow a back buffer on a 16K machine.

As you can see, it's quite tight with a couple of unknowns. The actual binary size should be ~5K + Levels + Sound, which could be compressed to 4K (although I doubt there'll be many levels). I don't know of any compression utility for the machine, so I'll have to write that as well!

Another thing I'll have to do is to convert my Spectrum graphics grabber so that it can grab 2-bpp graphics.

But what is the game? It's a mini-Gauntlet clone, so I'll go with the working title: "Glove". To make it a bit more unusual, I'm basing the game on the Spectrum version - not the arcade. I actually prefer the Spectrum version, as it's possible to play it for more than a few levels without continuing all the time. (I don't have to shift any graphics either).

Note: I don't want to make an exact copy, I'll be using "new" graphics and different levels.

Having done a lot of it, I can only say that I horribly miscalculated the code size.

Not only will it never be a Minigame entry (no way), it will not be a Tandy 16K game either (unless it's possible to make a cartridge with 32K ROM).

A long, long project which was extremely difficulty to fit into 32K. Level design was a notable part of the time, but it does prove that it is possible to design your own content if you stick at it for long enough.

Surprise! After a long time, Cronosoft are nearly ready to start selling the cassette! I have my free one and it's a great package, well worth a purchase. ;)

The good news is that the Cronosoft cassette release is on! I've had to spend the last 10 days trying to make a working master tape, but I think I've finally managed it - I'm surprised that my TV hasn't turned orange. It took quite a long time because of an error in the loading routine that made it less reliable than it should be. This has now been passed into the game's loader which makes the latest " Glove Final Release 2" a must-download for those of you who've managed to get it onto a cassette but are having difficulty getting it to load in.

Additionally, I've changed the vertical blank interrupt so that the base address of the screen is set almost immediately within the IRQ. This is to try and remedy reports that the screen will flicker occasionally on a CoCo 3.

I was amazed to receive some amazing artwork from graz for the cover AND for an advert! Both are excellent and should hopefully persuade Simon of Cronosoft to respond to emails. (Nudge, nudge).

It's amazing the feeling you get when you see the artwork. Suddenly the process seems more real and exciting (even though a year and a half of development feels very real). The idea of even a handful of people buying the real cassette version somehow makes it all seem worthwhile. I hope this spurs on my other projects.

I have decided to do a full release. Testing isn't actually finished yet, so I may be forced to make a V1.1 at some point, but there's no point in delaying this into 2007. Physical cassette versions may be available from a later date, but for now you can enjoy the full thing. Glove Final Release.

Now, regarding a proper physical release (on cassette)... I have had an offer of inlay artwork, but I am not getting a response from Cronosoft, so I don't know what to think. I may end up doing an internet release and leave the cassette for another day.

Glove is "finished" (as of the night of 09/12/2006)! I've tested it as far as I can with my hardware, so that just leaves testing it on a real Dragon and (somehow) obtaining an inlay... Whether I can release it through Cronosoft is unknown.

This game now has the full 50 levels and I found the bug! I've reordered the levels into the final order and attempted to have a "final" test run. Naturally, a couple of little bugs appeared which I'm now testing for. I may update again later or tomorrow.

I have now reached 45 levels, so 50 is a possibility. I also decided to change the way destructible walls were stored so that I could have as many as I wanted on a level.

Minimal response so far to my bug and inlay queries, but I have managed to make another 5 levels.

The XRoar (and T3) bug is being looked into. Apart from that, code is de-facto finished. I now need an inlay and have been trying to contact people about that... No success so far. I would like to get it finished in time for shipping for Christmas, but I can't guarantee that all the pieces will come together. In the meantime, I make the odd level or two to add into the game, maybe I could make it 40 levels - if I'm lucky.

The multiload system has been made and it is possible to play the 30 levels from start to finish on the real hardware!

There is one bug showing up in XRoar, where the game starts at level 3 on the Dragon 32 - I'll have to look into that. The game loads in one chunk at a time in 32K mode and loads everything at once in 64K. There is no disk multiload, at the moment, so I'm pre-loading the combined chunk at once for that.

I've also changed the spawning routine so that you can start a player while the other one is surrounded by baddies (I would probably get complaints if I didn't) and I've added a pause routine. I also had to optimise the game for space (again) while I did all this. I improved ADDCAS so that I could strip out the "RAM" section from the main file and save 9 blocks on cassette.

Mastering to tape is a problem again. One possibility might be that the CAS to WAV converters (known to me) do not put out a gap between each file - I may end up having to write my own!

Note below: the main loader not only has a new screen, it also has a block countdown to give you an idea of how far it has gone!

The lobber bug is fixed and two-button joysticks are now supported. Now I have to design the multiload system. I'm not particularly looking forward to that...

OK, I've reached the 30-level mark. I was hoping for 50, but my creative juices have dried up, so I'll stick with 30 and start working on code again.

Just a little update to show that I'm still here. I'm approaching the 30-level mark, but it is taking time to make these levels.

There has been no feedback from V3 yet... I have managed to get the overall level count up to 12, it is slow progress. It has also revealed a bug in the lobbers' lobbing on a wrap-around level. Hooray for bugs...

I've read that there's a two-button joystick for the CoCo 3, so I think I will add support for it. Unfortunately, the second button on the left joystick interferes terribly with the cursor keys & space, but I don't think I'll restrict players from selecting the left joystick and cursor keys as it only affects certain setups.

This release is mainly an attempt at fixing the Dragon PAL/NTSC and Dragon 32 RAM detection. I haven't had any reports from 32K Tandys yet, so it might be relevant there as well.

Also, I've modified the BASIC loader of the DSK file so that the drive lights switch off on the real thing!

Further difficulties have presented themselves. The Dragon 32 (I've had no reports from 32K Tandys yet) can have different types of upper RAM. Sometimes none, sometimes mirrored, sometimes partially broken (batch-failed 64K chips). Possible solutions have been suggested for this, PAL/NTSC and loader problems.

I'll release a V3 when there's a reasonable chance that all the detection routines will work.

I've added a "roll" option and the ability to draw lines into the level designer, it was just getting too awkward to design levels with just plot and unplot options.

V2 seems to have fixed the bug which was believed to be disk drive related, so it can now run on the average CoCo 3 setup. I still have a report of a problem with a CoCo 2 with a disk drive, but I can't figure that one out.

All reports seem to be from PAL machines, from the UK or Australia. I'll need to include a different PAL/NTSC detection routine for the Dragon machines and the cassette loader is still mysteriously erratic.

I've got some good feedback on some of the hardware configurations. The PAL/NTSC detection doesn't work on the Dragon and there are some distinct problems with CoCos with disk drives attached.

This version removes some (accidentally) illegal instructions which could've caused problems on a 6309 CoCo and gets rid of the "key turns into a baddy" bug.

Publish and be damned! I found that the loader worked fine if I played it directly from the PC into Tandy that it worked fine. I changed the loader a bit and fortunately I was able to get a working version on cassette. I hope it wasn't a fluke!

Any feedback is greatly appreciated and please test it on as many types of real hardware as you can. 32K/64K machines, Tandy CoCo (1, 2 and 3), Dragon (32 and 64), Tano Dragon, Prologica CP-400 and PAL/NTSC machines.

Remember that I will be looking for people to contribute levels to the game, so contact me if you're interested.

I had intended to release the demo tonight, but a cassette loading problem put paid to that idea at the last minute. The machine code loader works initially, but then crashes. It works OK on the emulator, but not on the real hardware. It wasn't a recording error as each file was loadable separately. At least it gives me more time to write my begging letter to ask for some level designs on various forums.

Other errors included the game working on the original CoCo in one version of MESS but not another and a syntax error on the "cocoe" disk loader (that goes away when you run it for a second time).

The demo had to be stripped back to 4 levels. One of the old ones and three of the new ones. Better luck next time...

All known bugs have now been fixed and a handy machine code loader has been written, so that you just have to type "CLOADM" to load it (just like the games of the time). Tommy has nearly finished the final set of graphics, so that means it is time to release a public demo version... when I've written a handful of levels that are better than my test levels.

Writing even a few new levels immediately means that it goes over the 32K limit, so I'll have to define some simple ones for the demo.

After the demo version, it'll be a matter of writing a load of levels (50 sounds rather ambitious) and then designing the multiload scheme.

I optimised one of the collision routines (again), fixed the random number generator, added code to ensure that only legal combinations of controls can be selected and optimised the destructible walls. The net result leaves us 192 bytes below the limit.

I tried everything to reduce the size of the code. I merged PSHS instructions, replaced all PULS ?/RTS combinations with PULS ?,PC, replaced CMPr #$FF with INCr, made the note data 8-bit (etc)... Eventually I optimised another couple of collision-based routines and made a decent saving, enough to get it 222 bytes under the limit.

I added the credit for Tommy into the code (in preparation for the final graphic set), but that cost me an expensive 31 bytes by itself! I currently have 188 bytes to spare.

I finally tested the sound routine on the real machine, it sounds a bit clicky when it is supposed to be silent, but it is still roughly what I expected.

It is now becoming rather difficult to reduce the size of the game. It is now 123 bytes over the 32K limit. For some better news, the CoCo 3 bug has been fixed (it was just a redundant instruction that depended on the initial value of 'U') and I may be getting some new graphics.

I've finally got around to putting some sound effects in the game. They sound horrible and use up a significant amount of CPU time. Even worse, it puts the game 274 bytes over the 32K mark. More work required...

I have finally written a controls screen, added joystick support and changed the frame system so that it runs at the same speed on PAL and NTSC systems. It also speeds it up a bit, as the old system would wait some time between vblanks. The downside is that I only have 325 bytes left, which has to fit the sound, multiload routines and part of the level buffer.

It has been quite a long time since I posted a screenshot (hello, Tommy) so I will do so now, without further ado.

The two player camera code bug (last mentioned on 22/10/2005) has finally been fixed! But, a CoCo 3 bug has cropped up - it crashes if you get hit by a lobbed rock.

I've been working on detection routines. I can detect a Dragon or CoCo 3 apart from the original machine. I can also detect 32/64K memory. But, PAL/NTSC is proving to be more difficult, so I've been asking around for help with that one.

I've also been checking the web and I found cassette loading and saving routines from m/c, which (with a little modification) appears to work on both machines (and should eventually allow for my planned multiload).

Additionally, I've managed to shave another 326 bytes off the RAM total (mostly by having a version of a well-used macro that leaves the registers in a messy state afterwards).

Finally, I've added support for the Dragon keyboard. I know how to read the joysticks now, but the time taken is frightening: 20 to 25 scanlines (according to MESS). That wouldn't be so bad, if it wasn't for the fact that the game could do with running a fair bit quicker.

Now 1512 bytes below the limit. Combined with the 608 bytes currently used by the test levels, that leaves 2120 bytes - which puts me inside the 2K limit that I wanted to be sure of being able to fit all the rest of the stuff in.

Well, we're now 1366 bytes below the limit and very close to my target. Some of the optimisations may have improved the speed slightly, by using fewer instructions in some macros.

I've also messed around with sound. There is no actual sound chip inside the Tandy, just a 6-bit DAC that you can write to. I've written a routine that can make an awful tone and an awful piece of white noise (my polynomial isn't very good), but I won't integrate it until I've a clearer idea of what I'm doing.

Finally, I've been sent some nice new graphics by Tommy. They really add character to the game, just three more enemies to be drawn now.

It's now 1211 bytes below the limit. This spectacular reduction was mostly achieved by merging part of the character and projectile collision routines into one generic routine. That saved 416 bytes on its own, but it does mean that time-consuming part of the code runs slightly slower...

The other main thing changed was the keyboard routine, which will now make it very easy to add support for the Dragon keyboard, although joystick support for either machine is a different matter.

Phew. 622 bytes below the limit. Where will I find another 800 bytes without affecting the performance of the game?

I'm now 542 bytes under the limit! It was mostly done by unpacking the projectile structure, as the code required to read and write to it was bigger than the amount of RAM I was saving. If I can find another 1K, then there might be enough space to complete the final routines and have 2 or 3 levels per load.

Tommy sent some more work-in-progress graphics, which now includes the wizard and the warrior - very nice. I still don't have a full set, so no screenshots yet!

I've been rejigging some macros and I've managed (somehow) to get the game from ~128 bytes over the 32K limit to 258 bytes under the limit.

There are 866 bytes (overall) available for the levels and the (as yet unwritten) sound routines. Even with a multiload, more than that would be required...

Tommy has agreed to help with the Glove graphics and he has provided some nice work-in-progress stuff. I'll put up a new screenshot when I've got a full set.

Hmm... I've just saved ~384 bytes (easily) by using the DP register and SETDP. Still ~128 bytes over the 32K limit though, although I could probably reclaim ~512 bytes by shrinking the screen size and getting rid of all the "half tile" printing routines.

The level compression has been written, which finds horizontal, vertical and diagonal lines and squashes them into a bitstream. That was pretty good, but ZIP could still beat it for levels with large blocks of the same item, so I added "box" searching and solved that problem (although it now takes 15 seconds on a 400Mhz PC to squash the worst case example).

One bug has cropped up in the original. The 2P camera code on wraparound levels goes horribly wrong when the players are standing either side of the zero boundary.

The (unexpectedly) large size of the game code has made this project take a long time, especially as I've had to shave off a few K here and there to try (unsuccessfully) to keep it within the 32K boundary. I was also unsuccessful in geting graphics and level designs from the Spectrum scene...

Here are a couple of screenshots, one showing the (near) final state of the game and the other (belatedly) showing the level designer on the PC.

Consider this case closed, as it's now time to have one final go at converting KO99 to the Spectrum.

Here's the first screenshot of the Tandy version. Code & constants have now increased up to 19K! The grabber left some graphics emaciated, most of them haven't been touched up yet.

Thankfully, the Minigame Competition has had its deadline extended to the end of October, so this could still be on the cards.

The C prototype now has practically everything code-wise. A full status panel, a level designer, timed levels and I've even added some text boxes (e.g. "Don't shoot food"). The only other things to do are to break the gameloop into separate frames and work on the level compression.

Asset-wise I've individually asked three people to do the artwork. No one available yet... I still need a bundle of levels to be designed and sound (the great unknown) will come last.

I've also managed to research the CoCo 2. I'm using A09 as the assembler, IMGTOOL (from MESS) to build a DSK image and a combination of (Jeff Vavasour's) CoCo2 emulator and the MESS emulator for testing. My Spectrum graphics grabber has been hastily modified to grab Tandy 4-colour graphics. 6809 is quite nice, you can use temporary variables on the stack very easily, so you never have to worry about running out of registers.

Some conversion of the code has begun. About 3/4s of the front end has been ported to 6809 and has immediately highlighted a problem - my code estimate was well short. I've already exceeded the 2K estimate and I haven't converted any game code yet! So, it doesn't look like this game will fit into a 16K machine.

One possibility would be to make a text mode version with block graphics! That would save approximately 7K and maybe allow a Minigame entry depending on the final code and level sizes. Anyway - I must get the game done first.

It still looks largely the same but it does play very much better. On/off-screen code has been done, which makes the game a lot easier. All enemies fire as they should and some animation sequences have been fixed.

The status panel is now operating, using the intended blocky Tandy font and an initial state machine is in place to swap between levels, initialisation, etc... It's twice as high as I'd wanted it, but there's really no way to make it smaller, not with the resolution I'll be using. (Note: I could use the horizontal interrupt and change the resolution just for the status panel, but I'm not sure about it and I don't have a real machine to test it with). The Tandy version will be 16x10 tiles instead of 20x10.5, so the perspective won't look as bad.

It looks like I won't have teleports, but I might make up for it by having multiple traps. This should improve the design of the levels.

Note that there are now two players (the other one is the red arrow below the yellow arrow!)

Unfortunately, I must stop at this point. Some work has cropped up and I'll be busy for the next six weeks. This will make it nigh-on impossible to meet the September the 30th deadline...

Correction: the font will have to be 4*8, as it's impossible to make a 4*4 font. I'll have to make the panel twice as tall or flick between score / health / pickups. I don't want to make it too tall, so I may choose to flick between them. The current "printf"s for the panel take up more CPU time than the rest of the game...

Door code has been added, as well as more AI code (note: only two different door graphics to save memory). It now looks sufficiently different enough to post a new screenshot. OK then, it may not look that different, but it does play differently.

I've worked out the collision detection, so the player can now pick up things, trigger traps, fight and move properly. The enemies can also move and fight properly. The collision routines are more CPU intensive though...

I'll also have to add some tiles in for the score panel, as there is no font available on the Tandy machine. Since it'll be in a low-res mode, they'll only be 4*4 pixels (4 bytes each)! I'm still within budget regarding graphics and RAM variables.

Visually, it doesn't look very different, so there's no point in posting a new screenshot.

You may think that this looks nothing like a CoCo screenshot and you're right. I'm doing a C prototype on the PC first, that allows me to work out the trickier gameplay code first and make the work on the actual Tandy a conversion job (as I have not programmed a major 6809 project before). All the graphics are temporary. The arrows represent the player and the enemies! At the moment it actually plays a bit like the game "Spore".

The AI code is quite simple, but the collision detection is an absolute nightmare. Compare the Z80-based versions of Gauntlet with the 6502 versions and you can see just how important the collision is to this type of game.