Cybearg

The items have interested parties accounting for them. Thanks to everyone who reached out. Whether you’ll receive some of this equipment or not, I wish everyone well in their home brewing adventures!

Yes, sorry, busy with a move. 🙂 I’ll reach out by PM.

To clarify, I’m offering this equipment for free and I’ll pay for shipping. If no one is in need of everything bundled, that’s fine; I can split out and ship items of interest. At the very least, I’d hope the AtariVox, USB adapter, and Harmony cartridges would be given to someone interested in using them for further development. Though if Atari2600 homebrew devs have their own already or there is newer equipment that makes all of this no longer needed, then I’ll probably donate it at a local game store or something.

After more than a decade of bringing the Atari 2600 equipment I used to develop Piñata, I think it's time to give up the fantasy that I'll ever return to Atari 2600 homebrew development. It was a blast and I have everyone at AtariAge to thank for the assistance with feedback and development and to Albert for my short cartridge run. I've been moving with the equipment I used for homebrew development and now I want to find it a good home. Atari 2600 Vadar system, several controllers both original and third party, a Harmony cartridge with memory card, an AtariVox and AtariVox USB interface, and an Atari Flashback Portable. The equipment is untested since I used it for development, but has been kept safely in this same tote, free from dust, water damage, or temperature extremes. I'll pay for boxing and shipping, but I only ask that any interested party use the equipment for further Atari 2600 homebrew development, rather than buying the lot just for the VCS and tossing the development hardware. Anyone interested?

Amazing word, Pac-Man-Red! You're very talented! I'm a little confused about some of the sprite examples you've given, though. Forgive my ignorance, but I assume that with most of the spritesheets you've posted, the Zelda sprites are on the left and you give your own take on the right. I noticed in a couple instances, though, that your versions use 4 colors instead of the limit of 3 (such as with the compass and book sprites in this post). Are those just rare examples where a sprite would actually be made up of two overlapping sprites (as would need to be the case for the supersprite of the bosses you posted above)?

... God dammit! How did I never notice that existed?!

For anyone interested, I've made a little command line tool called pngParse that reads a palette png image and a sprite png image and outputs sprite table data formatted for batariBasic or 6502 ASM. bBpP_1.0.0.zip Notes on use: pngParse doesn't approximate colors: it identifies colors between the sprite image and the palette image by comparing r/g/b values, so for your sprite image to accurately be parsed, its colors must exactly match the colors in the palette. pngParse can take custom palettes of 8x16 pixels. Palettes for NTSC and PAL are already included in the attached zip file. if you don't specify a custom palette file, pngParse will expect to find ntsc.png or pal.png (depending on the -P flag) in the same directory. Output will go to output.txt by default. Sprite images must have a width divisible by 8. Sprite images wider than 8 pixels will be parsed as a separate sprite, so you can input a 64x13 pixel sprite sheet and pngParse will output 8 8x13 pixel sprites. Flags: -s "spritesheet.png" Specifies the input spritesheet (required). -p "secam.png" Specifies the input palette image (ignores the -P flag) -o "spriteData.txt" Specifies the output file (output.txt by default) -P Uses the PAL palette (NTSC by default) -D Formats output for the DPC kernel (standard kernel formatting by default) -A Formats output for 6502 ASM (batariBasic formatting by default)

To inform everyone, Pinata has been taken out of production. Unfortunately, professional concerns over some of Pinata's content has compelled me to ask Al to discontinue sales. I've uploaded the latest version of the ROMs as well as a PDF of the manual to this topic's first post. I kept the 1.0.5 ROMs on the first post as well, in case people prefer playing the pre-cart versions of the games (there were some significant modifications to some of the games). Hopefully everyone who wanted a cartridge got one already. Thank you to everyone for your support.

And if you make the protagonist look a lot like Zelda, you may even get the FemFreq shout-out.

Mhm. Still, close enough for prototyping purposes, IMO.

I wouldn't say bB is, particularly since everything has to be done super-carefully or else you're out of cycles/memory/space/all-of-the-above. On that note (though this isn't quite so 7800-based), this is my result after a couple hours of building a way to take in the levels and spit out a recreation of what you'd see on the Atari2600, along with the original from Stella: ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXX......................XXXXX XXXX........................XXXX XXX............................. XXX...XX.XX..................... XXX............................. XXX...XX.XX..................... XXX............................. XXX............................. XXX........XXXXXXXXXXXXXXXXXXXXX XXX.......XXX................XXX XXX......XXX.................XXX XXX.....XXX..................XXX XXX....XXX...................XXX ........XXX......XX.XX.XXX...XXX .........XXX...........XXX...XXX ..........XXX....XX.XX.XXX...XXX ...........XXX.........XXX...XXX ............XXX........XXX...XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Can you tell which is Stella and which is GameMaker?

Well, I presumed one would make efforts to emulate the style of the 7800 to make things more accurate. The speed in development would more come from the convenience of objects in modern engines versus the abstracted sprites/limited memory of classic systems. It would indeed require careful effort to make sure that the screen resolutions were identical so that algorithms one develops, like jump/attack arcs, could translate directly (more or less) from the higher-power system to the retro system. I was particularly pondering this in the case of batariBasic programming; designing the systems that allow things to efficiently work takes a long time and is difficult in batariBasic (and presumably 7800basic as well). Maybe I'm blowing smoke, but I'm hoping that prototyping would be helpful in speeding up design, rather than requiring the entire game to be rewritten from the ground up a half dozen times as plans and requirements change.

Would you recommend making the game in 7800basic from the start, or prototyping in something else, like GameMaker?

^-- What I keep saying.

Do these maps actually take up the whole of those 256kb, or did you pick 256kb just as an arbitrary choice?