Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

826 Excellent


About Dionoid

  • Rank

Profile Information

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

Recent Profile Visitors

5,192 profile views
  1. 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.
  2. 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.
  3. 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!
  4. 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.
  5. 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?
  6. 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.
  7. Thrust+ is even better when you play it with foot pedal + driving controller!
  8. 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;
  9. It's an 328P with a CH340 USB to Serial chip (instead of an FT232 chip)
  10. 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.
  11. 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?
  12. It takes around 3-4 seconds for a 4K cartridge dump, IIRC.
  13. Now using a genuine Teensy++ 2.0, the dumper works flawlessly!
  14. Not sure if it helps, but for the PF iris in/out effect in my game, I basically divide the screen into tiles of 1x6 playfield pixels, which represent small squares on the screen. Then every frame, I'm calculating the distance from each of the tiles to the center of the screen, using dx2+dy2 (without bothering to take the square root of it). Then when dx2+dy2 < r2 (where r is the increasing circle radius), I mark the tile as 'dirty', but only if it wasn't marked dirty in the previous frame, by adding the clause: AND dx2+dy2 >= (r-1)2. Note that for the opposite direction (i.e. a shrinking circle), I use dx2+dy2 >= r2 AND dx2+dy2 < (r+1)2 to mark tiles as 'dirty'. After that, for each row of tiles, I check which of the 6 PF bytes in the line's display buffer should be drawn/updated, using the 'dirty' tiles. When *all* the bits of a PF byte are caused by 'dirty' tiles, I clean all the dirty bits of these tiles, indicating that the specific PF byte doesn't need to be updated anymore in the display buffer. There are lots of little optimizations along the way, but this is the gist of it.
  15. Yes, I thought about using a lower baud rate, but I rather use a genuine Teensy instead of the counterfeit. Eventually I want to use this setup to do a PoC where the Stella emulator is reading bytes directly from the cartridge, instead of a rom file. I'm aware it will probably run only at 10% speed, but it's just a PoC.
  • Create New...