GID 23 took place a few weeks ago on the 11th/12th of August.

It all began at approximately 11:01.34pm Saturday night, with nearly half of GID#23 already gone and yet I still had no idea what to do. Tom suggested I team up with him to do something similar to the original Teaminator.

We had no idea what the game was going to be about only that it had to involve Tea. A large part of the core code was already in place from previous GID’s Tom had done, which left us free to concentrate on more game specific issues.

The result by the end of Sunday was larger than expected and shows clear signs of the games and tv show we drew inspiration from; Monkey Island, Dizzy and Open All Hours.

I finally got around to playing Treasure Island Dizzy the other night, which I used to have for the C128 (or was it the Amiga, I forget which). It’s strange going back and playing games which I played many years ago. Some games I remember as amazing, and yet on playing them again all the fond memories of how good the game was, which you’ve over the years raised onto a pedestal of “how games should be”, comes crashing down as you suddenly realize you’ve built the game up to be more than it really was. Fortunately that isn’t the case with Dizzy nor Monkey Island (which I’m also part way through replaying)

I had forgotten just how HARD older games really are. Most games these days you can pickup and play for some time before you die, try playing Dizzy for more than a minute without dieing several times!

The GID did highlight a few areas of the Engine which could do with improvements, which has resulted in a complete overhaul of the dialogue system to now use a node based tree structure. This enables dialogue to be constructed through a parent/child relationship of dialogue and dialogueItem nodes.

Special purpose nodes can also be inserted into the tree allowing actions to be performed on the display of specific dialogue or the selection of a dialogue option. New node types will be added in the future to support a variety of actions, for example, enabling a quest, playing an animation or transitioning the camera. A general purpose callback node functions as a stop gap until new node types are available.

The Quest system has also seen a significant improvement along with the addition of an NPC Editor

Brew Isles can be download via the GreatGamesExperiment.

Having only had a few hours Sunday night to work on the last part of the code I wasn’t expecting to actually reach my goal of a pixel on the screen. In the end though, I managed to get a square block drawn in the center of the screen synced well enough to show flicker free on both my TV and Digital TV card in the PC.

The actual TV picture is a nice vibrant yellow, the screen capture doesn’t do it justice looking a little washed out. Oh, that reminds me, the colour burst wasn’t that hard afterall, just a case of making sure the colour is set in the upper 4 bits and the luma in the lower 4

Adding in the VSync and overscan code wasn’t that difficult, the hard part was counting all the clock cycles to make sure they met the timing requirements. In fact the most trouble was with the comparison loop where I check whether the scanline is within the block and needs to be drawn in colour. This results in 3 possible code paths all of which had to have exactly the same number of cycles before reaching the final DEALY(174-3) instruction. A little fudging goes a long way though

The theme for this GID was “Extreme Forces” well the forces exerted on my TV by all the badly formed signals I sent throughout Saturday were pretty extreme, does that count?

For those that care the source code is rar’d up and available for download. Although it works fine on my TV that doesn’t mean the code is correct so I’d love to hear back from any of the more experienced XGS users if you can see any obvious flaws. The final code weighed in at roughly 374 bytes (don’t quote me on that ) After looking at a few other peoples delay macros I can see a saving of several bytes there alone, so I’m sure this code can be optimised significantly, maybe another day

Check out the rest of this entry if you want to see the final code

Read the rest of this entry »

Having nailed the delay code I’ve spent most of the evening reading up on the SX52 memory architecture and the PAL timing signal. To start with I’ve created the signal needed for each scanline (see previous blog with timing diagram)

The first attempt didn’t go too well

It was only a few minutes though before I realise my timing was out by a few clock cycles. The reason? Well in order to generate say the SYNC pulse 0.0V on RE port for 4.7µs we need to delay for 4.7µs*1000/12.5ns = 376 clock cycles, so I did the following

[ASM]
mov RE, VID_SYNC
DELAY(376)
[/ASM]

The problem though is that really we’ve taken up 378 clock cycles and thus the code is executing for 25ns longer than we need it to. Couple this with all the other mov/delay statements for the other parts of the signal and we end up many cycles out of sync. The solution is simple, a mov takes 1 cycle or in the case of a compound mov (which this is) 2 cycles, so we just reduce the delay by 2 cycles to give

[ASM]
mov RE, VID_SYNC ; 2
DELAY(376-2) ; 376-2
[/ASM]

