Internal Retro-Brighting

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.

Vecalabeth – Beta

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 http://62.210.205.110/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.

Vecalabeth Alpha – Version 2

I uploaded a new version of Vecalabeth yesterday (http://62.210.205.110/Vecalabeth.rar) with some bug fixes and gameplay tweaks.

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.

Vecalabeth – Resurrection

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.

1

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.

3

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.

2

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.

Announcing Vecalabeth

I’ve been something of a fan of the Vectrex console ever since getting hold of one a few years back. The Vectrex was unique in the history of games consoles as it came with a built-in vector monitor. The pin sharp, glowing line graphics this produces are completely unlike the raster graphics we are all used to and give the console a timeless quality as far as I’m concerned. I’ve always fancied having a go at programming on one but never built up enough courage to take the plunge into the assembly coding that would be required. Thanks to a newly released cartridge, (the Vectrex32), I no longer need to.

img_20161016_183343

The Vectrex32 plugs into the Vectrex like any other cartridge. The difference is that it’s a 32 bit computer in its own right that takes over all the processing duties of the console. This means programs can now be written in BASIC instead of assembly and it vastly increases the processing power available. In addition, the cartridge can interface with terminal software on the PC via USB for easy debugging and copying the basic code over in the first place. Having spent a few hours playing around with it, it’s quite a neat system and it didn’t take long to get my first code up and running. I am finding that I need to stop each program running entirely before copying over my new version of the code every time otherwise I got file corruption trouble. This is slightly tiresome but not a major deal now I figured it out. The other snag with the Vectrex32 is that I need the real hardware to be able to try to run my code. I’d really hate to wear out my Vectrex and would prefer an emulator option in the long run.

Hopefully, the option to code in a high level language will produce a flood of new Vectrex games. I’m going to be giving it a go at least and the project I’m tackling is a reasonably faithful port of Akalabeth onto the platform all those line graphics were clearly meant for in the first place. How successful this will be is yet to be seen as there are still hardware limitations to deal with (mainly the number of lines and buttons). I thought I’d deal with the most difficult and interesting stuff first. I’ve built a single level 9×9 maze array to give me something to work with and set about getting the movement and graphics in place to wander around the level. This has proved considerably easier than I expected actually. You basically draw what’s on the left, middle, and right directly in front of the player, then scale it down a little and repeat, and just keep going scaling it down a little more for each grid of the map. No maths skills or understanding of 3D were needed whatsoever which is probably just as well.

Something you don’t realise about the Vectrex until you start programming on it, is that the lines are all effectively drawn with a virtual pen that you have to move around the screen in the code. This pen drifts a little with each move meaning that your lines don’t necessarily meet up despite having the same coordinates. I keep having to reset my pointer to the middle of the screen and draw things in chunks to get around this.

I only started this weekend and have got as far as being able to walk around the maze, go through doors and have drawn the graphics for a couple of monsters. The Vectrex can only really handle one monster at a time reliably or the cartridges 2K buffer runs out of space + the screen starts flickering with the pen not being able to keep up. This means the monsters in this version will be able to hide behind each other. I reckon with chests, trap doors, ladders, etc. they are much simpler graphics and it will be OK to show all of them at once.

I considered porting the code from the original Akalabeth since it was also written in BASIC but the two variants on BASIC looked far too different for this to be worthwhile. Instead, I’ve written everything from scratch so far other than borrowing the monster drawing code. Even this is quite different but I can still extract the coordinate numbers and scale them down a little to suit my needs. I may borrow some more of that code in the long run for maze generation and the like but I’m nowhere near that point yet. The next stage will be to finish implementing the graphics for all the different monsters and objects, then I’ll have a go at putting some actual gameplay in.

I’ll release the source code once there is something worthwhile to share. In the meanwhile, here’s a few screenshots of what it looks like so far, including a close up of the fearsome balron. You’ll never be able to get quite that close to it when I’m done as you shouldn’t really be able to occupy the same square.

img_20161016_183951 img_20161016_184031

img_20161016_184012