Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

830 Excellent


About Dionoid

  • Rank

Profile Information

  • Gender
  • Location
  • Interests
    Everything Atari 2600, Atari 7800 and Atari 8-bit.

Recent Profile Visitors

5,376 profile views
  1. Hi Steve, great to know you joined AtariAge!! Thanks for writing the Stella Programmer's Guide, which still helps me a lot when developing games for the Atari 2600. It was my pleasure to format your guide into a book version. -Dion
  2. y Received my copy this week. Nice green cartridge and awesome game!!! If you like Xevious or 1942, then you'll going to love this game.
  3. Hi @Albert, maybe someone else already asked this before, but were you in any way affected by the global chip shortage when assembling these carts?
  4. While the ARM7TDMI-S microprocessor used in the Harmory/Melody only supports 8, 16 and 32 bit data types, I found that using 64-bit integers is allowed when doing bitwise operations only (bitwise and, or, shifting, etc.). I'm currently using an unsigned long long variable to create on-the-fly 48-bit wide graphics, and also for masking and validating a 35-bit wide password (i.e. 7 BASE32 characters). Sometimes 32 bits just isn't enough 🙂 Note that doing calculations with 64-bit integers isn't supported, but at least all bitwise operations are. Maybe these 64-bit tricks could come in handy for other developers too.
  5. The cart version contains a few extras, like an optional two player alternating mode (featuring Ms. Amoeba) and SaveKey support. But the single-player game is the same. Also, the cart version gives you the manual and box (optionally) with great artwork by Nathan Strum.
  6. What an amazing set of sprites, @PAC-MAN-RED! I've been experimenting with the protagonist sprites (Bub and Bob), in order to get them more recognizable when displaying on a '2600. Below you see the original NES sprite on the left, in the middle the conversion by @PAC-MAN-RED and on the right my best attempt so far.
  7. The performance option shows me 60fps, but my game is still having hiccups and feels like it's running at 70% of the normal speed. Still, I think this is a very promising '2600 emulator and debugger!
  8. Hi, here are some hints for pushing your highscore on Tower of Rubble - from the developer: The normal 1-player mode is deterministic, so it follows the same pattern each time you play it. If you keep getting killed at a certain point/time in the game, try to move to a different position/island the next time you're nearing that point. I.e.: If you got killed, next time move the other direction. Try to position yourself at the highest point, as jumping down is faster than climbing up. When you find yourself being killed in the middle of the screen by disintegrating/sinking rubble blocks from both sides, you need to perform the "island jump" to move to one of the islands left or right. Before you do an "island jump", be sure that the destination island is at least 2 blocks wide, so you have a way to escape the falling rubble blocks. The laser beams only kill you just before they disappear. When staying in the beams for a longer time, there are sometimes more ways to escape a "locking in" situation. But sometimes the game still "locks you in", and you don't seem to have a chance. That basically means that you had to choose a different path (or run to a different "island") maybe even 30 seconds before you died. There is *always* a way out.
  9. Wow, that "bended scanlines" TV mode is really nice. I tried the latest release with a CDFJ rom, but noticed that the performance is not on par with playing on a real '2600. Could the new Go compiler help with this?
  10. Here are some pictures of my breadboard-setup of @SvOlli's Rom Dumper, but this time using an Arduino Nano, for which I added the code to his retrocartdumper project on GitHub. Note that the Nano has the bare minimum of the required 20 GPIO pins for dumping of Atari 2600 cartridges. I had to connect the cartridge's address A12 signal to +5V, which basically works as the chip-select for the ROM. This means that only bankswitching schemes are supported which use hotspots within the cartridge ROM address space. For most cartridges brands (e.g. Atari, Activision, Imagic, CBS, M-Network and Parker Brothers) this is sufficient. If you need support for dumping TigerVision's 3F or Superbanking cartridges, please use the Teensy++ 2.0 microcontroller instead. Also, since the A6 and A7 pins on the Nano are analog-in only, writing to the the data bus is not supported on the Nano, but only on the Teensy. Picture of dumping a PAL Fatal Run cartridge (which has F4 bankswitching + SuperChip) using a cheap €5 Arduino Nano clone: Note that I had to lift the 24-pin cartridge connector on its legs as high as possible, because the connector wasn't tall enough to give the cartridges enough clearance when inserting them.
  11. Thrust+ is even better when you play it with foot pedal + driving controller!
  12. I was able to get dump2600.exe working with the Nano at 38400 baud, by disabling some lines in windows/serial.c. I basically removed most of the DCB settings and only kept BaudRate, Parity, StopBits and ByteSize. So apparently one of the other settings was conflicting with the Arduino/CH340 driver. @SvOlli Could you please test if dump2600.exe still works for you, if you only keep these settings in windows/serial.c? memset( &dcb, 0, sizeof( dcb ) ); dcb.DCBlength = sizeof(dcb); dcb.BaudRate = baud; dcb.Parity = NOPARITY; dcb.StopBits = ONESTOPBIT; dcb.ByteSize = 8;
  13. It's an 328P with a CH340 USB to Serial chip (instead of an FT232 chip)
  14. For the Nano, I've wired the cartridge's A12 signal to +5V, as I had no more free IO pins. This means that on the Nano, only bankswitching schemes are supported which use hotspots within the cartridge ROM address space (i.e. f8, f6, f4, parker, CBS, M-Network), so not for example TigerVision's $3f. That is indeed a limitation, but IMO still acceptable for people that want to tinker around with a cheap Arduino Nano clone - I recently bought one for 5 euro on Amazon. So in total, I'm using 20 GPIO pins on the Nano (D2-D13 + A0-A7). This is the bare minimum to dump cartridges which use bankswitch hotspots within the ROM address space. And of course for cartridges that don't use bankswitching at all 🙂 A6 and A7 are indeed analog-in only ports, but converted to digital like this: static inline uint8_t peek( uint16_t addr ) { setaddr( addr ); uint8_t data = PINC; if (analogRead(A6) > 512) data |= B01000000; if (analogRead(A7) > 512) data |= B10000000; return data; } I've got the Nano already dumping the correct HEX data in the Serial Monitor, only the dump2600.exe tool isn't working (yet) with the Nano. Maybe the Teensy serial libraries add some magic, which isn't in the default Arduino libs.
  15. Hi @SvOlli, I'm working on support for the Arduino Nano, and I have the sketch working. when I open the Serial Monitor in the Arduino IDE and send the command 'rF000', it returns the first ROM byte correctly when I send the command 'dF000 1000', it returns all the hexadecimal values of a 4k cart as a long string. However... I cannot get the dump2600.exe working with the sketch on the Arduino Nano. It looks like the dump-tool is waiting on something. This is what is shows: C:\git\retrocartdumper>dump_2600.exe COM4 4k test.bin 0000 Then after a minute of nothing happening, I just kill the process with Ctrl-C. I've tried to lower the baudrate to 9600 (both in dump2600 and in the sketch), but that didn't help. Note that the dump2600 works fine when I run it on the Teensy. Do you have any suggestions on what might be the problem?
  • Create New...