Leaderboard

Another authorized conversion to the TI-99/4A of programs appearing within COMPUTE! Magazine, from Volume 8, Number 5, Issue 72, May 1986, Pp. 38-49. This game appeared after COMPUTE! Magazine dropped support for the TI-99/4A. From the article: I am working on another program and took a break to cast eyes on this. I was surprised to feel it is good enough to present in its original form and I will come back to it later to spruce it up. My TI-99/4A conversion is built to appear like the Apple II version. I felt it was a superior presentation to the other 8-bit systems, the ST version looked horrid, and I would be hard-pressed to duplicate the graphics of the Amiga version. While this is another tackling during my early programming years and could use a rewrite and optimizing, the end result is not terrible. I was concerned about its performance, but playing the C64 and Apple versions in emulation I find that it is pretty much on-par. In fact, with some optimization and a version for Extended BASIC, it could out-perform the original versions. While comparing the game in emulation, I was reminded the Apple II version does something really cool with the hour hand. The hour hand is positioned commensurate to the minute hand. For instance, the hour hand is half-way between hours at the 30-minute mark. I remember typing this game into the class computer and playing it, but I had forgotten about my deliberations on replicating this and deciding it was too much graphics to work with. Apple II screen on left showing hour hand proportionate positioning, versus the Commodore 64 screen on the right in which the minute hand covers the hour hand. TI-99/4A Conversion My conversion was written on a console with only the Program Recorder. I discovered in later years that if the final COMPUTE! authorized release from 1990 is run on a system with a disk controller, the program runs out of memory even after issuing CALL FILES(1). This post includes my original 1988 version, only. The two should be functionally the same, just in 1990 I included the COMPUTE! disclaimer which is a lot of text. HDD1988.zip

Indeed. To be clear folks - there was no source code to work with here. There is no ability to re-write sections of the game or make the code more efficient or add/improve on aspects of the code as typically presented. What @RevEng performed is a labor of love, to state the least, very time consuming to reverse engineer the game and its respective display generation to get it even working under NTSC. The fact it is playable at all and contains such relatively little glitching is astounding.

