Dionoid

Note that the packaging and cartridge label artwork for Amoeba Jump was done by Nathan Strum.

Thanks Darrell, this NTSC/PAL/SECAM detection is really useful! In your games that implement this detection technique (e.g. Draconian) I see that you still offer the option to change the TV type on the menu screen (with the detected TV type pre-selected). Is this because the detection isn't 100%, or just to give people the option to change it if they want to?

Hi @AW127, I'm not sure why you're posting inciting messages like this about ARM-supported games. My guess is that your opinion is based on incomplete/wrong information, so let me try to give some more color to that. First of all, in the ARM-supported games like Galagon, the ARM is used as a co-processor. The 6507 CPU still runs the show, as it is the only chip that can address the TIA (graphical chip of the '2600, responsible for all TV output). Please read the posts from @batari in this thread; he actually is the inventor of the Melody/Harmony boards, and worked together with other people on schemes like DPC+ and CDJF. The first time a co-processor was used in a '2600 game, was for Pitfall II, released by Activision in 1984. They called this co-processor "DPC" and it allowed for better graphics and music (although I personally don't like the somewhat noisy and hissing sound). While this technology was released after 1983 (which for some people in this thread is the magical cut-off year), I don't think anyone back then considered Pitfall II to be "not a real Atari 2600 game". Some of the "technical facts on ARM-support" in this thread were actually wrong, so there was some discussion on that. I don't recall anyone in this thread referring to ARM-supported games and saying that they "saw it not as a Atari-2600 game anymore". I'm not sure why you draw this conclusion. Until now in this thread, it looks that you are the only one saying that ARM-supported games are "not real Atari 2600 games". The only German people in this thread are you and Thomas, right? So when you refer to "these people", you basically mean Thomas. And I never heard Thomas say that ARM-supported games are "not real Atari 2600 games"; I know that in this thread Thomas brought up the magical cutoff year of 1983 (in that year both bank-switching and extra RAM were available, but Pitfall II wasn't released yet), but these are his personal self-imposed restrictions for writing '2600 games; just as every '2600 developer has his/her own set of self-imposed restrictions, otherwise we wouldn't be writing games for that old system. If you don't mean to say you "hate" these games or "condemn" these programmers, then please don't use these words at all. Words like that tend to stick in the back of people's minds (even if you said that you mean the opposite). And in this quote you're referring to newly released ARM-supported games (like Galagon) as "so-called Atari-2600 games". That sounds both really rude and ignorant. Of course Galagon is a highlight on the '2600! Just as Draconian, Aardvark and Boulderdash to name a few. But we all know that these are homebrew games and were not released during the active life-span of the '2600. And yes, we nowadays have better software tools, better hardware, and better (shared) knowledge on the '2600, so comparing them with games from the '2600 heyday doesn't make much sense. I appreciate every new homebrew game that's released for the '2600, no matter if it's using the original limits (4K ROM + 128 bytes RAM) or using extra ROM, RAM or co-processors. These C64 Super-CPU games you mention, require you to have a SCPU built into your C64, right? That means these SCPU games won't play on unmodified stock C64 machines, so that is where your comparison fails. For me, using ARM chips as co-processor in the '2600 is a natural progression of the hardware. Quoting @Random Terrain: "If you can plug a cartridge into an unmodified Atari VCS and play it, it's an Atari 2600 game. Doesn't matter if it has 20 gigabytes of RAM and a magical half-unicorn fairy living inside of the cartridge."

Hi @Andrew Davie and @TwentySixHundred, I don't think Andrew's explanation of the Melody/ARM was fully fact-checked, so you might also want to read into other threads on the AA forum. Note that I'm no expert on '2600 hardware myself, but I did read some threads about the Melody/Harmony, so I'd like to respond to things and put them into perspective. There are no finished Atari 2600 games using "bus stuffing" at the moment; I've read that it was found to be unstable on certain '2600 machines. I know there is a demo version of elevator action using bus stuffing, and that it's on hold since beginning of 2018. I doubt that any external processor could directly 'talk' to the TIA chip; if you look at the buss-stuffing code examples, you see that the 6507 is still doing the writes to the TIA, and only the value that it writes is being 'bus stuffed' directly on the bus. Currently released games that use the ARM as co-processor (e.g. Mappy, Draconian) are based around some form of DPC+ (improving on David Crane's DPC chip in Pitfall II). The latest framework for running DPC+ games is called CDJF, which does a lot of the plumbing for you when sharing RAM between the 6507 and the ARM chips. To put that a bit into perspective: a standard melody supports 32K ROM and 8K RAM. If you use the CDJF diver, you'll be down to 6K RAM (which of course is still a lot compared to the standard 128 bytes RAM). The ARM processor in the melody runs at 70MHz, which is almost 60 times faster than the 6507 @ 1.2MHz. Because reading/writing data from ROM is still relatively slow, I would say that in practice the calculations can be around 50x as complex, probably even less. So certainly not "many hundreds of times". Assembler code is actually more in my comfort zone than C, but maybe that's because I had to learn about C's pointers (and pointers to pointers). Note that when you write '2600 games with support of the ARM chip, you have to be very proficient in *both* 6507 assembly and C. And you still have to know all of the TIA tricks 🙂 I don't see why the "contract" between the 6507 and TIA changes? IMO the ARM is just making the 6507 smarter/more dynamic; the 6507 still controls the system. I think that DPC (invented by David Crane for Pitfall II, which was released in 1984) was the actual game changer, right? And of course bank-switching and additional RAM were also game changers. Finally, to me as a developer, Stella is the actual game changer!

Hi, I found something that looks like a bug: when you shoot a tank in the upper right corner of the maze, your helicopter will instantly die every time you re-spawn. Of course I should have known better than to shoot a tank at that position 🙂

Yes, I even experimented with allowing players to pass each other. However, I wasn't happy with the result, as there was no interaction between the players anymore (i.e. blocking and strategic positioning). And also when the players moved into the same tile, the graphics looked weird and it was hard to distinguish the blue from the red player. However there's going to be an 2-player AI mode (you against the CPU).

Thanks! Glad to hear you like the game. Yes, this game is still very much on my radar. Actually I'm working on two games concurrently; this Tower of Rubble and a remake of a well-known game where you run for lode of gold 🙂

A thing to mention is that char values are *unsigned* by default on ARM/gcc (I learned that the hard way 😒). So you might want to change that in your inline documentation on Variables in the file main.c Or add the compiler flag "-fsigned-char" in the Makefile, which tells the compiler to use singed chars. Looking forward to Part 6 !!!

Thanks, Dennis! Did you find structures or algorithms in the code that you didn't see before? E.g. those interleaved graphics? And the six digit display is an amazing clever 'trick', so hats off to Bob! I wonder why they didn't bother to change the colors for the PAL50 version of Football. Having a blue football pitch for sure didn't help to make Football more popular in Europe 🙂

Note that when clearing the ARM RAM, you also need to divide _GameZeroOutStart by 4:

Thanks for the update, Darrell! Note that 'testrom' is still in the Makefile, which might be confusing for people (it was for me in the beginning). In my .asm code, I prefixed the names of the datastream buffers with _BUF_, so it was easier for me to recognize them. ; datastream usage for Game _DS_GRP0 = DS0DATA _DS_GRP1 = DS1DATA _DS_COLUP0 = DS2DATA _DS_COLUP1 = DS3DATA ... ; Game datastream buffers _BUF_PLAYER0: ds 192 _BUF_PLAYER1: ds 192 _BUF_COLOR0: ds 192 _BUF_COLOR1: ds 192 So e.g. in my C code it is clear that we're resetting the pointers to the start of the buffers. ... setPointer(_DS_GRP0, _BUF_PLAYER0); setPointer(_DS_GRP1, _BUF_PLAYER1); ...

Looking at the schematics of the Atari Paddle controller pair, if I want the Ranger's paddle to drive the second paddle, I should create an adapter that switches pins 3 and 4, and pins 9 and 5. Still that's too much work just for a singple-player game of Video Olympics 🙂

So if I connect pins 6 and 3, does than mean that the paddle works for both?

This is what the mapped WebDAV drive looks like in the File Explorer: So whenever I have an updated rom of my game which I want to test on my Harmony cart, I'll just copy it to the Z: drive. Then I need to switch my '2600 off & on to be able to select it from the Harmony menu. B.t.w. documentation on the CONFIG settings of the FlashAir is still available via WayBackMachine here: https://web.archive.org/web/20170816194335/https://www.flashair-developers.com/en/documents/api/config/

It seems that Toshiba has discontinued the FlashAir SD cards 😢 Also their developers website https://www.flashair-developers.com has been closed. Still I think that a FlashAir card - supporting WebDAV - is great for homebrew development, so I recently bought a FlashAir 64GB W-04 for ~$40. 64GB is way too much for me, but the 16GB and 32GB FlashAir cards seem to be out of stock everywhere (Edit: I just found that Amazon.de has the 32GB FlashAir in stock for €30) After more than 2 hours of trial-and-error, I finally got WebDAV working on my FlashAir... It was not a simple set up at all and it's not 100% stable, as sometimes the card is not responsive and takes a few seconds to wake up. Things I did to get it working: Updated the FlashAir card to the latest version (F15DBW3BW4.00.04) using the FlashAir W-04 Software Update Tool Formatted the card to FAT32 using FAT32 Format Initialized the card again using the FlashAir Configuration Software Changed my Router's DHCP range from 10.0.x.x to 192.168.x.x (not sure if this was really needed, but I tried a lot of things to get the WebDAV working) On my router, I added a DHCP reservation for my FlashAir card, using the card's MAC address, so my FlashAir will have a static local IP address. Modified the card's configuration file SD_WLAN/CONFIG to support WebDAV like this: [WLANSD] DHCP_Enabled=YES [Vendor] CIPATH=/DCIM/100__TSB/FA000001.JPG APPMODE=5 VERSION=F15DBW3BW4.00.04 CID=[YOUR FLASHAIR CARD CID HERE] PRODUCT=FlashAir VENDOR=TOSHIBA APPSSID=[YOUR WIFI ACCESSPOINT ID HERE] APPNETWORKKEY=[YOUR WIFI PASSWORD HERE] APPAUTOTIME=0 STA_RETRY_CT=0 LOCK=1 DNSMODE=1 NOISE_CANCEL=2 UPLOAD=1 UPDIR=/ WEBDAV=2 MASTERCODE=[YOUR FLASHAIR CARD MAC ADDRESS HERE (see back of card)] APPNAME=FlashAir Then on Windows I mapped my Z: drive to my FlashAir's WebDAV endpoint at http://192.168.0.5 (which is the static IP address for my FlashAir that I configured in my router's DHCP settings). Hope this helps someone to set up WebDAV on their FlashAir W-04 SD card!

I think they should have included that adapter to be able to control the second paddle (and make Video Olympics work!)

Hi Darrell, this contains a lot of interesting things! I will try to get the example code running on my machine this week. A quick question: when (re)setting the pointers for the data streams, why is the offset shifted by 20?

While I like the thumbstick, the paddle controller is disappointing. As it is mounted sideways, IMO it doesn't suit games like Kaboom or Breakout, where the paddle moves from left to right. It better suits games like Video Olympics (Pong) where the paddle moves from top to bottom, were it not for the fact that for a single-player game of Pong (player vs computer) the Ranger controls the wrong paddle! I can't believe the Ranger's paddle controller wasn't tested with a single-player game of Pong! Just try to do a single-player game of Video Olympics: it won't work!

DASM has moved to github! The dasm-dillon repository has left SourceForge and moved over to GitHub here: https://dasm-assembler.github.io/ The new home on GitHub is the official single point where the latest version of DASM is maintained and distributed. The DASM team These are the people that currently maintain DASM and contribute to its development in one way or the other: The DASM team Get the latest DASM version [09/15/2020] Released DASM version 2.20.14. Some nice new features added. And finally there is a DASM User Manual (PDF) now! [02/19/2020] Released DASM version 2.20.13. Just like the previous version, this is a patch/bugfix release. [12/13/2019] Released DASM version 2.20.12. This is the first update to DASM in over 5 years! It's mainly a patch/bugfix update which includes the customizations that were done across the 7800AsmDevKit, batariBasic and the upcoming SpiceC toolkit. Bugs? Feature requests? Please report bugs or feature requests on https://github.com/dasm-assembler/dasm/issues. All versions of DASM are written in C. If you want to contribute we encourage you send us a pull request! Building a better DASM together.

Displaying the remaining 'free' time in the score-display works for me! Btw I found that using mod (%) or div (/) in C with anything other than a power-of-two number will stop execution of the Thumb routine that was called. Converting an integer to an array of numbers is clearly not the way to go on an ARM CPU 🙂

PlayerPal 2.1 is a great (online) tool to create player graphics for the 2600. I've converted PlayerPal to a Windows application (using AppMaker), just in case the PlayerPal website ever goes offline: PlayerPal-windows.zip

Hi James, your suggestions make sense. This would make it easier to control both the helicopter and the shooting direction.

Hi, is beta2 still the latest community firmware version for the R77? Just asking, as I want to put the latest version on the machine.

This game is extremely addictive! For some reason I end up crashing into the tanks a lot when I chase them too closely. It would help if there was an option to only change the direction of the gun/shots without moving the helicopter. Suggestion: if the helicopter is not moving and then you press & hold the fire button, moving into a direction would only change the direction of the shots and not actually move the heli. If you release the fire button, then the heli would stop shooting and start moving again. Anyway, this game is fun!

Thanks! Yes, it makes sense to use the score to display the remaining time for Vertical Blank and Overscan. I guess I first need to get the score-display routines working 🙂