Category Archives: Uncategorized

Protovision, Cartridges and a Village!

So many things have happened since the last update! First of all, I am proud to be now a member of Protovision! This solved a couple of questions that were bugging me regarding the publishing of ToS2 on physical media: e.g. how to deal with the German FSK or or US MPAA or whatever legal age restrictions are relevant for computer games in all the countries around the world that ToS2 might be delivered to. Also, how to deal with payment and delivery for international customers etc. So I was pretty happy when Jakob from Protovision contacted me about joining them!

Now, the really cool thing is, that Protovision is ramping up on a new game cartridge developed with Individual Computers. The fantastic Sam’s Journey developed by Knights of Bytes will be released on this cartridge and I was able to get my hands on a test cartridge (unfortunately without a Sam’s Journey pre-release though). So I started integrating it into my development work flow and am happy to say, that I am really confident that there will be a cartridge version of ToS2! I would love to provide a disk version in addition, because I am a huge fan of good ol’ 5,25″ floppy disks, so potentially ToS2 will be released on both. Let’s see… In the course of working with the cartridge I also had the chance to chat quite a bit with Chester Kollschen from Knight of Bytes, which was a most interesting information exchange by itself!

This all means that I spent quite some time with the cartridge and with writing tools to make it work with the current development version of ToS2. Nevertheless I did some more work on the game itself. I am still in the process of finalizing the implementation of the new, highly memory efficient data structures for the game. But in order to learn efficient working with the editor I did a draft for a new level. Despite the general gloomy mood of the game, there will be a couple of light and friendly moments, too. One of them will take place in a scenic German village with pretty half timbered houses. I am currently really unhappy with the trees, so expect some changes there (and probably elsewhere, too). But without further ado, here comes a first screenshot of a ToS2 level!

 

Milestones and Kanban

In the last month I was able to finish version 1.0 of my game data editor “TOSEdit”. This is the first actually useful version, because it can create tiles, charsets and maps and export them in the same binary format as the wonderful CharPad. This will be the base for the further required features, that are needed to support the more special properties of the TOS2 C64 engine (like e.g. swapping parts of the charset on the fly). Interestingly, the implementation of the editing itself went pretty quickly (did I already mention that I love Java?). But what really needed time was a reasonable implementation of cut, copy and paste and of undo. I never implemented an undo mechanism before and it is actually quite a challenge. You need to do it completely for all actions that change the underlying data somehow, or it will fail miserably. Well, I was able to finish it and thought that this is worth a “release”. Where release in this context only means that I give it the satisfying version number 1.0 and write a blog post about it!

tosedit_1-0

I think working towards milestones and releases is so much more satisfying! When starting the work on the editor I decided to even go one step further and apply some agile methods to plan and track my progress. As I am the only person working on the project, Kanban seemed a reasonable method and what can I say: I love it! Kanban is a simple way to organize tasks (or rather “stories”, which are features that are needed, described from a stakeholder point of view). In my specific case there are 4 columns with such stories, a “Backlog” of things that I want to do at some time in the future, but did not think enough about that I could immediately start work on. After I spent enough thoughts about it, the story is moved to the “Selected for Development” column. When I actually start working on it, it gets moved to “In Progress” and when I finally finish it, it gets moved to “Done”. There is one specific rule that is typical in Kanban, which is that you limit the number of stories that can be in a certain column. In my case I decided to say that I never want more than 3 stories in progress. This helps to focus and get things done instead of being distracted too much.  I am using the wonderful Atlassian Jira (which is free for small projects and nicely combines agile methods with bug tracking) and below is a snapshot of my Kanban board, filtered for the TOSEdit 1.0 release. You can see that there is only one issue left (which is writing this blog entry), which I will move now to the “Done” column. Really satisfying!

kanban

The Editor

Wow, no posts for such a long time! Well, it is summer and I have to admit that I did a bit of a break from my PC while the weather was so nice. But did I take a break from the project? No! I spent a bit of time thinking about concepts, I fought a bit with infrastructure (and actually had to change the provider of my development VServer, well you get what you pay for), and I even spent some time with scissors, paper and glue and created some prototypes for a nice packaging. Googling the Internet for creating cardboard boxes is an, um, interesting experience. Apparently only kitsch fanatic house wifes seem to care for this normally. But who says I am normal :-)! The results of all this work are nothing exciting to show off, but were important to work on at some point (at least for me, as I am a bit fanatic about the overall experience of a product). On the code side I did lots of clean-up and integrated the task scheduler and the font swapping module I wrote about further down. I wrote many many unit tests, so I am of good hope that the game will be much less bug-ridden than the compo version.

