Search the Community
Showing results for tags 'Atari Programming'.
-
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 Hawking were to upgrade his speech unit. I bought an AtariVox when they became available again (in the new casing), but didn't actually use it until today. The main reason being that my Atari gear has been in storage since I last moved, and I'm about to move again. I was able to use the AtariVox now due to the acquisition of the handy AtariVox USB adapter, pictured below: The USB adapter enables the AtariVox to be used from a normal PC, without the need for an Atari console. This might seem rather pointless, but the main reason for using this adaptor is that it makes AtariVox development much easier. Since the AtariVox is not (yet) supported by any of the emulators, it was previously necessary to write a test program and then upload it to the Atari, e.g. using the Krokodile cart. With the USB adapter, the AtariVox can be programmed directly from the PC. Incidentally, I was grateful for Nathan's review of the AtariVox, since my unit was indeed set to maximum volume. Using the USB adapter is simple - just plug it into the PC, and Windows recognises it as a serial USB device (Mac and Linux users will not be so lucky). The AtariVox can then be programmed using the hacked PhraseALator software or VoxPlay. It turns out that the AtariVox is not particularly easy to program. It is capable of making a wide range of sounds, but assembling these sounds into recognisable speech can take a lot of trial and error. Fortunately the PhraseALator software has a reasonably large dictionary that can be used in many cases. I also found that I got rapidly better at figuring out the necessary sounds after a bit of practise. Here is a reasonable approximation to "Juno First": \JH \UW \NO \OWWW \P1 \FF \AXRR \SE \TT I now think that the AtariVox is quite a cool bit of hardware, and the USB interface makes it much easier to develop for. I'm planning to use it in my future software projects, though I'm not sure I will be able to use it in Juno First, since it requires rather a lot of cycles - perhaps just a few bits of speech during the title screen. Now, if only it was as easy to develop for the Savekey ... Chris
-
It's been a while since I posted anything here, so here is a quick entry about a recent Atari 2600 project of mine. I had an idea for a holiday-cart based around the Ultimate game Pssst! for the ZX Spectrum. For those unfamiliar with the game, here is a flash version of Pssst!, and a YouTube video of Pssst!. The aim of Pssst! is to protect the flower growing in the centre of the screen from a variety of different bugs. The bugs are destroyed by spraying them using the aerosols positioned at the edges of the screen. To make things harder, different bugs require different sprays. If the bugs reach the flower they start eating it up until they are destroyed. You lose a life if the flower gets eaten entirely, or if you run into a bug. A new level begins when the flower finishes growing. The number, speed, and variety of bugs increases at the game progresses. My idea was to make this into a holiday game, based around protecting a Christmas tree (instead of a flower). However, I didn't take it further than a small demo for a number of reasons: I discussed the game with Nathan and we agreed that it wasn't holiday-themed enough. Shooting bugs doesn't really have anything to do with holidays! I enjoyed this game a lot when I was young, but I found it quite annoying when I played it recently. There isn't really enough variety in the gameplay, and the game gets ridiculously difficult very quickly. It may be possible to fix these issues by having different stages or by tweaking the gameplay. As usual, things got very hectic at work around the holidays and I had no free time to progress the game beyond a simple demo. The kernel demo of the game (and source code) for Pssst! should be attached at the end this entry. The demo isn't quite playable, but you can move around the screen, pick up aerosols (with fire), and kill the bugs (which don't move). The player and bug sprites are completely temporary and would be replaced in a real version of the game (they are monochrome in the demo, but the kernel allows a different colour on each scanline). A sample screenshot is shown below: I probably won't take this any further unless the gameplay issues can be solved. However, I'm interested to know what people think of the game and the demo, and for any suggestions. Chris P.S. I don't know either when Juno First is coming out on a cart, but I'm sure it won't be long now! The game and manual have been finished for some time.
-
With Juno First nearly done, I have started to think about my next Atari 2600 game project. I don't have anything decided yet, but these are the various projects that I have been considering: Prince of Persia - I wrote a reasonable kernel for this a few years ago. However, the main issue is that it requires extra RAM and there aren't any such carts available yet. The other issue is the massive sprite requirements of the game. Le Geek made a good start on the sprites a while back, but there doesn't seem much point continuing until the hardware issue is resolved. JetPac - my earlier Jetman 1K game was a limited attempt at a port of JetPac. However, a full port should be possible on the 2600 (probably with a lot of flicker). Millenium 2600 - I am a big fan of the game Millenium 2.2 on the Atari ST. I should be possible to do a similar simulation on the 2600 using an AtariVox/SaveKey to hold the game state. However, it would probably be a text-only game, and I think that might put people off? Juno Second - I've got various ideas that might make for a good Juno Second, e.g. more aliens, aliens attacking from behind (with rear shooting), two-player mode, missions. However, Juno First already pushed the limits of the hardware, and any extension would likely require extra RAM. Armor Attack - A port of the Vectrex game Armor Attack should be possible, with a bit of creative sprite work and some AI. However, I'm a bit concerned that it is too similar to Combat? Hunchback - A full port of the Hunchback arcade game should be possible, but it will be rather similar to my existing Hunchy minigame. Pssst - A port of the Spectrum game Pssst may be possible with a bit of creativity. I haven't made any decision yet, so let me know if you have any preference from the above list, or any more ideas for games? Chris
-
Now that the Juno First release candidate is out, I have a bit more time to look at other 2600 programming. I have been interested in batari basic for a while as I have several game ideas that could be done with a custom kernel strapped on. However, until recently I hadn't really looked at batari basic properly. One thing that has been bothering me is that batari basic doesn't have a way to load playfield data directly from ROM. There are several games (e.g. Cave In) that have a high resolution playfield, but this requires extra superchip RAM. To cut a long story short, I have now written a prototype batari kernel that can load playfield data directly from ROM, without the need for the superchip. This should make several new kinds of games possible, and allow some existing superchip games to be released on regular carts. The new kernel works by copying a single line of the playfield into RAM at a time. When a new playfield line is required, the kernel performs a bankswitch and copies the next line into RAM. The key to the technique is the following code which is placed in each bank. To make this code work, X is set to the bank containing the PF data, pfptr points to the start of the data, and pfoffset holds the current playfield offset from the start: BS_loadPF ; Switch To Playfield Bank & Copy Data lda bankswitch_hotspot-1,x; [9] + 4 ldy pfoffset; [13] + 3 lda (pfptr),y; [16] + 5 sta aux1; [21] + 3 iny ; [24] + 2 lda (pfptr),y; [26] + 5 sta aux2; [31] + 3 iny ; [34] + 2 lda (pfptr),y; [36] + 5 sta aux3; [41] + 3 iny ; [44] + 2 lda (pfptr),y; [46] + 5 sta aux4; [51] + 3 iny ; [54] + 2 sty pfoffset; [56] + 3 ifconst bankswitch if bankswitch == 8 lda $FFF9; [59] + 4 endif if bankswitch == 16 lda $FFF9; [59] + 4 endif if bankswitch == 32 lda $FFFB; [59] + 4 endif endif jmp EndLoad; [63] + 3 This code requires 57 cycles, so an extra blank line is required between PF rows. However, I think it still looks good (compare the attached Cave In screenshots below to see the difference). Let me know if you can see any improvements to this technique? Obviously it could be improved if the playfield data was always in the same bank as the kernel, but this isn't practical for many games. Because the PF data is loaded from ROM, it could technically support more than the 31 PF rows of the superchip kernel, though I haven't tried this yet. The kernel is still at a prototype stage and I could use a bit of help to improve it and integrate it properly into batari basic. The files that I have changed from the standard 1.0 release of batari basic are attached (in batarifiles.zip). The main issues are: There isn't enough RAM left to support various kernel options, e.g. pfscore, pfheighttable, pfcolortable, lives, etc. This can probably be fixed by reorganising things a bit. The colour data for the player 1 sprite is off by one line (not sure why). It should probably be integrated as a new kernel, rather than a hack of the standard kernel. It is relatively tolerant of page boundary crossings in the playfield data, but this could be improved. There are some weird issues display missile and ball sprites (occasionally it craps out completely). I have been using the Cave In source code as a testbed for this kernel. However, I don't want to post the code here as I haven't heard from Atarius Maximus yet. I can only compile pre-RC1 versions as the new kernel requires a bit of extra space in each bank and this is pushing things over the limit. Hopefully this issue can be fixed in later versions. Anyway, let me know what you think? I'm not sure of the status of the superchip boards, so this kernel might not be necessary, but I still think it would be nice to avoid using the superchip if it is not strictly required. Chris
-
There is a discussion currently in the homebrew forum about adding a flashing cockpit to the Juno First ship. One approach would be to use the ball sprite overlaying the player sprite. The ball sprite is used for the laser and is already correctly positioned (horizontally), but I can't find the spare cycles to enable and disable it at the correct time. The main loop where the ship is drawn is a 1LK as follows (the actual code is in kernel1.h in the zip attached to the previous entry): A_ShipLoop ; Calculate Pointer to Alien Sprite Data (aliens are 8 pixels high) tya ; [45] + 2 sbc ALIENY ; [47] + 3 bcs A_NoDraw ; [50] + 2/3 adc #8 ; [52] + 2 bcc A_NewSprite ; [54] + 2/3 adc TYPE ; [56] + 3 tax ; [59] + 2 ; Preload Ship Data lda (SPTR),Y ; [61] + 5 sta GRP0 ; [66] + 3 VDEL'ED ; Draw Alien & Ship lda A_Aliens,X ; [69] + 4 sta GRP1 ; [73] + 3 > 75 lda A_AlienCols,X; [0] + 4 sta COLUP1 ; [4] + 3 > 75 < 23 ; Set Ship Colour lda (CPTR),Y ; [7] + 5 sta COLUP0 ; [12] + 3 < 23 ; Draw Bullets (using PHP stack trick) tya ; [15] + 2 lsr ; [17] + 2 cmp B2 ; [19] + 3 php ; [22] + 3 cmp B1 ; [25] + 3 php ; [28] + 3 = 16 ; Reset Stack Pointer ldx #ENAM1 ; [31] + 2 txs ; [33] + 2 ; Check End of Kernel dey ; [35] + 2 bmi A_EndShipKernel ; [37] + 2/3 ; Check If Grid Line Should Be Drawn cpy LINE ; [39] + 3 bcs A_ShipLoop ; [42] + 2/3 ; ... Draw Grid Line, Alien & Ship and Return to Loop The y register holds the line count, and there are variants of this loop for drawing background lines, calculating a pointer to the next alien, and repositioning the alien sprite. In these variants the bullets are not drawn, which frees up the necessary extra cycles. To get a flashing cockpit, the ball sprite needs to be enabled and disabled at the correct time. One approach would be to use the lowest bit of the colour data, but would require 5 extra cycles as follows: lda (CPTR),Y sta COLUP0 asl sta ENABL Unfortunately I can't see any way to accomplish this. Unrolling the loop is not really possible as this would require 40 copies of this code (and all of the variants for repositioning etc.). I was wondering if any of the optimisation wizards around here could spot any way to fit this in. If not, it doesn't matter too much as this feature is not exactly essential to the game! Chris
-
I had a holiday yesterday and was able to spend some time finishing Juno First. I have now posted a beta version in the homebrew forum for general testing. There are quite a few changes since the last version that I posted, namely: There are now 32 unique waves, and I have made many changes to the previous set of 16. The game actually has 64 waves in total, but the second 32 are the same as the first with a higher speed setting. The fuel gauge now empties at twice the speed, which means that there is only 45 seconds to complete each wave. I have finally added the explosion sound effects and an effect at the beginning of each wave. EDIT: the source code is attached below (binary versions are in the homebrew forum). As usual, let me know of any problems. Chris
-
I have been slowly working my way through the Juno First to-do list that I posted in the last entry. The SaveKey support turned out to be a real pain to get right. Fortunately I managed to unearth my Krok Cart from storage, but it was still very difficult to find the bugs. However, the game now has working SaveKey and AtariVox support (fingers crossed). There is a little bit of AtariVox speech at the beginning and end of every game, and the high score table is stored on the SaveKey. I have attached the latest version of the game to this message. The main changes this time are: Setting the Player 0 DIFFICULTY to A speeds up firing and limits the number of consecutive shots to 5. Pressing SELECT in the game takes you to the next wave (just for testing). Sky changes colour, and flashes when nearing the end of hyperspace. Removed the flickering colours in hyperspace. Hyperspace scoring should be fixed. Collision detection should be improved. PAL60 colour support added. SaveKey support enabled. AtariVox speech added. My plan is to post a beta version on the Homebrew forum in the next week or so for testing. The only things left to do before then are to add a load more waves and a few more sound effects. As usual, let me know if you find any problems in the game, particularly any screen rolls. Chris
-
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 easy to wrap the score before). Here is a list of things left to do now before the game will be complete: Test Savekey support. Add player and alien explosion sound effects. Add "new wave" sound effect. Fix hyperspace scoring. Fix astronaut collection bug. Implement more waves (I'm aiming for either 32 or 64). Change background colour during hyperspace (if possible). Show score at end of game. PAL90 colour conversion. AtariVox support. Attract mode (not sure yet). It looks like there is going to be around 4K spare at the end. I might use this for another set of colours, or I could include an Easter egg (PM me if you have a good small game that you would like to see on a cart - no promises)! Let me know if I have missed anything from this list, or if you spot any bugs or screen jumps. Chris
-
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 and missile sprites to draw the 13th character). This trick provides exactly what I need for my high score table: The first part of the kernel arranges the sprites like this (P0 is set to 3 copies medium and P1 is set to 3 copies close): 0--101-10 Using the NUSIZ trick it is possible to display another copy of P1 (by setting it to 3 copies medium after the third sprite is drawn). This gives the following sprite layout: 0--101-10--1 This layout provides the necessary four-part display (Position, Score, Initials, Wave) that I was after! The spacing between the columns isn't perfect, but I think it looks good enough in the screenshot. The attached code demonstrates this technique. I haven't actually tested this on real hardware, so I hope the NUSIZ trick works in practise (it works fine in Stella and Z26)? Hopefully everyone will agree that this kernel looks much better than my previous attempt! Chris
-
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 displayed nicely on a single line, rather than split across lines. I'm planning to integrate this, together with SaveKey support, in the next release. Note that I haven't included the level number as there is no room to store this in a single page on the SaveKey. Chris
-
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 of the game is the addition of 8 levels to the game, this means that it is finally possible to play the game properly! The other main changes in this version are: A new colour scheme supplied by Nathan (colours change on alternate waves - see screenshot). A message display at the bottom of the screen. Lots of code reorganising. Note: It is essential to play this game with Phosphor mode enabled (-f for Z26, or Alt-P in Stella) or the game becomes (more of) a flickery mess! The main things left to do now are more levels (I think I can fit around 32 levels in the game), Savekey/AtariVox support, more sound effects, and an attract mode if there is space. Anyway, let me know what you think of the levels - they are a bit rough at the moment and not properly tuned. I think the game is going to be very hard indeed as I haven't managed to finish these levels without cheating (but it could just be me)! Have a Happy Easter, Chris
-
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 previous entry will be coming in the next few releases. I'm actually enjoying playing this game myself (which is rare), so I think it is coming along nicely! Chris
-
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 add more polish. Chris
-
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 version should also fix the screen jumping issues - let me know if you find any more! Chris
-
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 to save the high-scores on the SaveKey, but this will have to wait until I dig out my hardware again as the SaveKey isn't yet supported by any of the emulators. I was also planning to use AtariVox sound effects to the game. However, on reading the documentation it seems to require a lot of time to communicate with the SpeakJet chip, and I don't many spare cycles in the Juno code. The next step is to attach the title screen code to the main game and start making it playable. Chris
-
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'm still interested to know if the flicker is bearable on a real TV set? Chris
-
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 previous text kernels. I will be very grateful if someone can run this on a real 2600 as my own equipment is currently buried in storage. I'd like to check that it actually works, and if the flicker is acceptable on a real TV? Chris
-
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 in ROM. Fortunately, copying into RAM didn't impose too much of a penalty and it allowed the buffer creation code and display kernel code to be overlapped. As a result, I can now display 13 lines of text on the screen, as shown below: The kernel takes up a whole 4K bank now and is fairly RAM heavy, though some overlapping may be possible (as suggested by supercat in the last entry). The text data is double-buffered, so it would actually be possible to display the last line of text immediately after the second last, though this would look a little odd. I am reasonably happy with this now, as it manages the same number of lines on-screen as the ET Book Cart, while flickering much less! I think this is really as far as it will be possible to go with this approach, without merging the text characters in advance, though I said that last time! I think this would now make a very nice kernel for a text adventure as it enables text to be loaded from anywhere in ROM. I'm not too keen on this kind of game, so I probably won't be doing it myself. However, I've attached the source code and anyone is free to use it in their own projects (though drop me a line first if you do). Chris Edit: textkernel3.zip is the new 13 line kernel, and textkernel_zp.zip is the 12 line kernel from the previous post adapted to use zero page RAM. textkernel3.zip textkernel_zp.zip font.zip
-
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 room for the actual text. This could be solved by copying the text into zero page memory and then doing a bank-switch into the kernel code. However, the copying code would require 24 iterations of the following code (24x10 cycles = 240 cycles = 3.2 scanlines), which would negate any savings with this method! lda (TEXTPTR),Y sta BUFFER+? dey This is probably as good as I can get the code without pre-computing character pairs (as in supercats method), but this would be difficult with lower-case characters ... Chris
-
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-chars wide) on the screen: I would be happy with this if it weren't for a much better text kernel that supercat posted recently, which gets nearly twice as many lines of text on-screen. As a result, I'm going to try to improve this code to see if I can squeeze in a few more lines. I'll post the results here if I manage to make any improvements. Chris
-
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 (Game Properties->Display under Stella) or it looks like a mess. There is one small issue with this technique when using a real TV, and that is a banding effect between the columns. I think this is caused by colour bleeding, but I'm not entirely sure. This banding effect is shown (exaggerated) in the screenshot below: Anyway, even with the banding effect, I think the logo looks very nice. The binary and source for the title screen are attached at the bottom of this message. This screen will be included in my next Juno code release (hopefully sometime soon). One of the few things missing from the game now is some music for the title screen - there isn't any in the arcade game, but title music seems to be the norm for Homebrew Atari games! If anyone has any spare music that they would like to contribute, then I will be very grateful! Chris
-
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 working, except in one case, which would cause the gridline to jump in an annoying way. The source of the problem is that the alien sprites need to be repositioned at various places on the screen, and this repositioning takes a screen line to accomplish. This repositioning can clash with the drawing of the gridline, as there isn't enough time to do both. In most of the screen this wasn't a problem, as I just delayed the repositioning by 1 line when this happened (with a gap of two screen lines between aliens). However, at the bottom of the screen the ship also needs to be drawn every screen line and this trick doesn't work. My solution was to draw the gridline immediately after repositioning in this case, but this causes the gridline to be drawn one line further down, and leads to the annoying jumping effect. For a long time, I tried to re-arrange things to avoid the jumping problem. I managed to get within a few cycles of a solution by resorting to some loop unrolling, but I just couldn't make it fit! However, I recently read this post in batari's blog and was inspired to have another go. The suggestion in this post is that it isn't always necessary to waste a complete line on repositioning the sprites, since most of the repositioning code is just waiting for the correct position. Instead, it is possible to implement a series of mini-kernels that each reposition the sprite in a different horizontal position, and also have some spare time to do extra work! However, this technique is difficult to implement and requires a lot of ROM space. In Juno First, the aliens don't go completely to the edges of the screen, so there are ten different horizontal sprite positions. Therefore, 10 mini-kernels are required to implement the technique. I used the following code to jump to the correct mini-kernel: ; Set pointer at beginning of kernel lda #>ReposFunctions sta JPTR+1 ; Jump to correct minikernel ldx XPOSITION lda ReposTable,X sta JPTR jmp (JPTR) The jumping code costs only 15 cycles, but it requires a fairly large table of pointer values. In Juno First, there are 15 pointers required for each of the 10 mini-kernels: ReposTable DS.B 15, #<Repos0 DS.B 15, #<Repos1 DS.B 15, #<Repos2 DS.B 15, #<Repos3 DS.B 15, #<Repos4 DS.B 15, #<Repos5 DS.B 15, #<Repos6 DS.B 15, #<Repos7 DS.B 15, #<Repos8 DS.B 15, #<Repos9 EndReposTable Within each kernel it is necessary to hit the RESPx register at exactly the right time and also to set the HMPx value. I accomplished this with the following code fragments. Obviously, the cycle on which RESPx is hit, and the sbc# value must be changed in each mini-kernel. ReposX ; Reposition Sprite (Coarse) sta.w RESP1 ; Must happen on exactly the right cycle (20/25/30/35/40/45/50/55/60/65) ... ; Fine Tuning (X contains sprite position) txa sec sbc #30 ; Change value for each mini-kernel: 15/30/45/60/75/90/105/120/135/150 sta HMP1 ; Can happen anywhere before HMOVE ... ; Move Sprite sta WSYNC sta HMOVE EndReposX Anyway, to cut a long story short, I managed to get this technique working in Juno First after a lot of tweaking. The results are attached to this message. The kernel now takes a whole 4K bank and is the most convoluted bit of code that I ever hope to write! However, it has got rid of the annoying jumping gridline, so I am pleased with the results. I have also made a number of other tweaks to the Juno code since my last posting: Homing bullets are now implemented (although slightly buggy)! All the different alien types have their own movement and firing patterns. You have three warps (shown by the W's at the bottom of the screen). Pressing Select will make your ship disappear for a short time (handy for avoiding bullets). There is a nice reverse-explosion when the ship appears on the screen. You have to hit fire to start the game, and to resume after you die. The game now has all of the important features that I planned to include, although there is still a lot of polishing to do. I'm not going to make any rash predictions about when I will get this finished, as at least the following tasks have still to be completed: Implement lots of levels with different alien types. Make something happen when you pick up an astronaut! Add some cool sound effects! Add a title screen and high score table (see previous post). Add more polish if there is space, e.g. music, attract mode, colour schemes, etc. As always, let me know if you find any bugs or have any suggestions. The game works in both Stella and Z26 (use phosphor mode), but I haven't tested it on real hardware. I will strongly resist any changes to the kernel now, except if there are any bugs Chris
-
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 possible. It also looks like I will be busy for some time to come, and as a result I haven't been able to help out with this years' holiday cart. However, there is one small Atari project that I have managed to make some progress on, and I though I would post the initial results here. A feature that is missing from most Atari games, but is ubiquitous in the Arcades, is the "high score" table. Now that the SaveKey is available there seems to be no good excuse for this omission. I though it would be a good idea to try and write a generic Top-10 highscore routine that people could include in their games. I also wanted to include a highscore feature in Juno First, should I ever find time to finish the game. It turns out that it is quite difficult to design a high score routine as there are lots of exceptions that can occur, e.g. if the savekey is removed, or errors occur during reading or writing. As a result, I first designed a state chart which covers most of the possibilities: The main difficulty of developing for the Savekey is that it isn't currently emulated in either Stella or Z26. I had hoped that it might be possible to use the Savekey with the Stelladapter, but this doesn't seem to work. My Atari stuff is still in deep storage since I moved, so I haven't been able to test my code properly, but I have written some initial code that follows the state chart above. The code is completely unoptimised and takes up a full 4K, but I wanted to check that it works before I start shaving cycles. Also, I figured that anyone else using this code would probably want to customise it themselves, and any heavy optimising would get in the way. Edit: Minor code update - fixed some obvious bugs and optimised a bit - still untested on real hardware: controllerpics.zip The initial code and binary is attached above. In Stella, it gets stuck waiting for you to attach the Savekey, while in Z26 is acts as if the Savekey were connected. I have attached a couple of screenshots below so you can see the main screens. I will be grateful if someone could try this on a real Savekey, although it may corrupt any data that you have on there, so be very careful! Let me know if you find any bugs or have any suggestions for improvements. The text kernels are just for demonstration purposes and will be improved later. Chris
-
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 has a lot more RAM than the SC, it permits multiple games to be stored, and it keeps its content when the power is switched off. As a result, my old SC will now be retired from game development duties, unless I am actually developing for the SC itself, e.g. if I revive my PoP game. There is one small problem with the KC though: it doesn't have a Linux driver. This is an issue for me as I do most of my computing work under Linux. I do have a Windows installation, as it is sometimes unavoidable, but I would prefer not to have to use it everytime I need to write to the KC. As a result, I decided to investigate the Mac OS-X driver to see if there was some way to port it to Linux, since the two systems have many similarities. SpiceWare was kind enough to send me the source code for his OS-X driver, and a copy of the KC serial transfer protocol document. It quickly became apparent that the protocol was very straightforward, and it wouldn't take too much work to port the driver across. However, as my C coding is rather rusty these days, I thought I would have a go at porting it to Java instead. The advantage of this is that the same code would work across multiple platforms, and it would be easier to build a GUI. To cut a long story short, I have spent the last couple of days rewriting the KC driver in Java. The serial port communication is accomplished using the Java Communications API. I am actually using the RXTX implementation of this API, as it is available on many more platforms than the Sun version, and seems to be more actively developed. The latest version of my Java code is attached to the bottom of this entry, and there are basic instructions in a README file. It can already download a single file to the KC under Linux, and I have tested it with a variety of different bankswitching schemes. This is actually all that I need, as it lets me test my Juno First game on the KC, but I am planning to clean it up a bit and add multicart support in the near future. I haven't tested it on other platforms, but the Java code should work fine if the correct RXTX implementation is used. Anyway, let me know if this is useful to anyone, or if I am the only Linux hacker around here? At the moment the code is really only intended for experienced Java hackers, but I will improve it further if there is any demand. I don't have any plans to add a GUI at the moment, but I may do this in the future (or someone else might volunteer ). Chris
-
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 application, but it now has essentially the same feature set as the OS X version, except for the cart database. This is probably as far as I will go with this as it now does everything that I want with the software. However, if anyone else would like to improve it, e.g. add a GUI, then they are more than welcome to modify the source code. Chris EDIT: I have attached a precompiled version of the jkrok software for Linux x86 below. Instructions are in the README inside the zip. Let me know if there are any problems, as this was done in a hurry!