Some years back, I decided to have a go at converting Akalabeth to the Vectrex. I didn’t much fancy learning the intricacies of Vectrex programming so instead did this using a Vectrex32 cartridge. This is an ingenious gadget that is essentially a little computer in a cartridge that takes over from the Vectrex CPU and allowed me to program in a BASIC variant. I got that working and released it on here although I doubt many people ever played it. The Vectrex32 itself never really took off as a technology. I did struggle with it’s limitations when doing the port, not something I’d expected with such a simple game, and it was quite expensive to say the least.
A year or two after that, we had the idea of doing a very small run of these cartridges as a Kickstarter reward to go with Andrea Contato’s second book about Origin – Through The Moongate Part 2. We got approval from Richard Garriott, I improved the code and after numerous covid related delays it was shipped several months ago along with the book to all the backers. I highly recommend picking up a copy of Andrea’s book if you are at all interested in the history of Origin. As for the game, the plan was always to release the final version on here at some point and it’s now available to download here + on the downloads page. The code is all in BASIC so you are free to fiddle with it and make tweaks/improvements as you see fit. Apart from the graphics routines, it’s based off the original Apple II source code and a close match to the original game. I did make some changes to the dungeon generation which would throw out unsolvable levels in it’s original form. I think Richard just picked some numbers which happened to work reasonably well with the Apple’s random number generator – there was certainly nothing in the code to ensure the levels were actually playable.
The changes to the previous Vecalabeth release include :-
All mazes are now solvable Your lucky number is actually being used to generate the mazes and stats Mazes are consistent, i.e. you will get the same level every time you return to it rather than a new random one Improvements to the control responsiveness Splash screen at the start Monsters aren’t mirror images of the originals any more Numerous bug fixes that were found during playtesting
It’s not something I’ve tried myself but I understand that the new PiTrex cartridges will allow Vectrex32 games to be run. This is a much cheaper alternative with many additional capabilities and should mean that more people than I expected actually get the chance to play this. I’d love to hear back from anyone that does. Getting a physical release presumably means I’m officially a game developer now, although I have to say I prefer playing games to writing them so it’s not something I’ll be making a habit of.
Updates are a rarity here these days but the end of the year seems like the appropriate time to come up with something to show I’m still here. As far as actual content goes, I’m still methodically scanning PC Zone’s. The plan was to have them all done before 2020 but the help I was receiving on that front stopped earlier in the year leaving it all to me once again. As of right now there are a mere 9 issues left so the whole lot should be archived by the end of February.
In slightly relevant news, I did a little work on improving Vecalabeth a couple of months back for the limited physical release that is part of the Kickstarter rewards for Through The Moongate part 2. I’ve added a title screen (plotted in true old school style on graph paper), tidied up the bugs and also done some work on map generation. Reproducing the maps faithfully isn’t easy as the original code basically relied on the non-randomness of the Apple II’s random number generator. This worked by supplying a seed number and it would effectively work through a given sequence of numbers from this starting point. It appears that all those years back Garriott simply found some seed numbers which worked reasonably well as a starting point for his map generator and went with it. Every time the code generates the map again, the random number generator gets reset which is why the code behaves exactly the same if you repeat the same events on a given level (a long known means to manipulate the random amulet effects among other things). This sort of psuedo-randomisation cause + effect was still present in later games. E.g. in Ultima 2 you can choose which stat got “randomly” raised at the Hotel California by counting the number of moves taken to walk to the clerk from entering the map. What I can’t find is documentation on exactly what the Apple’s random number generator does so I can reproduce it.
So instead of that, I’ve implemented my own pseudo-random generator for Vecalabeth to have static map levels based on your lucky number. I’ve taken the decision to keep everything else actually random so there is no knowing what the amulet will do this time around. This has gotten the game essentially where I want it to be but I have to tweak the map generation still to find a decent balance between dead ends and too open levels. I should have some help with playtesting ultimately so the port is on hold until then when I can get a second opinion. I won’t be releasing my updated code for Vectrex32 owners until some time after it’s in the hands of paying backers but I expect to put it on here sooner or later.
I thought I’d write about some recent random adventures in retro. I’m still acquiring the occasional piece of old hardware, one of the latest and largest being a 21″ Apple Studio CRT. 21″ monitors were extremely expensive when new and as a result relatively uncommon these days. This Apple Studio would have cost an outrageous £1500 back around the turn of the century. It was made specifically for Mac’s but contains a regular Sony Trinitron tube and uses a standard VGA connector meaning I reckoned it should work on a DOS PC at least in theory. The potential downside was that the picture controls aren’t in a menu on the monitor and were instead controlled by software on a Mac via a USB connection. This lack of compatibility gave me the chance to get it relatively cheap so I took a punt and grabbed it while I could. First impressions were promising. While it may not officially support resolutions below 640×480, the command prompt came up fine. The picture geometry all looked good and it appeared it was going to work straight out the box so I set to fitting it into my desk.
The desk I use for all this stuff is a peculiar arrangement I picked up many years back. The brand name escapes me all these years later, but a company in the 90’s came up with this idea of having glass sections in desks so you could mount your monitor below the surface at an angle and look down through the desk when using it. This saved a ton of space with CRT monitors, which given that I hadn’t even moved out of my parents at this point was a seriously useful feature. It’s a feature I still take advantage of being able to double up on monitors with my flatscreen and CRT being on the same desk. There are a couple of adjustable padded bars to accomodate different size screens, and originally a harness of sorts which wasn’t really needed and is long gone. The desk wasn’t supposed to support monitors larger than 17″ so I had major doubts on getting this behemoth in place. Attempting to manhandle 35kg of monitor into it was a minor nightmare but just about possible with enough perseverance.
It was only at this point that I noticed that the picture was way too dark in some games even with brightness and contrast on maximum. 7th Guest above is a prime example. This could be due to fading of the tube over time but I think it’s more likely to do with Apple’s non standard implementation once again. Additional brightness controls were built into the display drivers on the Mac, working in the same way as a gamma control in a game. I could get a great looking picture in this way on my Mac but could barely see a thing in darker games in DOS. Not great and I was wondering if I’d wasted my money.
So I started looking around for a solution. Were I simply using Windows, I could of course have fixed this in software but this wasn’t what I was looking for being ever the DOS stalwart. There are no DOS software equivalents that I could find so I needed a hardware solution. Around the time HDMI started to become a thing, a company called X-Vue spotted a place in the market for HDMI to VGA adapters so that people with older projectors or CRT’s could connect an HD signal to their existing and presumably expensive home entertainment set up. They produced the HDFury for this job, later versions of which are for sale to this day. They also offered an add-on for it called the Gamma-X which is what got my attention. This gadget could be bolted on to the HDFury adding a slider control to boost the gamma level. It even conveniently uses VGA connections for in/out – exactly what I wanted.
It would have been too easy if these were still being manufactured and they were discontinued 10 years back. Initial hunting found new old stock still for sale in Germany on Amazon. I tried twice to buy them on there from different sellers, both times being sent an HDFury III instead for no clearly obvious reason especially when there was a picture of the Gamma-X on the listings. I got a refund both times, and even got to keep the HDFury in one of those cases so it could be worse. Weeks after I’d started, I ended up on Ebay in the USA instead where there were a good number for sale around the $15 mark. I had concerns about the US power supply not being compatible but it turns out the adapter uses a USB cable which can be plugged straight into a PC.
Initial results were fairly good. The picture was significantly brighter with no washing out. This isn’t the easiest thing to make out in one of my photos but this can particularly be seen behind the lamp on the left with a larger amount of the background behind visible. Only one problem, it still wasn’t quite as bright as I was looking for even if set all the way to maximum. All that the Gamma-X is doing, is raising the RGB values of the signal so having come this far I figured there couldn’t be any good reason why I shouldn’t bolt in another one to boost it further.
Another trip to Ebay and more waiting for the postman and it does indeed work. The chain of cables under the desk is a little extreme but it’s a small price to pay for a usable CRT. It took me several months to get there but the picture is bright and vivid and I would hope that I’ll be using this for years to come.
I’d like to think when I write these posts that someone could eventually find some use out of them but the odds on anyone reading this being in the same situation seem extremely slim. If you do happen to have an Apple Studio Display around and are into DOS gaming, this is one way to get some use out of it at any rate. I’m not sure it’s something I’d recommend over a standard PC display otherwise. Given the extra expense and hassle, this was a gamble that didn’t entirely pay off in my case but I got where I wanted in the end.
The remaining fixes turned out to be something I could knock off in what was left of my lunch break. I tested it all last night, fixed a couple of other bugs I found and did a complete playthrough of the game. Having played through it, I changed my mind about the hit point reward when you leave a dungeon and put them back how it was. The game is definitely beatable anyway so I’m calling it done for now. I may revisit it at some point but I reckon I’ve achieved what I wanted when I set out. I’ll fix issues if anyone reports anything but right now I’m dubious as to whether anyone else will ever even play it. You can grab this latest version is at https://www.pixsoriginadventures.co.uk/Vecalabeth.rar as before.
Aside from a Vectrex, you’ll clearly need a Vectrex32 to run it which isn’t cheap and my port certainly isn’t worth that asking price on its own. It undoubtedly makes writing Vectrex games way, way easier than it would be otherwise so if you ever fancied creating a game of your own I’d certainly recommend picking one up. The BASIC variant it uses is still primitive but it’s no doubt a joyful experience compared to the alternative. I had quite a few issues with bugs when I first bought it but the updates since then have improved things no end. My overriding complaint is still the lack of emulation so that I have to load and run my code on real hardware all the time. Aside from the inconvenience, it seems like unnecessary wear and tear on an ever more valuable system. To compensate, I’ve been doing this oldschool and writing the code in a text editor (usually during my lunch) and then only running it when I’ve made decent progress. This isn’t how I prefer to code but it forces me into it.
If anyone does play Vecalabeth, please let me know how you get on. I think it’s a decent approximation of the original but I could do with some other opinions.
This version improves the flickering and more importantly fixes a good number of game-breaking bugs. I’ve played this one far enough to complete about half the quests on the easiest level without noticing any major problems. There are a few bugs I’m aware of which for my benefit as much as anyone else are:-
I still haven’t fixed invisible passages showing up from certain angles.
If you kill a carrion creeper the text goes off the screen
Monsters don’t attack you if you are stood on something (ladder/chest)
The menus are still a little fiddly – I may not do too much with these as it wasn’t really an issue when playing.
You will keep being told a quest is completed every time you kill the appropriate monster
Lucky number selection starts at 0 instead of 1
I went back and played the original Akalabeth again as a basis for comparison. There are clearly different versions of this as the usual Apple II version does not quite match the source code I’ve got or the code analysis. I was fairly certain I remembered it playing differently but it’s been years so I needed to go back and make sure. As such I’ve made some changes to make my version a bit more playable and bring it more in line with the later version:-
I’ve altered the dungeon generation to include empty blocks in the grid. Believe it or not, this would never happen with the original dungeon generator and it makes the dungeons much more open and playable. It is still possible in my latest version to not have paths through the dungeon but far less likely.
I’ve doubled the number of hit points awarded when exiting the dungeon. This feels much closer to the original to me and a whole lot fairer on the player.
On the earlier version, all the monsters for that level didn’t always spawn on each level. I’ve altered it so they are always on there somewhere. Best find a dead end to fight off the onslaught on those lower levels…
I’ve made traps about half as likely to be generated. They were a nightmare on the original version.
Another major difference in the later Akalabeth is the persistence of dungeon levels. i.e. they are the same when you go back. This didn’t happen on the original and I’m tempted to leave this alone on the Vectrex. I don’t have enough memory to store more than the one level at a time – I could try to save them to the cartridge but I’m going to leave as is at least for now. The random levels offer an easy way to compensate for potential dead ends if nothing else.
There are no doubt other little differences but this felt very close to playing the Akalabeth I remember at any rate. The current plan is to fix the bugs in the first list, play through the whole game to see if I can finish it and then if nothing else shows up, call it a beta and see if anyone else ever actually plays it. None of that will take too long so I should be done in the next few days.
Readers with good memories may recall that well over a year back I got hold of a Vectrex 32. This is effectively a mini computer on a cartridge that can be used to run BASIC programs on a Vectrex. My first thought was of course to port Akalabeth since all those line graphics are a perfect fit for a vector screen. Life soon got in the way and I managed all of about 3 brief sessions coding, much of which was spent learning the ropes. The ropes are now well and truly forgotten but it’s time this project got finished off so I intend to pick it up again until I at least have something playable. First, a look at where I actually got to.
Luckily, I never clear out my PC desktop and all the code is still sat there untouched since boxing day 2016. The last thing I was working on was the initial text/menus at the beginning of the game. You would imagine this would be quick and easy but placing text on the screen has to be done one line at a time with all the coordinates being set manually. It was a bit of a pain as I recall but I got further than I remembered with it. With no keyboard, the interface is going to be clunky but I’ve got all the text on screen for the shop and a currently broken means to select things to buy. I didn’t have any means to exit from this shop so I’ve added that in for the purposes of trying everything out.
In the time I did spend on this, I concentrated on the graphics since that is the fun part. The overhead world is pretty much all there. I’d created a random world builder for this based on the original code and can walk around it. I can’t go back into a shop or chat with Lord British as of yet. You can see where the idea for tile graphics in Ultima 1 might have come from in this section since it is effectively tile graphics in a 3×3 grid.
There was no means to enter a dungeon either as I’d just bypassed the dungeon code when adding the world map. I made some changes to fix this at which point things started breaking. A load of painful debugging later, I managed to figure it out (a shared variable name). This is the problem with picking up a project a year down the line especially in BASIC which I’m not used to. I am relearning my own code but you really need to have a clear picture of it in your head given just how unstructured the language is.
The dungeon is just a predefined array for now with one of each monster kicking around a load of corridors. The beauty of using vector graphics comes into play here as there is no actual 3D programming going on whatsoever. I simply have an array with scaling factors for each block in front of the player and a routine to draw any given object. I then apply the scaling factor when drawing the object to shrink the graphics by the appropriate amount to place it that many blocks away. The disadvantage of vector graphics comes in as well in that it can all get a bit flickery. As with the overhead map, all I can do is move around.
No doubt I’m forgetting something but my checklist to get a playable game is :-
Sort out dungeon generation.
Implement ladders, traps.
Get the player stats in place and inventory.
Get the monsters to move around and attack the player.
Implement combat.
Shops
Add in Lord British and the quests
The only job I’m not sure about how to tackle is the first one. I’m seriously tempted to bypass it altogether and just hardcode some levels.
Here’s a bit of video of Vecalabeth in action (and yes it really does buzz that much). The flickering is if anything worse in real life. It’s something I’m probably going to have to live with as the platform is even more limited than the Apple II was. I don’t reckon it’s looking too bad though. It moves faster than the original Apple II version ever did and is recognisably Akalabeth at the very least. Let’s see if I can make it actually playable over the next week.