*** UPDATE: 12/7/2023: Turbo Arcade is now available for purchase, both as a ROM and cartridge, in the Champ Games store! *** UPDATE: The first public demo ROMs for Turbo Arcade (NTSC and PAL60) are now available for download on the Champ Games ROM Demo Download page. Have fun! Hi all! Last night on @ZeroPage Homebrew's Twitch stream, Champ Games revealed the "secret game" that we've been working on the last few months: Turbo Arcade for the 2600! Turbo is a 3D racing game from the early 80's (1981 to be precise) that featured state-of-the-art scaling graphics. @Nathan Strum has done an amazing job bringing these images to life on the ol' 2600, including full screen four-color scrolling backgrounds (inspired by @cd-w's Zeviouz kernels) and managed to capture all of the iconic scenes from the arcade game, including the city, tunnel, wall, bridges, snow forest and many more! Nathan also stepped out of his comfort zone and provided the sound effects , but if anyone is interested in 'checking his work' we'd appreciate the help! The game currently supports joystick for control but we are hoping to add in driving controller support. There are two modes of shifting supported: automatic (the game automatically shifts from high to low and vice versa when necessary) and manual (the player manually shifts to low or high gear). Due to the large number of data needed for the 150+ scenes and 300+ frames of animation in Turbo Arcade, the game uses the new 64K CDFJ backswitching scheme. Currently this is not supported by the Harmony or Harmony Encore but Fred aka @batari was gracious enough to send a loaner development 128K Melody board to myself, Nathan and James so we could develop, test and reveal the game on real hardware. Thanks Fred! The game does run on the latest version of Stella; I will need to test the ROM on other emulators to confirm whether it works or not. A demo ROM is expected to be made available in the next week and will be available on Champ Games ROM Demo Download page. If you haven't already, be sure to check it out for the latest demos of RobotWar: 2084, Lady Bug Arcade and Gorf Arcade (all expected to be released in 2021), as well as final demos from the released versions of Galagon, Wizard of Wor Arcade and Mappy. The full version is not expected to be released until sometime in 2022. We will post updates here, on our FB site and on our webpage as they become available; in the meantime, here are some screenshots from the current build of the game (which we estimate to be about 70% done): Title screen: Start of race in the city: Limited visibility in the darkened tunnels: Be careful on the slippery surface in the snow / forest scene: You lose sight of the opponent cars as they dip behind the oncoming hill: Slow down around the sharp curve overlooking the ocean! Avoid the ambulance as it travels through the streets with it's sirens blasting!

It is as good as it will get, more than enough time has already been spent on it. Maybe now the "POKEY = NEVER" makes more sense to some, no cycles for it.

Tested Toki on multiple different televisions to note the differences: On a CRT screen the story intro for each level is partially cut off on the PAL version but fully visible in the NTSC mod. When playing the game, you can see the entire screen on the PAL version, but the scores on the top are cut off on the NTSC mod. On a LCD screen the story intro for each level is partially cut off on the PAL version but fully visible in the NTSC mod. When playing the game, you can see the entire screen on the PAL version (bottom aligned) and the NTSC mod (top aligned).

A short story: A few years back I was browsing r/speedrun when I stumbled on the Dragster drama. Someone looked at the assembly of Dragster and created a sim in an attempt to figure out if a certain someone's world record time was actually achievable. Having done quite a bit reverse engineering of Ocarina of Time, and dabbled for a day or so reversing The Legend of Zelda for the NES to figure out the heart container glitch, I figured I'd might try my own hand at it despite never having played an Atari game in my life before. Though I never got too far into understanding the code, I was amazed at how you can print the entire game on only a few pages of paper, and finally understood how it was possible to do animated sprites with so little ram. Fast forward to this year. I'd just replayed The Legend of Zelda on the switch (both quests of course), and I got it in my head that I wanted to make an Atari 2600 port. So here's how far I've gotten: The game is written in 6502 assembly. To create the sprites I use a GCS program called MegaZeux, which has a pretty nice built-in 1 bit sprite editor. I also coded my world editor in MegaZeux, using it's "robotic" language. "Robotic" can be fairly esoteric at times, but it's the first programming language I ever learned and it was the easiest thing I could think of to use without rolling my own rendering code. I also use Python 3 for data manipulation purposes. For example, in order to save rom space I use a superstring algorithm to pack the sprite data for the text kernel tighter. Additionally, the music sequence data is completely generated by Python, so that I could write music using proper notes instead of numbers. I can't say for sure that I will continue working on it, as I hit a bit of a wall and decided to switch gears to a different thing I'm working on. But I don't think I'll stop working on it for good just yet.

I had previously posted on another thread about a good candidate for replacement cables for 600/800XL keyboards and have since gone ahead with ordering some and testing them. These are the TE Connectivity A9AAT series flat flex cables. They are not available in 24 conductor, so I used two 12 conductor cables with the solder tabs. This allowed easily soldering in the keyboard side of the cable, while the tabs plug in neatly to the pinch connector. It does require careful alignment of the pins, however, but they seem to be quite secure, and the keyboard is now working great with very little effort. Just keep in mind to be very careful desoldering the old cable from these cheap single-layer circuit boards, they are quite delicate. Part numbers: TE Connectivity AMP Connectors A9AAT-1208F 12-conductor 8" (the A9AAT-1206F 6" cable can also be used) For the function keys: A9AAT-0803F (3") or A9AAT-0802F (2"), depending on the keyboard

zaxxon8.bin

You may not, but I would have a problem with it not being accepted. You did what anyone else has the ability to do, your technique was within the confines of the programming, no glitches were used, there is a limited amount of distance that can be covered, and the game has a definitive end... you just happen to be the first to maximize scoring opportunities within that distance and max it out. I think this should be allowed to stand.

Um, because this site is AtariAge, and AtariAge happens to be probably the largest publisher of carts for retro-systems in the world today, maybe? Or did you not realize the site has a Store?

I never cease to be amazed at how a little nostalgia turns into a hobby turns into a community service to like-minded folks. Thank you @RevEng for your reverse-engineering!

Here's a YouTube video showing the first couple of rounds of Turbo Arcade (be sure to watch at 60fps):

I'd be wary of blaming playtesters for bugs in a game. Often they do this work for a pittance, and purely out of a love for gaming. Bugs are a developers' responsibility, and they will almost for sure get through most testing processes. It's a shame that these bugs (two I know of) have made it through to production. The real issue here is how Audacity responds. I know that a severe bug in one of my programs led to me doing a recall, which was a bit of a personal disaster, actually. Edit: I'm not suggesting/implying there should be a recall. My point being, a bug screws everyone. Developers don't want to release games with bugs. Consumers don't want to play games with bugs. Playtesters don't want to feel responsible for bugs.