The result is a lot more promising, using VID_WHITE (1.0v) for the output port RE gives us a nice white screen, however we’re not finished yet, since there is not handling of the vertical sync yet.

So thats as far as I managed to get by the end of Saturday. I expected to have a good few hours sunday to work on getting the vsync sorted and plotting a specific pixel, but plans change. If I’m lucky I’ll squeeze in a few more hours tonight and hopefully finish things off.

GID j posts - first entry

As mentioned in the last blog entry, timing is cricical down to the cycle. In order to make sure all branches of code execute in the exact same amount of time I’ve created a delay macro. This isn’t an optimal method, I’m sure there are ways to reduce the number of bytes this uses however it does the job.. at least it does after a little debugging.

After coding up the above I programmed it into the SX52 and put the SXkey into debug mode which allows you to single step the processor one instruction at a time and view the programs memory/registers and flags. Using various delays of 1, 7, 10, 14 etc I noticed the NOP repeat was only generating a single nop rather than the expected number, this turned out to be because missed the ending ENDR directive

[ASM]
;
; DELAY for a specified number of clock cycles
; EXPECTS:
; “counter” 1 byte variable defined
DELAY MACRO clocks
; eat up clock cycles 10 at a time
IF ( (clocks / 10) > 0)
mov counter, #(clocks / 10) ; 2
:loop
jmp $ + 1 ; 3 jmp to next instruction
jmp $ + 1 ; 3 jmp to next instruction
djnz counter, :loop ; 2/4 (4 if <> zero)
; 10 cycles per loop, 8 for last loop
ENDIF

