I've made some more progress on my Juno First game. The main change is the addition of a startup screen and the high-score table kernel from the last entry. I've also added SaveKey support, but it is commented out at the moment as I haven't been able to test it properly yet. I've left in the "Enter Name" screen, but in the final version this won't be shown unless a SaveKey is connected. The main game hasn't changed at all yet, except for the scoring which I have divided by 10 (it was too
It seems that nobody was impressed with my 16 character kernel last time - the main problem being the introduction of unnecessary flicker! I wasn't entirely happy with it myself, but I couldn't think of a better solution at the time. However, based on batari and Manuel's comments I decided to have another look at the no-flicker 13 char text demos. The 13+2 char demo uses a neat trick of rewriting NUSIZ during a scanline to squeeze in an extra two characters (in addition to using the ball a
I have written another text kernel which displays 16 characters. This may seem pointless, given my earlier 24-char and 28-char kernels, but it has several nice features:
Uses less ZP memory (46 bytes total).
Shows more lines on screen (14).
Text width is a power of 2 (for easy calculations).
Kernel has loads of free cycles (around 40 per scanline), e.g. could have a PF image underneath.
The main reason for writing this kernel is to allow the Juno First score table to be
I have done a lot of work on the Juno First levels today. The aliens should spawn further apart (to reduce flicker) and they shouldn't appear directly in front of your ship any more (most of the time). I have also expanded the game to 16 levels, and I will be amazed if anyone can complete them all! Let me know what you think of these levels. In particular, are they too repetitive or too difficult? I haven't made any other alterations to the game yet - the changes discussed in the pre
I have done some more work on my Juno First game recently. The game code has now grown rather large, and it is becoming increasingly difficult to make changes without causing breakage or exceeding the scanline counts. Also, I'm now into the tedious last 5% of the implementation, which involves tying up all the loose ends and adding polish. However, I'm determined to finish the game this year without getting distracted by any other shinier projects!
The main change in this version
When I first heard about the AtariVox I wasn't too impressed with the sound quality, and decided not to bother getting one. However, I changed my mind after seeing a demo of Man Goes Down at the vgXpo a few years ago. I realised that the sound quality was a perfect match for the Atari, being broadly equivalent to the quality of speech chips back in the day. I now think it would sound "wrong" if the Atari were to produce high-quality speech, just as it would sound unnatural if Stephen Hawki
OK, here is a small update to Juno First. The main change is the addition of sound effects to the game. I initially tried to approximate the arcade effects, but eventually gave up and just went for effects that sounded reasonable. Let me know if they sound OK, and if the background hum is too annoying (I don't want a repeat of Hunchy 2!). I haven't added all the effects yet - I'm still trying to find a reasonable explosion sound for the aliens, and a few other spot effects. This versio
I've now integrated the Juno title screen and main game together into a 32K ROM (see attached). There isn't anything really new here, but I have sorted some long-standing issues in the code. In particular, the scanline count should now be stable at 262 in the main game - let me know if you see any screen jumps (except between the title screen and game).
The main things left to do now are:
Add a lot of levels.
In-game sound effects.
SaveKey support.
Tune the gameplay and
OK, I'm leaving my text kernels alone for the time being and attempting to get back to coding Juno First. I have attached a minor update to the Juno First title screen code. It doesn't contain anything new, but it integrates together various features that have previously been discussed separately here:
Contains the awesome Silkworm tune by moderntimes99.
Displays the score table in white (rather than striped).
Alternates between logo screen and high score table.
My plan is
I'm still having fun writing text kernels. The latest version (attached) is an update to my 28char kernel to display multiple lines of text. This new kernel shows a 28x12 display without any restrictions. The kernel doesn't use any illegal opcodes, and there are still around 30 free cycles per-line, so it should be possible to display a few more lines of text with some work. Unfortunately, as before it has a 20Hz flicker, so it is essential to use the phosphor options under emulation. I
I finally understand how supercats 26-character text kernel works (I think)! As a result, I have written my own version which displays 28 characters on a line. Unfortunately I could only do this by flickering at 20Hz and using a 6-pixel high font, so it doesn't look all that good. However, I think this is the first ever 28-character kernel on the 2600? It only displays one line of text at the moment, but it should be possible to display 12 or 13 lines using the same techniques as my prev
I decided to experiment again with my textkernel to see if copying the text into zero page memory would be useful. The advantage of using zero page RAM to hold the text is that it removes the need for the text to be in the same bank as the display kernel. The text can be loaded into RAM in one bank and then displayed by bank-switching into the display kernel. Another practical advantage is that it becomes possible to create text dynamically in RAM without the need for the text to be fixed
I've done a little more work on my text kernel. It still displays only 12 lines of text, but the code is cleaner and it now shows lower-case letters and numbers (the text is from "The Hunchback of Notre Dame"):
I can get this up to 14 lines by overlapping the buffer creation code with the display code (there are lots of free cycles in the kernel). The problem is that this requires four versions of the copying and kernel code, which takes up nearly the whole 4K and leaves very little
It has been nearly a year since I updated this blog, and just about as long since I did any Atari programming. However, things are a bit quieter for me at the moment and I decided to write a text kernel as a way to refresh my 6507 programming knowledge. My first attempt is attached to this message and is an extension of the Juno First title screen technique in my previous blog entry. The screen-shot below shows the results - I have managed to get 12 lines of nearly flicker-free text (24-c
This is just a quick update on my Juno First project. I have now created the title screen, thanks to some more amazing artwork by Nathan. I was aiming to reproduce the look of the Arcade title screen as far as possible, and I think I have managed to do a reasonable job given the limitations of the 2600 (arcade shot on the right ):
The logo is 96-pixels wide and is created using the Homestar/Ruby Runner flickering trick. It is necessary to use the Phosphor option in the emulators
It has been some time since I last posted an update on my Juno First game. The project has been on hold for a while, but it has not been abandoned completely. One of the reasons that it stalled is because I wasn't completely happy with the kernel. My aim for the game was to have full colour sprites that are updated on every line (1LK). This should make the game visually superior to similar games (such as Beamrider), but it is quite a challenge to achieve!
I managed to get the kernel
Well, it has been 5 months since my last blog entry! A lot has happened to me in this time, including finishing a book, getting engaged, moving house, and changing jobs. Most of these have been good things, and I will try to write about them in more detail in the future. However, it has all left me with very little time to do any Atari programming. I started the year with big ideas (i.e. PoP) and planned to enter the 8K minigame competition (with Juno First), but this has not been possib
It appears that my Java port of the Krokodile Commander software generated almost no interest at all I guess all the people who were previously asking for a Java version on the forums were actually just wanting a Mac OS X version. Nonetheless, I have done some more work on the Java version to add multicart support, and increase the transfer speed. The new version is attached to this entry, and the documentation is contained in a README file inside the zip. It is still a command-line ap
Last week I received a shiny new Krokodile Cartridge (KC) in the mail. I had been on the waiting list for some time, so it was great to finally get hold of one. It came at a good time, as I needed some way to test my Juno First game on real Atari hardware since exceeding the limits of my Supercharger (SC). In addition to permitting binaries over 4K, the KC has a number of other advantages over the SC: it doesn't require the weird audio setup that I was using to transfer game images, it ha
I haven't been very active on the AA site recently. This is not because I have lost interest - it is just that I have been travelling around the globe recently as part of my work. I have just returned from Japan, and I though I would write a little bit about it here. I won't bore you with the work side of things, instead I want to write about the three days that I had to myself in Tokyo.
This was my first trip to Japan, and I wasn't sure what to expect. The country has a kind of myth
Here is another quick progress update on my Juno First game. I have now implemented the missiles, which were the final missing feature in the game. Up to 8 missiles can be shown simultaneously on screen (using flicker). There is still a bit of tearing when the missiles pass over the grid lines, but I hope this isn't too noticable. The missile firing patterns are rather boring, but I will improve this later. I was originally planning to use one of the missile sprites for regular missile
I am often struck by the similarity between the activities of game playing and game creation. In both cases, there is generally a long sequence of problems to be solved with an eventual goal in mind. These problems can have complex dependencies, and finding a good solution can make the difference between reaching the goal and starting over. As I have previously noted, I actually gain more enjoyment from creating games than I do from playing them. According to some friends of mine in the
I spent the weekend working on my Juno First game, so here is another update. The main changes this time are:
There is now an explosion animation for the aliens, and some of the sprites are animated at their largest size.
The alien spawning code is in place, so the aliens appear one by one at the beginning.
The length of the laser beam shortens as it goes up the screen (I know I said this wouldn't be possible )
There is now a basic 6-digit score at the bottom of the screen.
This is just a quick update on my Juno First game. I hope people don't mind me using this blog as a beta testing area. However, I find it useful to post these development versions as the folks here are quick to spot bugs and problems that I might not notice otherwise. The previous versions had a number of serious bugs, but I hope that most of these have now been resolved. The main features this time are:
All 20 possible sprites are now displayed on screen. This causes some serious fl
The Atari 2600 is a difficult machine to program, but the 6502 assembly language in which this programming is done is relatively easy to understand. Nonetheless, there are certain features of this language that I still don't completely understand. One of these is the indexed indirect mode that I taked about in a previous entry, but this is not a particularly useful feature. The other issue for me is two's complement binary arithmetic which I view as a necessary evil. Two's complement is