I have just updated my posts with the explanation that can be seen in the youtube description. The graphics glitches appear because it is the PAL version of the game being played on an NTSC console. If the PAL version were played on a PAL console there would be no glitches. The NTSC mod resolves most of the glitching, but it introduces a little slowdown.

Some scenes (the city, tunnel entrance and curved wall) use the PF above the horizon. The city was the first one done, so I never considered not using it. That's how I was drawing everything when those were designed, and I do like the consistency of it. We could throw some sprites in there for extra detail, but we're already using that space for the warning flag, and we may end up putting other sprites up there. There are different transitions: pre-rendered (tunnels, cities, curves); and ones done on-the-fly wiping from one scene to the next. At some point, everything should have one transition or the other (or a combination of the two). We're mostly trying to match what the arcade game does, but have made a few improvements like lengthening the transitions in and out of the curved roads to give you a bit more time to react, and adding a cleaner transition out of the curved wall. Not sure we'll add one into the curved wall or not (there is none in the arcade game). Anything pre-rendered like that comes at the expense of ROM, and we ran out. But as we have the time and space to clean up the transitions, we will. When John first showed me the transition wipes between scenes, I told him, "Okay... you're just showing off now!" I really wasn't expecting to see that. Most of the arcade hills are darker in the distance (the lower elevation): There are a few that are the other way: I suppose either could be correct - it just depends on if you think the crest of the hill (where the car is) is in the sun or the shade. I think having the darker color in the distance helps it feel like it's at a lower elevation. In the arcade game, the hill scrolls all the way off the bottom of the screen. Ours does too (in terms of road width) but the upper-half color does not. The standard color replaces the darker one as the hill scrolls off the bottom. This is what our hills look like now (this is what my Photoshop files look like, BTW): You can see the narrower road being "pulled" all the way to the bottom of the screen. It's really kind of a cool almost "wave" effect. I did suggest that we pull the darker color all the way to the bottom, along with the narrower road: But this was really, really late in development, the display engine didn't support it, and we were trying to get some gameplay in there before the reveal . Also, we'd be "stuck" at a darker color set until we could throw in another transition to get out of it (as shown above). But it's something we'll likely revisit later. I'm still completely amazed John managed to stuff everything into the game that he did, in the amount of time we had. The hills were a pretty late addition (although we had always known we wanted them). I didn't notice the glitch at the time, but I wasn't watching the video much since it was so far out-of-sync with the Zoom call, and I was also trying to read the chat. But it could be James' system (again). It's not there on real hardware (on my systems). The only older Turbos out there are your April Fools version, the prototype (which I don't believe has ever had a ROM release), and the mockups in my blog that I did while the prototype was being worked on. I posted links to those, which I'll post below in another response.

Regardless of the debate of counting or not, I am impressed by your patience to move through the course that way and finding that can do this! I don't think I would have the patience to pull this off.

The capacitor (C65) is connected to the Red output line (for the RGB video) and there were no visible (to me) symptoms. It was more a feeling that something was out of place.

Just an aside, though. I would like to think there's room for everyone in the community. If their product isn't quite so good as expected -- well the expectations were certainly very very high, weren't they. If the product is not quite up to those expectations, just remember that if/when making future decisions as to from whom you buy your next game. A couple of bugs sneaking through, and issues with boxes and labels are unfortunate and don't happen generally with AA because of the literally years of experience and the community contribution to quality. But hey, they've had a go, and actually got product out the door - and kudos for that. Their game sold possibly approaching a couple of thousand units on the reputation of the programmers/company alone, and that's got to be good for the community. I don't particularly love the way Audacity is distanced from our community, basically lurking here for at least 5 years without any interaction at all and possibly benefiting from the sharing of code, tools and techniques that happens here. But I do like that they felt motivated enough to have a go at releasing product on the '2600. I'd like to see us support everyone who writes games, and likewise I'd like everyone who writes games to participate in the homebrew community. "Professional" aspirations or not, CC is quite the achievement.

Hi all, Lately I've been trying to put the source to some of my old projects online and the latest is AStar. Check out AStar on GitHub. This version is different from the cartridge release. Just for fun I decided to modernize the solution finder and make a few new levels - there are 8 in the attached binaries. If anyone is interested, making your own levels shouldn't be too hard since they're just plain text files. The updated solution finder generates assembly source with an optimal move count usually within a couple seconds, which is about 10000 times faster than the version I used for the original game. Memory card support is still present in the source, but has been disabled since the levels are different and I didn't want anyone's progress on the cartridge version to get wiped out. astar-free.zip

Keep in mind, the 7800 was designed with a cart audio line to support whatever sound chip option was present in the cartridge. POKEY happen to become the only thing leveraged for the original retail line for a variety of reasons, but not due to system design or intent. Much more advanced than POKEY, the Minnie chip - WaveTable synthesis for the 7800 - during the mid 80's. Actual prototypes already designed, produced, and sound played from it in GCC hallways. 7800 8BitDev has the complete details and capabilities. What we hear from Rikki & Vikki is well within what could have been heard similarly from the 7800 during the late 80's (or sooner), just presented through different hardware means.

'YMMV' here is worth a mention. Depending on the number of visible lines for a particular CRT, it can have a significant impact on the results. One NTSC display showing only 215 lines, as opposed to another showing 239 lines, will both demonstrate significantly different from the 224 lines average. Under a 1983 NTSC Commodore 1702 monitor (Just like the ones Al uses at many of the expo shows), NTSC Toki, both intro story and score, are completely visible.

I posted these links in the chat last night when James' computer decided it could no longer handle the awesomeness of what the 2600 was doing . I had sent these to James to show/link during the stream as a kind of history of Turbo on the 2600, but that never materialized. So here they are now for your perusal/bemusement. Turbo arcade game (video) : I threw this video together really quickly, since a lot of the other YouTube videos either use cheats or are of poor quality, or have too much talking. (I didn't make it to the red bridge though...) Coleco catalog listing Turbo for the 2600: https://atariage.com/catalog_page.php?SystemID=2600&CatalogID=18&currentPage=5 Anyone who ever bought a Coleco game has probably seen this. Along with Cosmic Adventure and Lady Bug, Coleco never actually released Turbo for the 2600. Promises, promises. But Champ Games will have done 2 out of 3 after Turbo Arcade is finished. You're welcome, Coleco! Intellivision version (video) : Avert your eyes! Well, at least they got a version. It did come in handy for one thing: when we were putting the box together for the AtariAge prototype reproduction, we bought a CIB Intellivision copy off eBay so we could scan it. ColecoVision version (video) : This was the only game I ever would've considered buying a ColecoVision for. Electronic Games Magazine "review" of Turbo: https://archive.org/details/1983_Software_Encyclopedia_Number_1_1983_Reese_Communications_US/page/n31/mode/2up From their 1983 Software Encyclopedia. They probably saw it at CES that year. Maybe Coleco sent them a WIP version. Who knows? But this ruined my life because I kept waiting for Turbo to show up for the 2600 for years. Resellers even listed it in their ads in the back of the magazine. But of course, they'd probably just gotten a list from Coleco saying "Coming soon!" Maybe even a flyer... Coleco promotional flyer (at AtariMania) : "Actual game screen may show variation from illustration above." Indeed. 2003 April Fools version (based on flyer): Thomas Jentzsch (and others) conspired to pull off this April Fools prank, based on the above flyer. 2006 Discovery of the actual prototype: Just three years later, the real thing finally appeared. There's a link to the original prototype ROM in this post. AtariProtos write-up about the Turbo prototype: http://www.atariprotos.com/2600/software/turbo/turbo.htm Essential reading if any of this has been of interest to you so far! AtariAge release at CGE2010: https://atariage.com/features/shows/cge2010_preview/new_games.html The prototype (and an enhanced version) sees the light of day in a boxed release. Hard to believe this was over 10 years ago... And finally... The Turbo that never was: My blog write-up about my involvement with the prototype project, my desire to make a better Turbo, and some concept mockups from 2009 that eventually led to, well, this!