; handle remaining delay 1-9 using nops
IF ( (clocks // 10) > 0)
REPT (clocks // 10)
NOP ; 1
ENDR
ENDIF
ENDM
[/ASM]

The following screenshot (click for a larger view) shows the debugger running the DELAY(14) code and circled in red the lone NOP instruction. A simple mistake putting an extra slash but one which would if not caught render the video output useless. Glad I caught it early, otherwise I might have wasted hours debugging my video code.

With the delay loop out of the way, its time to final make a start on generating accurate h/v signals. Hopefully by the end of tonight

GID j posts - first entry

Satuday 2pm and I’m a little closer to understanding how to plot a pixel, although only a little. The first attempt to generate a video signal resulted in, well see for yourself, detune a tv channel and look at the white snow, thats pretty close to what I’m looking at right now

The reason been, I’ve not setup any kind of timing for generating the video signal yet but I know that at least I’m outputting to the correct port to generate “a” signal. After a little digging through the XGS docs I’ve got the information on the PAL signal specs, the main bits of interest are:

• Front Porch 1.5µs
• Active Video 53.1µs
• Sync 0V
• Black 0.3V
• White 1.0V

Based on this we can calculate the number of pixels a PAL tv can cope with (@5.5Mhz), we can change the signal at a rate of 1/5.5Mhz = 182ns which gives us 53.1µs / 182ns = 292 pixels per scanline (best case; although I think my tv will do 720 due to extra bandwidth, but we’ll go for a conservative value)

So in order to get a pixel (assuming no colour) on the screen I need to generate a video signal to display 312 scanlines each comprised of at most 292 pixels. Heres the full scanline signal needed for a PAL system. (I’m ignoring colour burst for now; image obtained from Haagans website)

Once the horizontal signal is up and running the vertical signal should be a snap, its nothing more than another timing signal, so we’ll be sending a H Sync signal for each line followed by 4-10 lines of vsync. I’m keeping this simple and going for 274 lines at 50Hz (50 frames per second) with 16 blank lines top/bottom to account for tv variations and the 6 lines of vsync giving a total of 312 lines.

The key to this is the timing, with the SX52 processor that the XGS uses running at 80Mhz, 1 clock cycle = 12.5ns we need to ensure that the number of cycles used to generate the signal matches the above timing diagram.

There is a whole lot more to the signal generation than the overview above, if you’re really interested in the details either get the XGS and read the book (which in addition covers designing and building the actual video hardware) or google it.

So the plan for the larger part of today is to get a suitable delay macro up and running and outputting the appropriate voltages to generate a stable H/V signal. Initially using a fixed value for each pixel (we’ll get to plotting a single specific pixel later.. for now its a screen fill) Fingers crossed that is.

Its that time of the month again, we’re now on GID j, for a change I thought I’d code something for the XGS. I sense this GID is going to be rather painful just setting things up ready for tomorrows start brought problems.

Lesson1: When routing the video/audio output through your digital tv card and you only get black and white check the Crystal. I’d forgot that the last time I used the XGS I’d hooked it up to my TV which supports PAL or NTSC and had been playing around with some of the NTSC only demos. I’d left the 3.57Mhz crystal in the XGS rather than the 4.43Mhz crystal needed for PAL output.

Lesson2: Prepare for things to only get worse from here on in. This little voice keeps telling me this is a bad idea. Trying to learn the details of programming a chip such as the SX52 and assosiated hardware is bad enough, but considering how rusty my asm skills are we’re in for a bumpy ride.

The chances of a successful GID appear to be slim to say the least, so I’m lowering my expectation (and I mean reeeealy lowering) and instead doing a PID; pixel in a day (if you hadn’t already guessed ). In other words, if I manage to get a pixel up on the screen within the time constraints of this GID I’ll be happy, anything beyond that is a bonus. On a good note I’ve already written code to handle interfacing with the joystick port (see previous blog) so if we can get a pixel up, maybe we can get it moving, perhaps even a several pixels

Hey with 4k of direct memory who knows we may even get as far as displaying a sprite, maybe two but lets not get too carried away.

Anyhow the XGS is rigged up with video/audio routed through my pc to make for easier screen grabs (erm that is assuming we get as far as displaying anything, otherwise you’re in for some code dumps instead ) so, for what remains of Friday night and a few hours of Saturday morning I’m going to hit the SX Programming manuals and read over the XGS hardware specs.

I think this first calls for a fresh cuppa.

Sat - 00:24

I’ve finally settled on an idea, the rest were interesting, but would have taken way too long to get even the basics going. So heres the plan, as to how much I’ll manage to get done of this in 24 hours I’ve no idea.

Ghost Hunter - A 2d top down view game. The game will take place within a haunted house (although you’ll have to take my word for that since I’ll be using programmer art :P) teaming with ghosts (again unless a kind artist donates some graphics, take my word for it).

The player has two weapons, the first is a limited ammo scare gun. It will fire a projectile that will cause ghosts to panic and run away from it (may change into a stun gun or some other variation depending on how the game plays assuming I get that far).

The second is a short range trap that can be dropped and will suck nearby ghosts into it. The trap will hold a limited number of ghosts requiring a trip back to the ghost hunters van. Emptying the trap will score the player points.

The player will lose health should he come into physical contact with a ghost.

So thats the basic plan. Whether it will end up anything like the above remains to be seen.

Read the rest of this entry »

The last GID I entered was GID#12 for which I coded Conquest. In little over 6 hours it’ll be time for another GID#14, this time the theme is ghosts, and I’m still pretty stumped for ideas. There’s the obvious pacman clone, but I’ve been there, done that. The rest of the ideas I’ve had are really too big for a GID. I’m sure I’ll think of something though

Anyhow, I’ll keep this blog entry updated as things progress.

Following a comment about GID selling GID t-shirts to buy cakes and tea for the first Live GID (still hoping they’ll be one the discussion moved onto Tea T-Shirts, well here’s my Tea-Shirt in a day entry

It’s now midnight Saturday, I’ve still not decided on a GID idea, although I’m fairly certain I’ll be using T2D for it. Its been a couple of months since I last had a chance to play around with T2D, in fact I think it was GID#12. Time for a cuppa, then hopefully I’ll have a moment of inspiration and decide on an idea.

Move GID#14 to a seperate blog post.

Saturday 7th May marked the start of GID#12 which I’ve been looking forward to all week. Unfortunately I was out all saturday night and by the time I crawled out of bed sunday, it was already around 12pm. Since hearing about GID I’ve managed to miss every event and was determined not to miss this one, even if I only had 12 hours of sunday left to GID in.

The theme was augmentation, although after about 5 minutes thought I decided I didn’t have time to think of a game that would fit the theme. I’ve wanted to create a turn based strategy game for some time, so I decided to prototype a greatly simplified version. If any of you have every played Konquest that ships with KDE, you’ll have a good idea of what my aim was At a pinch you could say that your augmenting the neutral planets with your fleets

Read the rest of this entry »