Disaster! My cleverly contrived apparatus to break-out the CoCo cartridge port to a breadboard doesn't work! In fact, it could even damage the CoCo...
Short Circuit
The apparatus I described in the previous post included a breakout board designed for use with the Raspberry Pi 2. This board includes a 40-pin IDC connector and pins in the footprint of a 40-pin DIP. This seemed to be a perfect match for the 40-pin CoCo cartridge port.
Unfortunately, the designer of the breakout board has "helpfully" used his knowledge of the Raspberry Pi 2 GPIO port in order to tie all of the Ground lines together on the breakout board. This might have only been an avoidable nuisance, but it turns-out that the layout of the pins on the board is such that when adapted to the CoCo cartridge port, +5V power is shorted to ground. The traces responsible for the short are not visible, so I don't think the board can easily be modified. Fortunately, at least I don't seem to have damaged any CoCo in the making of this mess!
Retreat
Time was already a bit short for me this month, as I have plans to be at KansasFest. I'm not sure I have time to order any new parts either. I'm not sure where this leaves me.
Maybe I can come-up with a way to save this project? Or perhaps I can hatch another one? I will have to take some time to consider my options.
Stay tuned...
Monday, July 6, 2015
Friday, July 3, 2015
Holiday Weekend
Well, the Retrochallenge 2015/07 event started a couple of days ago. As usual I'm off to a slow start. This weekend started a day early, giving me a little time to get going on my project. So far I've done very little, but I thought it might be useful to review the outline of the project and discuss some possibilities...
Outline
The point of this project is to exploit some features of the CoCo cartridge port for the potential benefit of game cartridges. Therefore it is reasonable to question what such features are available. This includes interrupt signals, address decoding signals, and audio input.
I have discussed the interrupt-based timing sources available on the CoCo in my other blog posts over the years. The Hsync and Vsync signals are a bit inflexible and difficult to use for audio playback in particular. Vsync is too slow to drive the DAC, and Hsync is much faster than needed -- especially since it connects through the PIA that feeds the IRQ signal on the 6809. The CART line on the CoCo cartridge port is actually tied to the PIA that feeds the FIRQ (i.e. "fast IRQ") signal on the 6809, potentially making it a great candidate for an audio playback timer signal.
The cartridge port provides two separate address decoding signals. One is the standard ROM chip select used to access program code on cartridges. The other is designed for accessing the floppy drive controller hardware. But since a game cartridge typically is used without other cartridges, that signal can be used for whatever purpose a cartridge likes. In particular, it can be used to provide access to other hardware bits that a game might need.
The CoCo cartridge also has a line that can feed an audio signal directly back into the CoCo. This could be used to enable audio generation hardware directly in the cartridge itself.
Apparatus
(Note: the apparatus does not work -- do not attempt to replicate this from the picture!)
The purpose of this experiment is really just "proof of concept", so I won't be bothering for now with building PCBs or any other permanent design artifacts. Instead, I only want to have electrical access to the CoCo cartridge port as a means of interfacing to hand-built circuits on a breadboard.
Some time back another CoCo person produced some simple PCBs that breakout the cartridge port to a 40-pin IDC connector. More recently, the popularity of the Raspberry Pi platform has led to the availability of some small PCBs that adapt between a 40-pin IDC connector and a 40-pin DIP connector compatible with a breadboard. I combined these two items to adapt from the CoCo cartridge port to a solderless breadboard.
I often like to use a "monitor" program plugged into the the cartridge port when doing CoCo development. In order to facilitate that, I have added a "Y cable" to the mix. This should allow me both to use the "monitor" program and to have access to the cartridge port signals for circuit development.
Ideas
If I haven't lost you yet, then I probably don't need to tempt you further! Nevertheless, I will provide a couple of teasers to whet your appetite...
In order to facilitate audio playback on the CoCo, a reasonably paced signal is needed. Use of the FIRQ line is desirable, since that can be the most efficient mechanism for handling high frequency events. The more flexible interrupt and timing mechanisms of the CoCo3 illustrate that a moderately paced FIRQ signal can provide pleasing audio playback. So, a simple idea is to use a simple timer circuit (e.g. a 555 wired as an astable multivibrator) to provide such an FIRQ signal.
A normal CoCo cartridge can provide almost 16Kb of program storage. That may seem like plenty(!), but larger programs can easily consume that with graphics assets, audio samples, map data, and even just program code. One approach to extending available storage is bank switching. This can be done by using the I/O address range in the cartridge to control the bank switching hardware in order to multiplex the ROM address range onto a larger memory.
Adding audio hardware to the CoCo seems like a simple way to extend its gaming capabilities. This may have been expensive in the past, but for today's hobbyist I think this option seems quite reasonable and could make for a very collectible game cartridge. Anyway, I hope to conduct the exercise of building such a circuit as the month progresses.
If I get this far, I may have one more idea that would have seems a bit ahead of it's time when the CoCo was in stores. Still, it might be a cool option in today's market. For now I'll keep this last one under my hat...stay tuned!
Outline
The point of this project is to exploit some features of the CoCo cartridge port for the potential benefit of game cartridges. Therefore it is reasonable to question what such features are available. This includes interrupt signals, address decoding signals, and audio input.
I have discussed the interrupt-based timing sources available on the CoCo in my other blog posts over the years. The Hsync and Vsync signals are a bit inflexible and difficult to use for audio playback in particular. Vsync is too slow to drive the DAC, and Hsync is much faster than needed -- especially since it connects through the PIA that feeds the IRQ signal on the 6809. The CART line on the CoCo cartridge port is actually tied to the PIA that feeds the FIRQ (i.e. "fast IRQ") signal on the 6809, potentially making it a great candidate for an audio playback timer signal.
The cartridge port provides two separate address decoding signals. One is the standard ROM chip select used to access program code on cartridges. The other is designed for accessing the floppy drive controller hardware. But since a game cartridge typically is used without other cartridges, that signal can be used for whatever purpose a cartridge likes. In particular, it can be used to provide access to other hardware bits that a game might need.
The CoCo cartridge also has a line that can feed an audio signal directly back into the CoCo. This could be used to enable audio generation hardware directly in the cartridge itself.
Apparatus
(Note: the apparatus does not work -- do not attempt to replicate this from the picture!)
 |