These are the latest binaries. The only differences here to the last set of files are: - title screen text has additional credits - the system reboots on exit from the game INNUH-TI-EN-40.zip INNUH-TI-IT-80.zip INNUH-TI-IT-40.zip INNUH-TI-EN-80.zip

Sounds like the mistakes some amateur homebrew clowns would make, not some big badass studio

Thanks! Yes - that wall transition is very abrupt. If you step through the video I posted of our version, you'll see we did add an exit transition to it. It's very fast, so it's more visual than functional, but it's a lot cleaner looking that what the arcade game does (which is apparently just turning off different layers of graphics as you leave the scene). The wall scene is always preceded by a curved section of the road facing the same way, so at least you aren't doing something horrible like suddenly jumping from a right-hand curve to a left-hand wall. If I can figure out some way to bring that curved wall into the scene (without gobbling up tons of ROM) we may add a transition there at some point. But we don't want to "fix" too many things from the arcade game either, because those are all gameplay elements that have been baked into the history of the game for 40 years now.

Fair play to you for posting it on a couple of points. Firstly for making a clear how you've played, and giving people the opportunity to protest if they feel it not in the spirit of things. Fwiw, my own take is that it isn't quite in the spirit of things, but Zilch is probably right that you haven't actually done anything wrong here given the parameters of the game, so there's no reason not to let the score stand. The game should really have been written in such a way that the event ends if the timer reaches zero. But it wasn't, and you played within the rules as they are Secondly (and perhaps more importantly), seeing that those kind of scores are achieved only by playing that way reassures me that I'm not going mad ?. I really enjoy this one, and have probably ended up playing it more than most of the games in the HSC. I got to about 38,000, which I thought was pretty good. Then I saw a couple of scores way into the 40s, and thought they would have to be something close to perfect runs. Then I saw these really big scores and just thought , how ?!?!?!?!?! And now I know, so thanks !. Personally I just haven't got the patience to rack up a score in that way . . .not least as I think the game is too much fun, and I wouldn't last long at all before the temptation to play in a more conventional way would just get too much