What I did this weekend was maybe more exciting: I finally started work on the game editor. With all the new features of the game engine, standard tools are just not flexible enough to work with. So here comes a screen shot of the first editor version! A lot is still missing, but I feel I am on a good way:

tosedit It is really heavily inspired by the fantastic CharPad, I hope the creator does not see this as a plagiat, but rather a tribute to his great software! Especially the font swapping needs a lot of intelligence in the software.

Apologies once more for the delayed update! I expect them to happen more frequently now that the weather is getting more favorable for dwelling in my computer cave…

Tasks, schedules and priorities (2)

Apparently I was creating more questions than answering them in my last post. I will try to provide a bit more detail about the implementation of the task scheduler.

interrupt-3

The interrupt routine decides, if it wants to schedule a new task. If the new task has a higher priority than the one that is currently running, we want to switch to the new task. So what we need to make sure is, that when we return from the interrupt we do not return to the old task, but to the new one. In order to achieve this, we need to manipulate the stack accordingly, as the return address (and some more information) is stored there. Let’s look at what happens when an interrupt is triggered:

  1. the currently executed instruction is finished
  2. the current program counter is pushed onto the stack, high byte first
  3. the status register is pushed onto the stack
  4. the interrupt flag is set (because you usually would not want your interrupt routine to be interrupted itself)

All these steps are performed by the hardware itself. An interrupt service routine normally saves the registers in software in addition:

  1. A is pushed onto the stack
  2. X is pushed onto the stack
  3. Y is pushed onto the stack

How can we manipulate the stack now to return to a different task? We simply push respective data onto the stack!

    lda #>task
    pha          ; push >task
    lda #<task
    pha          ; push <task
    lda #0
    pha          ; push arbitrary states, IRQ flag must be clear
    pha          ; push arbitrary A
    pha          ; push arbitrary X
    pha          ; push arbitrary Y

When the end of the interrupt service routine is reached, it will restore Y, X and A and the final rti will pop the state register and jump to the new address we just pushed onto the stack! We do not have reasonable values for the registers (as the task was never executed before), so we simply chose 0. There is one caveat regarding the state register: we need to make sure that the interrupt flag is clear, or the interrupt will never be called again. It took me a while to realize this, as I was happily using php to push the current state register instead and as can be seen from step 4 above, that had the interrupt flag set.

Now let’s have a look at the task_done routine that is jumped to by a task when it is finished. In theory, all we need to do is to jump to the task with the next highest priority. Let’s for now assume, that the old task has the next highest priority. Things get slightly messy now: we still have the remains of the interrupt on the stack, but tasks are always executed in the main loop! So instead of jumping to the new task with jmp, we will misuse rti and simply do the same as we would do at the end of an interrupt routine:

    pla
    tay
    pla
    tax
    pla
    rti

Et voilá: we restore all registers and are back in the old task!

There is one additional thing that needs to be organized: when a task is added with a lower priority than the currently executed one, it needs to be stored for later. To do this, a list with upcoming tasks needs to be kept. Every time a task is done, the list needs to be searched for the next highest priority and the task needs to be pushed onto the stack as described above. But I am going to leave this little detail to be worked out by the reader (ha, I always wanted to say this cruel sentence at some point in my life)!

Tasks, schedules and priorities

Here we are with another rather technical update! Last time I was posting some information about how I want to get more diversity into the game graphics by switching parts of the character set on the fly while the player moves through the world. That actually raised an interesting new problem: how to handle tasks with different priorities!

Up to now there were only two possible priorities: tasks that need to be done during the currently displayed frame (like color RAM scrolling or inserting new characters at the border of the screen) and tasks that only need to be finished eventually during the next frames (like scrolling the currently invisible double buffer or checking for trigger areas for events). The character set swapping adds another priority: in theory it can take quite long and there is no need to have it finished in the next 2-3 frames, it is ok even if it takes e.g. 10 frames or so. Instead of patching this into the existing engine I decided to do it right from the start and be prepared for any upcoming additional tasks.  Which means: implement a task scheduler!

clocks-1098080_640