| Breakout Circuit for CoCo Cartridge Port |
The purpose of this experiment is really just "proof of concept", so I won't be bothering for now with building PCBs or any other permanent design artifacts. Instead, I only want to have electrical access to the CoCo cartridge port as a means of interfacing to hand-built circuits on a breadboard.
Some time back another CoCo person produced some simple PCBs that breakout the cartridge port to a 40-pin IDC connector. More recently, the popularity of the Raspberry Pi platform has led to the availability of some small PCBs that adapt between a 40-pin IDC connector and a 40-pin DIP connector compatible with a breadboard. I combined these two items to adapt from the CoCo cartridge port to a solderless breadboard.
I often like to use a "monitor" program plugged into the the cartridge port when doing CoCo development. In order to facilitate that, I have added a "Y cable" to the mix. This should allow me both to use the "monitor" program and to have access to the cartridge port signals for circuit development.
Ideas
If I haven't lost you yet, then I probably don't need to tempt you further! Nevertheless, I will provide a couple of teasers to whet your appetite...
In order to facilitate audio playback on the CoCo, a reasonably paced signal is needed. Use of the FIRQ line is desirable, since that can be the most efficient mechanism for handling high frequency events. The more flexible interrupt and timing mechanisms of the CoCo3 illustrate that a moderately paced FIRQ signal can provide pleasing audio playback. So, a simple idea is to use a simple timer circuit (e.g. a 555 wired as an astable multivibrator) to provide such an FIRQ signal.
A normal CoCo cartridge can provide almost 16Kb of program storage. That may seem like plenty(!), but larger programs can easily consume that with graphics assets, audio samples, map data, and even just program code. One approach to extending available storage is bank switching. This can be done by using the I/O address range in the cartridge to control the bank switching hardware in order to multiplex the ROM address range onto a larger memory.
Adding audio hardware to the CoCo seems like a simple way to extend its gaming capabilities. This may have been expensive in the past, but for today's hobbyist I think this option seems quite reasonable and could make for a very collectible game cartridge. Anyway, I hope to conduct the exercise of building such a circuit as the month progresses.
If I get this far, I may have one more idea that would have seems a bit ahead of it's time when the CoCo was in stores. Still, it might be a cool option in today's market. For now I'll keep this last one under my hat...stay tuned!
Thursday, June 18, 2015
RC2015/07 Competition Entry
June is halfway gone, and another RetroChallenge event is just around the corner. July is going to be busy for me, including my first ever attendance at KansasFest. That combined with some external things had me wondering if I had time to participate in this round of RetroChallenge, but I do enjoy the events and the cadence they provide for my retrocomputing hobby. So, what to do?
The Struggle Is Real
I often have trouble coming-up with projects for these things. It is important to "size" things properly to fill a month's time without running long enough to elude completion. It should also be interesting for readers (or viewers) at a variety of technical skill levels. Of course, it also needs to be interesting for me as well! Finding the "perfect" project is probably impossible, but it is hard not to try... :-)
Spit It Out!
OK, OK...while I have at least some interest in a number of retrocomputer and retrogaming systems, there is no denying that I'm in love with the CoCo. Recently I even produced the first cartridge-based game release for the CoCo in decades. While Fahrfall cartridges only hold an EPROM, there are other capabilties of the CoCo expansion port that could be exploited for more advanced gaming possibilities.
So, for my RetroChallenge 2015/07 project I will be exploring some hardware possibilities for CoCo cartridges that might be interesting for games in particular. This will include both some existing (i.e. documented) circuits and hopefully some new ones as well.
Want to learn more? Then you will just have to stay tuned... :-)
The Struggle Is Real
I often have trouble coming-up with projects for these things. It is important to "size" things properly to fill a month's time without running long enough to elude completion. It should also be interesting for readers (or viewers) at a variety of technical skill levels. Of course, it also needs to be interesting for me as well! Finding the "perfect" project is probably impossible, but it is hard not to try... :-)
Spit It Out!
OK, OK...while I have at least some interest in a number of retrocomputer and retrogaming systems, there is no denying that I'm in love with the CoCo. Recently I even produced the first cartridge-based game release for the CoCo in decades. While Fahrfall cartridges only hold an EPROM, there are other capabilties of the CoCo expansion port that could be exploited for more advanced gaming possibilities.
So, for my RetroChallenge 2015/07 project I will be exploring some hardware possibilities for CoCo cartridges that might be interesting for games in particular. This will include both some existing (i.e. documented) circuits and hopefully some new ones as well.
Want to learn more? Then you will just have to stay tuned... :-)
Saturday, June 6, 2015
Digital Joystick for a CoCo?
From time to time, we see requests on the CoCo mailing list for ways to use digital joysticks with the CoCo. You see, the CoCo is designed to use analog joysticks for pointing, like the Apple II or the IBM PC. Joysticks like that are good for applications requiring precise positioning, like Flight Simulator or the old game Doubleback. But for action-oriented arcade games like Pac Man, Frogger, or Donkey Kong, the brute force choice of a simple direction is usually preferred over precise positioning. Worse, like the Atari 5200, the original CoCo joysticks weren't even self-centering...
Adapt
While the later "deluxe" CoCo joysticks addressed the self-centering issue, analog joysticks still feel a bit sloppy for most arcade games. One option is to build an adapter that allows the use of common 9-pin digital joysticks like those used on the Atari 2600, the Commodore 64, and other machines from that era. Such adapters are built around a single integrated circuit, are relatively simple to build, and allow the use of unmodified digital joysticks with the CoCo. Tim Lindner has a YouTube video of him building just such an adapter.
Improvise
The other option involves either hacking an existing joystick to work with the CoCo or building your own to do so. These options are essentially the same, each requiring a circuit to convert switch closures into analog voltages that are meaningful to the CoCo. A hand-drawn schematic of such a circuit is shown above.
Unlike the Apple II and IBM PC, the CoCo does not use an RC timing circuit for measuring joystick position. Instead, the potentiometers in the CoCo joysticks are wired as voltage dividers. This allows for less precision in the exact choice of components, since there is no need to match-up against anything internal to the CoCo. The biggest concern would be choosing resistor values so small that the joystick burns-out the CoCo power supply. Caveat emptor! But if you stick to the values in the schematic above, I think you will be fine...hopefully... ;-)
Overcome
The original idea for the circuit came from a post about the Vectrex, which uses a similar design for its joysticks. On each axis, the resistors are wired in an "H" configuration. The resistors on one side (the side always connected to power and ground) are significantly larger in value than the resistors on the other side of the "H". The switches are connected across the top and bottom of the "H". When a switch is closed, the equivalent resistance of the large and small resistors connected in parallel is much smaller than the value of the single large resistor on the other end of the "H". This causes the voltage at the center of the "H" to swing accordingly, fooling the CoCo into thinking that the (non-existant) potentiometer has been moved in the corresponding direction.
It would be tempting to eliminate the smaller resistors in the "H" configuration, causing the switch closure to pull the axis voltage directly to the rail voltage. The problem is that if a mechanical failure allows a pair of opposing switches to be closed at the same time, then you will have a short circuit that could damage the CoCo. Keeping resistors in the path should limit the possibilities for damage. I strongly urge any circuit builders to keep both sets of resistors.
I hope that others will find the information useful. I know of at least one other person that has used this schematic to build a CoCo joystick out of arcade components, much like I had previously done for my Fahrfall joystick. If you have any questions about the schematic, then feel free to leave them for me below. Also, you can download the PDF of the circuit if the picture of the schematic above is too small to be useful.
Enjoy!
Adapt
While the later "deluxe" CoCo joysticks addressed the self-centering issue, analog joysticks still feel a bit sloppy for most arcade games. One option is to build an adapter that allows the use of common 9-pin digital joysticks like those used on the Atari 2600, the Commodore 64, and other machines from that era. Such adapters are built around a single integrated circuit, are relatively simple to build, and allow the use of unmodified digital joysticks with the CoCo. Tim Lindner has a YouTube video of him building just such an adapter.
Improvise
The other option involves either hacking an existing joystick to work with the CoCo or building your own to do so. These options are essentially the same, each requiring a circuit to convert switch closures into analog voltages that are meaningful to the CoCo. A hand-drawn schematic of such a circuit is shown above.
Unlike the Apple II and IBM PC, the CoCo does not use an RC timing circuit for measuring joystick position. Instead, the potentiometers in the CoCo joysticks are wired as voltage dividers. This allows for less precision in the exact choice of components, since there is no need to match-up against anything internal to the CoCo. The biggest concern would be choosing resistor values so small that the joystick burns-out the CoCo power supply. Caveat emptor! But if you stick to the values in the schematic above, I think you will be fine...hopefully... ;-)
Overcome
The original idea for the circuit came from a post about the Vectrex, which uses a similar design for its joysticks. On each axis, the resistors are wired in an "H" configuration. The resistors on one side (the side always connected to power and ground) are significantly larger in value than the resistors on the other side of the "H". The switches are connected across the top and bottom of the "H". When a switch is closed, the equivalent resistance of the large and small resistors connected in parallel is much smaller than the value of the single large resistor on the other end of the "H". This causes the voltage at the center of the "H" to swing accordingly, fooling the CoCo into thinking that the (non-existant) potentiometer has been moved in the corresponding direction.
It would be tempting to eliminate the smaller resistors in the "H" configuration, causing the switch closure to pull the axis voltage directly to the rail voltage. The problem is that if a mechanical failure allows a pair of opposing switches to be closed at the same time, then you will have a short circuit that could damage the CoCo. Keeping resistors in the path should limit the possibilities for damage. I strongly urge any circuit builders to keep both sets of resistors.
I hope that others will find the information useful. I know of at least one other person that has used this schematic to build a CoCo joystick out of arcade components, much like I had previously done for my Fahrfall joystick. If you have any questions about the schematic, then feel free to leave them for me below. Also, you can download the PDF of the circuit if the picture of the schematic above is too small to be useful.
Enjoy!
Sunday, February 1, 2015
Final Thoughts for RC2015/01
The end of January has past, and thus came the end of another RetroChallenge event. As usual there were a number of interesting projects started, several completed, and a few derailed along the way. Count my port of Fahrfall to the Apple II in the completed category! Of course, no software is ever finished... :-)
Alpha Release
I want to make a binary available for my Apple II version of Fahrfall, but my "real world" knowledge of using an Apple II is still lacking in several ways. One of the things I don't know how to do is making disk images! In fact, I'm not even sure what sort of binary format is needed for an Apple II machine language program to be loaded from diskette...
While developing Fahrfall, I have been using the built-in monitor program on the Apple II in conjunction with a Super Serial Card and the "IN #2" and "PR #2" commands in BASIC. I used a 6502 assembler running on my Linux laptop to generate the machine code for Fahrfall, and I used a script to convert the binary output from the assembler into a series of monitor commands that I could send over the serial port. I am now making this file available as "fahrfall.txt" in the directory below:
http://www.tuxdriver.com/download/fahrfall/apple2/alpha-1/
In order to load the program, start the monitor (CALL -151 at the BASIC prompt) and upload the file through the serial port (assuming that you have already done the "IN #2" and "PR #2" as described above). Once the upload is complete, start the program executing at location $0C00 (C00G at the monitor prompt). In order to play with a joystick, just press the joystick button to start the game and use the joystick to move left and right. If you want to play with a keyboard, just press the spacebar to start the game and use the "open apple" and "closed apple" keys for left and right.
A Tale Of Two Platforms
At this point, I am tempted to make some comparisons between the CoCo and the Apple II and/or between the 6809 and the 6502. Instead, I'm going to avoid feeding the trolls and just say that both machines have (sometimes hidden) strengths and (often obvious) weaknesses that probably influenced the types of software that were historically available on each machine. There are differences between the CoCo and Apple II versions of Fahrfall, many of which are due to the strengths and weaknesses of the respective platforms. I hope that both versions feel like "native" games to the users of those platforms, as long as that doesn't interfere with making Fahrfall fun!
Moving Forward
As for what is next, that is hard to say. I like the colorful, moving background in the CoCo version of Fahrfall and I would love to bring something like that to the Apple II version, if possible. Some amount of music might be a nice addition to the Apple II version as well. Plus, there might be a better way to handle keyboard input? I'm not sure...
For some time I have wanted to go to KansasFest, a yearly Apple II convention. By all reports it is a great event, but my limited Apple II experience made me feel like too much of an outsider to be sure of having a good time. Now that I have an Apple II version of Fahrfall, at least I would have something to discuss with other KansasFest attendees! So, this may be the year I make the trip.
Anyway, I guess that is all I've got for now. I would like to thank the organizers of the RetroChallenge event as well as all of the other participants. As usual, the past month proved to be a great learning experience, a source of great reading material, and an excuse to have some good retro-fun. I hope these events keep coming until the end of time, and I intend to be involved whenever possible. I suspect that you, Dear Reader, feel the same way! So as alway, I expect you to stay tuned... :-)
Alpha Release
I want to make a binary available for my Apple II version of Fahrfall, but my "real world" knowledge of using an Apple II is still lacking in several ways. One of the things I don't know how to do is making disk images! In fact, I'm not even sure what sort of binary format is needed for an Apple II machine language program to be loaded from diskette...
While developing Fahrfall, I have been using the built-in monitor program on the Apple II in conjunction with a Super Serial Card and the "IN #2" and "PR #2" commands in BASIC. I used a 6502 assembler running on my Linux laptop to generate the machine code for Fahrfall, and I used a script to convert the binary output from the assembler into a series of monitor commands that I could send over the serial port. I am now making this file available as "fahrfall.txt" in the directory below:
http://www.tuxdriver.com/download/fahrfall/apple2/alpha-1/
In order to load the program, start the monitor (CALL -151 at the BASIC prompt) and upload the file through the serial port (assuming that you have already done the "IN #2" and "PR #2" as described above). Once the upload is complete, start the program executing at location $0C00 (C00G at the monitor prompt). In order to play with a joystick, just press the joystick button to start the game and use the joystick to move left and right. If you want to play with a keyboard, just press the spacebar to start the game and use the "open apple" and "closed apple" keys for left and right.
A Tale Of Two Platforms
At this point, I am tempted to make some comparisons between the CoCo and the Apple II and/or between the 6809 and the 6502. Instead, I'm going to avoid feeding the trolls and just say that both machines have (sometimes hidden) strengths and (often obvious) weaknesses that probably influenced the types of software that were historically available on each machine. There are differences between the CoCo and Apple II versions of Fahrfall, many of which are due to the strengths and weaknesses of the respective platforms. I hope that both versions feel like "native" games to the users of those platforms, as long as that doesn't interfere with making Fahrfall fun!
Moving Forward
As for what is next, that is hard to say. I like the colorful, moving background in the CoCo version of Fahrfall and I would love to bring something like that to the Apple II version, if possible. Some amount of music might be a nice addition to the Apple II version as well. Plus, there might be a better way to handle keyboard input? I'm not sure...
For some time I have wanted to go to KansasFest, a yearly Apple II convention. By all reports it is a great event, but my limited Apple II experience made me feel like too much of an outsider to be sure of having a good time. Now that I have an Apple II version of Fahrfall, at least I would have something to discuss with other KansasFest attendees! So, this may be the year I make the trip.
Anyway, I guess that is all I've got for now. I would like to thank the organizers of the RetroChallenge event as well as all of the other participants. As usual, the past month proved to be a great learning experience, a source of great reading material, and an excuse to have some good retro-fun. I hope these events keep coming until the end of time, and I intend to be involved whenever possible. I suspect that you, Dear Reader, feel the same way! So as alway, I expect you to stay tuned... :-)
Saturday, January 31, 2015
Feature Sweep
The end of RetroChallenge 2015/01 is nigh! But is Fahrfall running on the Apple II? Well, sure it is (at least for the IIe and above)! The last couple of days have seen a flurry of feature development, but I think the result is looking fairly good...
Urge To Merge
My last post talked about adding color patterns to the platforms and using another LFSR to change the platform colors. While writing that code, I discovered that I was close to the edge of a performance barrier for drawing during the vertical blanking interval. I thought that was resolved by some code optimization, but the issue returned when I attempted to merge the changes into the main game code. Fortunately I was able to find a few more minor tweaks that allowed me to merge the color changes and to still draw everything within the allotted time constraints.
Making Introductions
Games generally have a starting and an ending, and it is appropriate to mark those points prominently. Like any game, Fahrfall needs to introduce itself to the player and it needs to tell the player how well they performed. The Apple II offers a video mode that allows for graphics on most of the screen while providing four lines of text at the bottom of the screen. Fahrfall now uses this mode to display some colorful graphics while communicating to the player through text at the bottom of the screen both before and after a game is played.
Keeping Score
With the "intro" and "game over" screens in place, it was finally time to add scoring. The score itself increments as a timer while the game is in progress. Since the score is displayed as a decimal number, this seems like a perfect application for the BCD support built into the 6502! This allows for maintaining the score just like any other binary number, while making conversion of the score into screen data almost painless.
I have been using a joystick while developing the Fahrfall code, and using a joystick is the preferred method of play. Not everyone will have a joystick, so supporting the keyboard is desirable as an alternative. Unfortunately, the keyboard repeat rate is too slow to support use of the arrow keys for controlling Fahrve. (Maybe I just don't know how to get around relying on the keyboard to report repeated keys?) However, unlike most of the keys on the Apple IIe keyboard the "Open Apple" and "Closed Apple" keys are accessed directly through "soft switches". This lets me poll those keys directly at any time, so I am using those keys for "left" and "right" when keyboard access is selected. (FWIW, the keyboard access selection happens when the <spacebar> key is used to start the game.)
The game ending "sizzle" is like a Fahrfall trademark. Some people hate it, but it always gives me a chuckle to watch a new player nearly jump out of their skin the first time they end a game! The sound itself is just a short burst of noise, implemented by using the LFSR to determine when the speaker is toggled. This addition is a nice "final touch" to make Fahrfall seem complete.
Well, I think that is "pencils down" for my RetroChallenge 2015/01 entry. I now know a lot more about programming the Apple II and the 6502 processor, and I have an Apple II port of Fahrfall to show for my efforts. I reckon this counts as a success! I'll probably be back later today or tomorrow with a wrap-up post, so I hope you will stay tuned... :-)
Urge To Merge
My last post talked about adding color patterns to the platforms and using another LFSR to change the platform colors. While writing that code, I discovered that I was close to the edge of a performance barrier for drawing during the vertical blanking interval. I thought that was resolved by some code optimization, but the issue returned when I attempted to merge the changes into the main game code. Fortunately I was able to find a few more minor tweaks that allowed me to merge the color changes and to still draw everything within the allotted time constraints.
Making Introductions
Games generally have a starting and an ending, and it is appropriate to mark those points prominently. Like any game, Fahrfall needs to introduce itself to the player and it needs to tell the player how well they performed. The Apple II offers a video mode that allows for graphics on most of the screen while providing four lines of text at the bottom of the screen. Fahrfall now uses this mode to display some colorful graphics while communicating to the player through text at the bottom of the screen both before and after a game is played.
Keeping Score
With the "intro" and "game over" screens in place, it was finally time to add scoring. The score itself increments as a timer while the game is in progress. Since the score is displayed as a decimal number, this seems like a perfect application for the BCD support built into the 6502! This allows for maintaining the score just like any other binary number, while making conversion of the score into screen data almost painless.
I have been using a joystick while developing the Fahrfall code, and using a joystick is the preferred method of play. Not everyone will have a joystick, so supporting the keyboard is desirable as an alternative. Unfortunately, the keyboard repeat rate is too slow to support use of the arrow keys for controlling Fahrve. (Maybe I just don't know how to get around relying on the keyboard to report repeated keys?) However, unlike most of the keys on the Apple IIe keyboard the "Open Apple" and "Closed Apple" keys are accessed directly through "soft switches". This lets me poll those keys directly at any time, so I am using those keys for "left" and "right" when keyboard access is selected. (FWIW, the keyboard access selection happens when the <spacebar> key is used to start the game.)
The game ending "sizzle" is like a Fahrfall trademark. Some people hate it, but it always gives me a chuckle to watch a new player nearly jump out of their skin the first time they end a game! The sound itself is just a short burst of noise, implemented by using the LFSR to determine when the speaker is toggled. This addition is a nice "final touch" to make Fahrfall seem complete.
Well, I think that is "pencils down" for my RetroChallenge 2015/01 entry. I now know a lot more about programming the Apple II and the 6502 processor, and I have an Apple II port of Fahrfall to show for my efforts. I reckon this counts as a success! I'll probably be back later today or tomorrow with a wrap-up post, so I hope you will stay tuned... :-)
Monday, January 26, 2015
Over The Wall
We are now in the final lap of the Retrochallenge 2015/01 event! Time is short, and Fahrfall still lacks some key features (like keeping score)... Worse, I got a bit distracted while chasing a performance issue!!
Candy Canes Aloft
In Fahrfall, as the game progresses the color of new platforms changes periodically. I enjoy this feature, as it is both an indicator of how far the game has progressed (almost like a score...), and it rewards the player with something new in return for playing a bit longer. The graphics in the Apple II version won't allow for the "checker board" patterns available on the CoCo, but it will allow for both solid colors and a striped pattern that looks a bit like a "candy cane".
The existing code for drawing platforms only worked with single-colored platforms. I made the necessary modifications to allow for multi-colored platforms, and added some scaffolding to feed random color patterns to Fahrfall. This resulted in multi-colored platforms, but it also resulted in Fahrve's head disappearing before he reached the top of the screen!
Crossing The Line
For a while, I struggled to find the cause of this issue. I carefully checked the code changes, and I even went so far as to rewrite and test the changes in a step-by-step manner. I was almost at a loss as to the cause of this problem, until I noticed that Fahrve's head seemed to make it slightly higher up on the far right of the screen than on the far left. That observation led me to believe that I was overrunning the end of the vertical blank interval before finishing with drawing Fahrve.
With that suspicion in hand, I applied a trick for checking the timing of my vertical blank drawing work. When I start the vertical blanking period, I switch the video mode to showing text instead of low-resolution graphics. (These modes share the same video buffer on the Apple II, and the background data for the graphics screen displays as visible characters in text mode as well.) I switch the video mode back to graphics after Fahrve is drawn, which would be indetectable if done before the end of the vertical blanking interval. But as suspected, it was clear that my drawing code was not completing in time.
Redemption
Up until now, the code in the Apple II port of Fahrfall has largely grown organically. Heeding the axiom that premature optimization is the root of all evil, I have largely focused on getting things working rather than making them run as fast as possible. Unfortunately, at some point things that run too slowly simply aren't working, whether they are correct or not. Drawing during the vertical blanking interval is, in fact, a "real time" programming task! :-)
In my game loop, I was erasing the old platforms and the old Fahrve, calculating movement and detecting collisions, then drawing the new platforms and the new Fahrve. As an optimization, I delayed the movement calculations and collision detection until after drawing the new objects. This bought a little time, but not enough to meet the required deadline.
Something else I was doing sloppily was erasing the platforms. For this I was actually using the same routine I use to draw the platforms but with the data changed to use the background color. The new multi-color platform drawing code takes longer to do its job, and using that routine for erasing the platforms made that take longer as well. I replaced the platform erasing code with a simpler loop, and this was enough to meet the drawing deadline.
So, there you have it -- multi-colored platforms are possible on the Apple II port of Fahrfall. There isn't much time left during the vertical blanking interval for any other drawing tasks, but right now what is needed are less time-sensitive measures -- like scoring! I don't think I'll be able to reach a totally finished game by the end of the month, but I hope to get a bit closer than I am now. If you are curious to see where I end-up, then you will just have to stay tuned!
Candy Canes Aloft
In Fahrfall, as the game progresses the color of new platforms changes periodically. I enjoy this feature, as it is both an indicator of how far the game has progressed (almost like a score...), and it rewards the player with something new in return for playing a bit longer. The graphics in the Apple II version won't allow for the "checker board" patterns available on the CoCo, but it will allow for both solid colors and a striped pattern that looks a bit like a "candy cane".
The existing code for drawing platforms only worked with single-colored platforms. I made the necessary modifications to allow for multi-colored platforms, and added some scaffolding to feed random color patterns to Fahrfall. This resulted in multi-colored platforms, but it also resulted in Fahrve's head disappearing before he reached the top of the screen!
Crossing The Line
For a while, I struggled to find the cause of this issue. I carefully checked the code changes, and I even went so far as to rewrite and test the changes in a step-by-step manner. I was almost at a loss as to the cause of this problem, until I noticed that Fahrve's head seemed to make it slightly higher up on the far right of the screen than on the far left. That observation led me to believe that I was overrunning the end of the vertical blank interval before finishing with drawing Fahrve.
With that suspicion in hand, I applied a trick for checking the timing of my vertical blank drawing work. When I start the vertical blanking period, I switch the video mode to showing text instead of low-resolution graphics. (These modes share the same video buffer on the Apple II, and the background data for the graphics screen displays as visible characters in text mode as well.) I switch the video mode back to graphics after Fahrve is drawn, which would be indetectable if done before the end of the vertical blanking interval. But as suspected, it was clear that my drawing code was not completing in time.
Redemption
Up until now, the code in the Apple II port of Fahrfall has largely grown organically. Heeding the axiom that premature optimization is the root of all evil, I have largely focused on getting things working rather than making them run as fast as possible. Unfortunately, at some point things that run too slowly simply aren't working, whether they are correct or not. Drawing during the vertical blanking interval is, in fact, a "real time" programming task! :-)
In my game loop, I was erasing the old platforms and the old Fahrve, calculating movement and detecting collisions, then drawing the new platforms and the new Fahrve. As an optimization, I delayed the movement calculations and collision detection until after drawing the new objects. This bought a little time, but not enough to meet the required deadline.
Something else I was doing sloppily was erasing the platforms. For this I was actually using the same routine I use to draw the platforms but with the data changed to use the background color. The new multi-color platform drawing code takes longer to do its job, and using that routine for erasing the platforms made that take longer as well. I replaced the platform erasing code with a simpler loop, and this was enough to meet the drawing deadline.
So, there you have it -- multi-colored platforms are possible on the Apple II port of Fahrfall. There isn't much time left during the vertical blanking interval for any other drawing tasks, but right now what is needed are less time-sensitive measures -- like scoring! I don't think I'll be able to reach a totally finished game by the end of the month, but I hope to get a bit closer than I am now. If you are curious to see where I end-up, then you will just have to stay tuned!
Subscribe to:
Posts (Atom)