Zilch....I understand your point of view...its bad programming to have a game make this kind of point grinding possible. I have no problem with the score counting as is....but this seems very obviously a loophole to being considered leeching...but still should be considered leeching. Again I really dont have an issue with this at all....just wanted to share my two cents. Thanks guys & gals.

Kinda cool this... So @Asmusr makes "Raphael" and does an adjustment so that I can use his tool, to EASILY get out HEX data. That inspire meg to try some animations as I now QUICKLY can convert graphics to HEX. Then a "tiny" question about speed and "The Running man" is sprinting his ass off! Hahahaha, I love this forum! So cool that people share their knowledge, willing to help and have fun. Thx to @Asmusr @Lee Stewart @TheBF @RXB I got two cool "WOW" moments today!

As the string says, "I'm a frayed knot." But, I did get my 1990 version to load into Classic99 using CALL FILES(0) and loading it from tape. In 1990 I added the hands to the controls area at the bottom, and also made "H" and "M" advance the respective hand, while "1" and "2" move the hand backward. This was to help compensate for the performance lag in drawing hands: if we start at 12:00 and the time to match is 11:55, a lot of time is spent getting there. I had considered starting the hands from random positions, as well, but that is not part of the original game. I also found a couple of my original graphics worksheets so when I do the 2021 release it will be included.

Congratulations to Italy. Best Eurovision winner in YEARS!