What does a task scheduler do? It makes sure, that most of the processor time is spent on the tasks with the highest priority. I simplified the concept a bit, so that higher priority tasks are always finished before lower priority tasks are continued. The implementation is actually simple, although there is some mean stack fiddling involved and it needed a bit of head scratching until I got it right. The interface of the scheduler module has only two routines: task_add, which adds a new task with a given priority and might switch to it immediately (if it is the highest priority), and task_done, which is called by a task when it is done and selects the next highest priority task to be executed.  All that is needed is to modify the stack such, that the RTI instruction at the end of the interrupt routine jumps to the right task. Apologies for the clumsy block diagram trying to depict this with an example. Did I mention that I am not a graphician?

In any case: implementation is done and unit tests are passing (yay!), so I am looking forward to put this new module into good use!

Gold plated tests and breaking the 256 character limit

Last time I was talking a bit about the test framework I am setting up. I actually became a bit obsessive with this in the last weeks and spent a lot of effort to get it to a point where it fulfils everything I need. Meanwhile I am at a point where tests are run every time something is submitted to the version control system. The result can be nicely seen on a html page and a history of the last 20 tests is visible. Log files for passed and failed tests are stored and can be accessed from the html page. All in an eye pleasant view, slightly  heavily inspired by a professional commercial CI system (is anyone able to guess which one? Write it into the comments and you will get personalized kudos in the next update :-)).

ci

From the screen shot above you can guess that I have some unit tests running meanwhile. I decided to run the Vice emulator using a virtual display, because that allows me to run it on my headless server and still store screenshots in case something unexpected happens. This proves to be pretty important, as my tests rely on a Vice break point to be triggered. If this does not happen for some reason (e.g. if I messed up the code and it does totally different things from what I actually intended), the test system will grab a screen shot and kill Vice after a time out. That makes it easier for me to guess what went wrong.

But I did more than gold plating my CI system: I finally started implementing the much more advanced idea I had for increasing the char mode flexibility. The idea is to assemble the current charset arbitrarily out of different char set parts. For any rectangular area on the maps, the combination of charset parts can be changed. This is done in the background, so the player does not notice it. Obviously that does not help against the limitation of 256 character visible on the screen at the same time. But as soon as a couple of characters are not visible anymore, other characters can be swapped in. This is hard to handle during level design, but I think it should be doable to optimize the charset parts automatically in the level editor. Ideally, I could simply design the levels mostly arbitrarily, and the editor will take care for the rest. Let’s see how it works out…

Still alive!

Wow, that is a long time since my last post! Well, I had a lot to do in my daily job and all my other hobbies demanded some well-deserved time. But here I am back in front of my PC and typing away. The project is surely not dead, it just needed a bit of a break to go back to full speed again. There was a bit of a setback with the anticipated help for the graphics, so currently the team consists more or less of one person again. Nothing to worry about though, as there is no time pressure! That’s the nice thing about hobby projects…

I picked it up where I left it and finally finished the mechanism for continuous integration testing. “Continuous wha…?” I hear you say. Well, it is a buzz word for automated testing triggered by any kind of change. There are really really advanced tools to do all this kind of stuff, but I felt that they are waaaay too much overkill for my use. So I quickly setup my own system, that is really really simple. There is a daemon running on the server that watches for submits in the versioning system. As soon as something has changed, it will start a script on the server, that will get the latest version of the software and search for subfolders in a dedicated test folder.  Each of these folders contains a script, that can generally do any kind of test and will output the result on a web page. Passing and failing is signaled by a colored flag, so it is easy to see if something got broken. Additionally the test script itself and all kinds of error outputs are accessible from the web page, to easily identify a problem, when the test fails.

Up to now, the only test builds the disk image for the game, so a build buster can be easily identified. Not so impressive, as this can easily be checked locally on the machine where I do my development. But this is the basis to do much more advanced things. I am planning to run a C64 emulator and perform all kinds of tests in that, e.g. do a speed-run through the game to see, if it is still possible to finish it! I did this manually countless times for the original “Time of Silence” and it really, really sucked big time. You begin to hate a game, when you play it through for the hundred-fiftieth time, and this is definitely not a good prerequisite for coming up with ideas for improvements. So this is something that I will definitely avoid this time.

compiling

The infrastructure is now practically complete, so there is no excuse for not ramping up on the game itself again! Well, there is also the level editor, let’s see where I am going to concentrate on next…