It's funny to see that Lee and I were both thinking about this. I could not take the time yesterday to re-write it but I wanted to. So you can think this through for memory usage by looking at Lee's code. We can see the program lines are small and the data lines are most of the code. Each frame of the animation here is using 64 characters on the screen, but they are they same characters reused so that's not a problem. The pattern data to re-shape the characters is using the space in the program. Counting the bytes in the data lines I see 8960 bytes. So that's a lot of memory for our little machines. You are full with 2 or 3 animations Some solutions come to mind in order of difficulty: You reduce the size of the pictures. You could do the animation with one character images but it would not be as interesting. You record all the data for each animation as records in a disk file and read them into memory one at a time to show them. Of course you need a program to make the disk file as well. There are a lot of zeros in the data so some kind of compression method could be used to like "run-length-encoding". This would count the zeros and just record that number in the data. Then to remake the picture it outputs the correct number of zeros as a string and correctly glues the other data to the string of zeros. Kind of tricky but doable. And of course the best solution would be to make an animation language that lets you play the data faster with a simple set of customized commands. How could we do that... let me see... how about Forth! (That's a big learning curve)

You'd probably want to stylize it differently, but yeah I think the 7800 could run a decent facsimile. Sure, we've had enough of those threads. My point is moreso that everyone else ditched the stone knives and bear skins by the late 1980s, which drastically affects not only what the hardware can do - but the ease of working with it. That makes a significant difference.

Well, thank heavens they don't consider themselves Homebrewers then! I don't think we could afford that sort of damage to our reputation. (Mostly kidding.) (Seriously. I love Laser Blast.) (And Space Jockey.)

Going to need multiple pictures for this one.... I saw someone roll, and you know this season when I see top play it raises my play... So.... here's a roll at 100,000 (100,150 to precise, right after scoring the 2nd frog into home. Note the "Extra Frog", it's the last your going to see ALL GAME lol Then, we go on and on and on, and this happens... That's right, a SECOND roll of the scoreboard. I lost that frog due to trying to take a pic of the roll and hence the time ran out on it. Poor little froggie... And then, the end on the final life nets... Final Score: 211,870

Hello fellow Atarians, picked up this item on ebay back in 2011. I used to run a search for "atari prototype" and if anything looked interesting throw in a bid. Won this item sold by a seller in Maryland with a description of "Mock-Up for Happy Drive CPU", stored it away and found it in the closet the other day. Thought you might enjoy checking it out. Cheers!

HoW dO i gEt oN tHe LiSt??!

I have completed all the boards. For me, the game is done. One of them is random. Here are the screens: (sample screen as they are random )

Youtube video of NTSC mod of Toki on NTSC console. This is an NTSC mod of the PAL version. The NTSC mod substantially reduces the graphical glitching when the game is played on an NTSC console, but introduces some occasional slowdown as well as some screen judder during vertical scrolling.

For those that haven't looked, Djaybee is not only posting his cracks (which are the best form to me, absolute minimum required to remove copy protection), but he also explains each crack in detail with the archive.org posts, including a summary, disassembly, and comparison of the before and after states. It's really great stuff, I've found myself looking up a couple of games I tried to crack myself back in the day.

Vocelli: Updated Scores. Spikes Peak: 25700 BMX: 84250

Capacitor installed with wrong polarity?

The stream last night was great, despite the crash. You and Nathan have done an amazing job with this. And the info of how Nathan did the graphics. Amazing. Looking forward to this one. You both did it justice for the 2600. Looking forward to the demo release and all the other things you have planned for it. High five!!

So, new discovery ... a stable C distortion bass without need for polycounters! Here's how: AUDCTL=$41, set two tone mode, distortion 4 in channel 1, silence 2. In channel 1, use mod 15 values, starting at $0B then every 15 steps. The higher, the fuzzier it sounds. In channel 2, your frequencies are in this pattern: T1, T2, T2, T1, silence. They correspond to mod 3 C distortion timbers, but stable regardless of polycounters. Chart attached. Values are for T1, T2, and normal C distortion at 15 khz. The range is a bit better here.

For those of you who missed the live broadcast of the premiere of Turbo Arcade last night and the interview with @johnnywc @Nathan Strum on the ZeroPage Homebrew Twitch stream, it's now up on YouTube! Thank you again to John and Nathan for making an truly astounding game and blowing everybody away with incredible innovations that are sure to change the landscape of what we thought possible on the 2600 (once again)! - James (SET VIDEO TO 1080P60 FOR FULL QUALITY)

The tile textures and giant sprites make this 7800 version quite charming. It will be just me, but I also like the audio. I'm glad this is finally becoming a reality, a big thank you to everyone involved.

My boards arrived in Memphis this afternoon, just a few hours away. So with any luck, I'll have them in another couple days and I'll be able to verify I didn't screw up such a simple layout, lol. And not a moment too soon - I went to play ALIEN BRIGADE tonight only to find I'd snagged my contraption in the last couple days and pulled one of the wires free from the terminal block connectors I'm using. D'oh! Fortunately that was a quick fix. Soon I was blasting the ever-loving frak out of green a-holes again. I managed to clear the first stage and get through most of the second before I died. The game is SO much more fun with a light gun than a control pad or joystick.

Just finished up my library catalog with DISKODEX. As of this minute, I have 17,134 files spread among 1039 disks. It worked out quite well!?

Mmmhmm, I've found that most of the stubborn issues involve too strong of a focus! Clearing the mind is often the better part of the solution.

Breaking news: Scamming on Atariage. The Last Squadron has been caught , mime Terra Cresta. 8-bit police investigating

The intention is still to release the game as originally planned, hopefully soon. Appreciate everyone's patience so far, especially those who are involved in the release. Will be updating this thread a few times over the next week.