Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 08/20/2009 in Blog Entries

  1. 17 points
    I realized that there is no place where people can download my ROMs. So I decided I should use my blog to provide them. There will be ROMs of all my homebrews. And maybe I will add some demo or unfinished stuff later too.
  2. 16 points
    For a few months now I've been toiling behind the scenes on a port of batari basic for the 7800. Today I'm going public and showing off a little bit of what I've accomplished. Since a picture is worth a thousand words... adventurer.bas adventurer.bas.bin adventurer.bas.a78 ...the source code for that quick and dirty demo is decidedly not a thousand words. It's 68 lines of pure 7800basic code, and 12 of those are simple commands to import png images. There are already a bunch of useful features... import of png graphics to any one of the 7800's mode formats, with the ability to reorder color indexes during the import. plot sprites, values, and characters/tiles. simple joystick polling, for both one and two button joysticks. 32k and 48k formats are currently available. SuperGame formats to come. switch between 7800's various display modes. pick from a zone height of 8 or 16. ...in addition to all of the great features that 7800basic receives from its batari Basic heritage. A special thanks goes to batari, who gave his approval and encouragement for using the excellent bB code base. There are still features to add, testing to do, and docs to write before 7800basic is ready for public beta, but it's in the home stretch now. [edit]update #2 posted.
  3. 15 points
    Received a question via Messager that I'm going to reply to here as others may find it interesting as well: Long story short, extra hardware in the cartridge. Short story long, one or more of the following are added into the cartridge: Extra ROM When the Atari was designed ROM was expensive so they only used 2K for the games (think Combat, Air-Sea Battle, etc). They did plan ahead though and designed the Atari so it could use 4K ROMs. As the cost of ROM dropped 4K games like Space Invaders and River Raid could then be written. Having extra ROM gives a game the space to store more detailed graphics. Bankswitching - AKA even more ROM Atari thought the successor to the 2600 would be out before they needed to go beyond 4K of ROM. The 2600 turned out to be more popular, and longer lived, than they expected so eventually 4K was no longer enough and they had to figure out a way around the 4K limit. What they came up with is known as bankswitching. For bankswitching you can think of the cartridge as a book, and each page in the book contains 4K. The Atari can turn the page to see different parts of the cartridge. A "2 page book" would be an 8K cartridge, like Asteroids and Ms. Pac-Man. A "4 page book" would be 16K for games like Solaris. I believe the largest game released back in the day was Fatal Run at 32K. Extra RAM All that extra ROM allowed for more complex games that needed to keep track of more things. The Atari only has 128 bytes of RAM and the cartridge port does not have the required signals to support RAM in the cartridge; critically it's missing the Read/Write line which is used to determine if the memory being accessed is to be Read From or Written To. Eventually they figured out how to work around that by repurposing an address line as the R/W line. The tradeoff of using an address line is each byte of RAM in the cartridge shows up twice in memory - one location is used for Reading, the other location is used for Writing. Jr. Pac-Man used extra RAM in order to keep track of all those dots in the large scrolling mazes. Games that use extra RAM tend to also use extra ROM. Coprocessor The Atari's unique in that the program has to update the video chip in real time, scanline by scanline, in order to create the display. This part of the program is known as the Kernel and is very time critical. Eventually extra ROM and RAM cannot help make a game look better as there just isn't enough processing time to utilize those extra resources. To solve that, Activision came up with a coprocessor, known as DPC. DPC speeds up common kernel calculations, allowing even more updates to the video chip on every scanline. More updates leads to better graphics, as seen in Pitfall 2. DPC also includes support for 3 voice music via waveform addition; however, using it requires the audio chip to be updated every scanline. That's a 9.2% hit in processing time in the Kernel, though Pitfall 2 used this feature to great effect. Sadly the market collapsed before DPC could be used for other games on the 2600, though coprocessors in game cartridges were very common with later systems like the NES. Space Rocks Space Rocks uses all of the above - extra ROM, RAM and a "DPC+ coprocessor". Those are air quotes as the DPC+ coprocessor doesn't actually exist. So how'd we pull that off? Well the Harmony Cart (and Melody board, basically a Harmony without the SD slot or USB port that is used to create stand alone games) has an ARM processor that runs different drivers to emulate the different types of hardware that can be found in an Atari cartridge. One those drivers emulated the DPC chip, allowing you to play Pitfall 2 on it. The Harmony has a lot of unused resources when running the DPC driver so we created a new driver, known as DPC+, in order to unlock those extra resources (extra RAM, ROM, and even running game code on the ARM processor itself). The Future As we learn more about the 2600 we can create new drivers for the Harmony/Melody to take advantage of that knowledge. As an example we're currently working on a bus stuffing driver and have created a few demos so people can try it out. Expect to see a lot more activity on this new driver after the holidays. Bus stuffing in action:
  4. 14 points
    By sheer coincidence, on Tuesday's episode of ZeroPage Homebew, James posted a poll asking if people used a video mod or stock RF to output video from their 2600s. Overwhelmingly, people answered RF. So the timing of this blog post is pretty good, since I've been working on this particular entry for well over a week. RF tends to have a bad rap with the Atari 2600. It's the standard connection between your console and TV, and was designed for a time when the only input that TVs had was for an antenna (either a pair of terminal screws, or an F-type coaxial cable connector). The reason RF gets a bad rap is twofold: 1) It's fuzzy 2) It's noisy. Now, there's not much we can do about the fuzziness. The reason for that is because of how RF works. The 2600 creates video as luminance (brightness) and chrominance (color) signals. It then takes those signals, and mushes them together into a single composite video signal, and then modulates that with the audio signal onto a radio wave that the TV tuners of the day would see as a channel and demodulate it back into video and audio. So because it's mushing the luma and chroma together, everything gets a bit soft and indistinct. That's just the way RF is. The signal is carrying a lot of stuff that has to be separated back out at the other end. To get a sharper picture means modifying the 2600 so you're taking video and audio directly from the output of the TIA (Television Interface Adapter) chip, before they get to the RF modulator, and then outputting them directly using either a composite (luma and chroma merged) or S-Video (separate luma and chroma) signal, with audio sent separately. To go beyond S-Video requires a special mod that can transcode luma and chroma into either RGB (separate red, green and blue signals) or component video (which is... confusing ). Both further separate the components of the video signal, maintaining the best possible color definition. But modding a console has drawbacks. First, you have to have some ability to solder small electronics. There are no fully plug-and-play mods available. If you don't know how to solder, that means either learning, or finding someone else to do it for you. Second, you're altering your original console, which some people simply don't want to do. Either because of the risk of damaging it, or just because they want to keep it original (although mods can usually be removed). So if you don't want to mod your console, but want the best RF picture you can get, then it's time to clean up the noise. The noise happens because since the 2600 uses radio frequencies to transmit picture and sound, and that signal is susceptible to interference. This can come from just about anything: nearby lights, microwave ovens, hair dryers, fans, electrical cords, air conditioning, power supplies and other electronic devices, and it manifests itself as static on the screen. There's some metal shielding in the 2600 to help reduce this, but most of the noise comes from the connection between your console and the TV set. And this is what we can address. The first thing to consider is where you plug your 2600's signal into your TV. If your TV has an F-type connector and a tuner that can still tune in the (now defunct) analog channels, you can just plug into that. But if you have a cheap TV with a poor tuner in it, that can negatively affect your picture. A bigger problem is if you're using a monitor that has no tuner, and only a composite input. Then you need an external tuner. One option is to plug the 2600 into the F-type connector on an old VCR, tune it to channel 2 or 3, then plug the VCR into into your monitor. But the output you get depends on the quality of the built-in tuner and the video circuitry, and a lot of VCRs were, well, junk. Plus, they're bigger than they need to be, especially if you aren't playing VHS tapes in them anymore. All you really need then is the tuner, or more to the point, an RF demodulator. And you want to get a good one, since that's the thing that's going to separate out that RF signal, and pipe the video and audio to your display. So let's start with that. What I use is a dedicated Sony tuner (TU-1041U), that was designed for use with their professional video monitors in broadcast applications. Fortunately, with the death of analog broadcast TV, these things are all over eBay, and they're usually dirt-cheap. Right now, there are some available for less than $15. Some variants have mono audio only, which is fine since the 2600 is mono anyway, as are many older CRT monitors. I bought a stereo model, so the audio gets sent to both channels in my home theater system. (The audio is still mono, it's just coming out of both speakers.) The demodulator in this is excellent. For one thing, it wasn't a consumer piece of electronics. This was built by Sony for professional use. It was designed to take RF signals and demodulate them back into high quality composite video and audio. It doesn't play tapes, or record shows, or do anything else. It's significantly smaller than a VCR, and it looks cooler too. That said, it doesn't do S-Video. Sorry. If you really want S-Video, your best bet is installing a mod. If you want to get S-Video without a mod, you'll still need a demodulator and then a composite to S-Video converter. But unless you can find one on eBay, decent ones are almost $300. Even then, trying to convert composite to S-Video is like trying to un-mix chocolate milk. You could probably do it, but it's not going to be worth the effort or expense, and neither the milk nor the chocolate are going to come out of it very well. So, with a good demodulator in hand, let's see about improving the noise problem. For all of the examples below, I shot all of the pictures off of a Sony PVM-14M2U monitor, calibrated with a color bar generator (click on any picture for a large version). If you're going to do any work on improving your 2600's picture, the first thing you need to do is calibrate your TV or monitor to color bars. This is simple enough to do with a DVD player and a calibration disc. The 2600 was developed according to NTSC video standards, and if you don't get your display correct first, then anything you do to the 2600 really isn't going to reflect what it should look like. (The same applies to PAL 2600's, but with more lines, and weirder colors. ) All RF signals went into the TU-1014U tuner, then into the monitor's composite video input. The same four-switch 2600 was used for all RF tests. The S-video signals were from a different four-switch 2600, and the signal went straight into the S-Video input on the monitor. First, let's look at how all 2600s were originally connected: the switchbox. This horrible little tin disaster connected to the antenna leads on the back of your TV, and allowed you to switch between your antenna and your 2600. For those with an F-type connector on their TV, you had to add one of these adapters, and attach the switchbox's screws to it: The other side would plug into the back of your TV (or cable box, if you were an early adopter): The problem with switchboxes, besides being susceptible to RF interference, was the switch contacts would get dirtier and dirtier, resulting in an increasingly noisy signal. Here are three pictures from the exact same system. This is using the original Atari RF cable and a switchbox. Here's how it looked, right after installing it for the first time in years: That's Chopper Command, in case you were wondering. I should point out, there is absolutely nothing wrong with this 2600. After giving the switch a good cleaning with contact cleaner, and working the switch back and forth a number of times, I could get a pretty clean signal: But the slightest bump of the switchbox, and I'd get this: And these were the best pictures I could get with the switchbox. Clearly, the switchbox has to go. The simplest replacement is an RCA to F-type adapter: This bypasses everything inside the switchbox, and lets you plug the RF cable straight into your TV. But what do you do if you still need a switchbox? Maybe your 2600 is still sharing an RF input with something else on your TV? Well, get a switch that isn't noisy. A high isolation A/B switch is the way to go. I have one from the late, lamented Radio Shack. But there are others out there. An important thing to remember though - you're increasing the number of cables when using an A/B switch. You have to plug your 2600 into the switch, then run another cable from the switch to your TV. Each cable increases the potential for that noise we want to get rid of. The cables basically act as antennae, picking up whatever stray RF interference happens to be floating around. So let's deal with the main cause of RF noise: the RF cable. Atari's original cable is thin, long, and poorly shielded. It's basically a magnet for interference. Here are three pictures using Atari's RF cable, without a switchbox: Look familiar? A little grainy? (The camera captures static that you don't always see in person, because it's happening so fast. Try taking a picture of your own TV, and see what you get!) Here's another look: See all of the extra noise? So what's the difference between those pictures and the previous set? Well, nothing! It's still the same 2600, the same stock Atari RF cable, and the same monitor. In fact, each of the photos in the second set was taken within a few seconds of the ones in the first set. The only difference is that for the second set, I've moved the RF cable about six inches closer to the 2600's power cord. That brings up a very important tip: keep the power cord under control! I've found that I can reduce RF noise a lot, just by bundling the excess power cord together, wrapping a Velcro™ tie around it, and moving it until the picture noise diminishes. A related tip is that if I bundle up the excess RF cable, it tends to pick up less interference. If you grab the bundled RF cable in your hand, you'll usually see the onscreen noise drop even more dramatically. At that point, your body is basically canceling out the interfering radio signals. (Or something like that.) But holding the cable in one hand isn't really conducive to playing videogames. Maybe you could have someone else hold the cable for you while you marathon your way to that Laser Blast patch. What we really need though, is an RF cable that's better shielded. When I test RF systems, I use a broadcast-grade video cable (the purple one in the photos) with excellent shielding. But having leftover broadcast cable sitting around isn't a practical solution for most people . So I thought I'd look for an off-the-shelf solution. First, I tried out a Cable Matters quad-shielded RF cable (this came in a three-pack, but you can find similar, single cables). This is decent quality but still affordable. The shielding looks like this: Now, that looks like a lot of shielding, but look at the braided part. There are gaps in it. There are more gaps than braid. You can look up the cable specs online, and find out more information about it. For this cable, it says that it has 95% coverage in total. Two braided shields, plus two foil. It also says the cable is "swept to 3.0 GHz". So what does that mean? Well, it's a spec that says how high of a signal frequency the cable should be able to carry. The higher the spec, generally the higher quality the cable. The Atari uses either VHF channel 2 or 3, which at 50-60 MHz is way, way below that. So this should be fine, right? Let's take a look! Now, those do look better than the stock RF cable. But let's move the cable back to where we had problems before: It's still picking up interference. Not as noticeable as before. But as a budget option, this would be fine, and it's definitely going to improve your RF picture. But we can do better. Remember that broadcast-grade cable I used? It's made by Clark Wire and Cable. Here's the shielding it uses: This has two layers of braided shielding each rated at 98% coverage. But again, I only have this because of a few leftover cables from work. To make new ones, you'd have to order the cable by the foot, buy some connectors, and stripping and crimping tools. Can we get something similar, without having to go to the hassle and expense of making our own cables? Well, this wouldn't be much of a blog post if we couldn't! (I'm sure not going to make the cables for you.) Fortunately, you can pay someone else to make them, and order them from Amazon. Blue Jeans Cable uses Belden 1694A, with really nice Canare connectors. The shielding isn't quite as robust as the Clark cable, but it it has a layer of foil shielding and a 95% coverage braided shield. So it's braided shield alone is effectively the same as all of the shielding in the Cable Matters cable. It's also rated for 6GHz. Effectively, this means the cable should be of higher quality than the Cable Matters one and be able to reject more interference. Here are the three cables side-by-side. The original Atari cable on the left, the Cable Matters one in the middle, and the Blue Jeans one (using Belden cable) on the right. Now, the Blue Jeans cable is expensive. No question about that. But the build quality is exceptional. Even though the cable is about the same diameter as the Cable Matters one, the Belden cable is less stiff (as a point of comparison, the Clark cable I have is so stiff that it's difficult to work with - it's really meant for permanent installations). The Canare connectors on the Blue Jeans cable are actually a joy to use. Most F-type connectors are a pain to tighten or loosen because the part that turns is usually too small to grip comfortably. But the Canare is easy to grip and turns as smooth as butter. So, it's a nice cable that doesn't skin my knuckles when I install it. But what does it look like? Very clean! Every bit as good as the Clark cable. But how does it do at rejecting interference? Well, it's still there. If you have bad RF interference, it's going to show up on your screen regardless of the cable. The goal here is to minimize the noise, and maximize the signal quality. A better cable does equal a better picture. There's less signal loss, and more shielding against interference. But there's always going to be an environmental component. Some of it you can control. Some of it you may not be able to. But you have to at least start with a good cable. Now, replacing a stock RF cable in a 2600 requires opening it up. Fortunately, it's just a few screws to remove, and the RF cable is simply plugged in, either near or directly into a small metal box (the RF modulator). To install the new cable requires an adapter. A new RF cable will have an F-type screw-on connector. The Atari cable used an RCA plug. The problem is, depending on the model, the space inside the 2600 can be very limited. In this four-switch, the cable has to bend at a 90° just above where it plugs in, and then exit out the back of the console. There's no way that the new RF cable will fit there, especially with an adapter on it. It's too tall. But as they say, two wrongs don't make a right, but three lefts do. Or something. So I came up with this: Two right-angle RCA adapters, and an F-type to RCA adapter. This setup adapts the F-type connector to RCA, and then routes it where it needs to go. Before reassembling the 2600, I'll use electrical tape to wrap all of the connectors together. The final RCA adapter that plugs into the 2600 has to have its center post filed down (at right), or it bottoms out before fully making contact. Note the pin on the Atari connector to the left. To see if I can simplify this setup, I've ordered a right angle F-type to RCA adapter. But it hasn't gotten here yet. I'll post an update in the comments if it works. Now, even with a really good cable, RF isn't going to be 100% noise-free. This is still RF and still susceptible to interference. But a high quality cable can make the picture more stable and much cleaner. This is the best RF can probably look on a 2600. It's certainly a lot better than the stock Atari RF cable. And this will work on an Atari 7800, too. Or any console that used a weedy little RF cable to connect to a TV. If you want a truly noiseless picture on your 2600, then you'll need to install a video mod (in this case, a CyberTech S-Video mod, in a four-switch 2600): As a direct point of comparison, here's a color test binary using the Belden/Blue Jeans RF cable: And the same, using S-Video: If you can get RF working without noise though, you won't really mind not having S-Video. As long as you don't think about it too much. Unfortunately, the CyberTech mod is no longer available. But at some point, I'll be installing an Ultimate Atari Video mod, and we'll see how that compares. Update: I added an addendum in this blog entry showing a lighter, more flexible Blue Jeans cable and a simpler RF adapter setup.
  5. 14 points
    While getting ROMs together for Nathan for his RetroN 77 contribution to the Stella-thon 12 Hour Gaming Marathon Fundraiser! event I realized I've yet to publish the final ROM for Draconian. ROM: draconian_20171020_RC8.bin Source*: draconian_linux.zip * linux is in the zipped directory name because I used my Linux laptop to finish Draconian on the way to PRGE.
  6. 14 points
    Alright so I decided to just release my Ebook for free here on the forum so here ya go. It comes in EPUB and MOBI flavors for Kindle users. 101 Reviews for the Atari the Good, the Bad, and the Weird.mobi 101 Reviews for the Atari the Good, the Bad, and the Weird.epub
  7. 13 points
    Finally completed! This idea started when I acquired a 5" LCD panel about a year ago, and I thought about making a mini arcade machine around it. I figured 1/4" scale, because originally they used 19" monitors, so 20" (I rounded up) divided by 5" = 4. I then decided to start with a mini upright pacman, and would like to do others as well (i.e. Asteroids, Defender, Galaga, etc.) Sort of like a 'mini arcade' for people like me who don't have the room for full size cabinets. First this I have to say, is that this would not have been possible without John from Boulder Arcade Factory. He was helpful, willing to try something new (he usually sells full size cabinet recreations... I made a Cabaret version with one of his cabinets here), and just a nice person all around. John made the scaled-down cabinet out of MDF, and I took it from there. The cabinet was perfect, and he paid attention to every detail. Unfortunately, the side art I had printed last year came up a little short (about 1/2 inch), so I painted the bottom. I must have mis-measured last year when I was trying to build it myself. Other than that, I tried to follow the exact way the full size cabinet is made. I ended up 3-D printing: - The marquee retainers - The red joystick ball - The Control Panel itself - The Coin Door - The speaker grill AA user 'spawnshop' desgined the coin door, and printed the first one... which I subsequently ruined since then, I purchased my own 3-D printer, and was able to print another two of them, using his design. Thanks spawnshop! I found a small joystick on the net and used that as you can see in the pictures. I pulled off the keycap, and printed the Red ball as noted above. I also used Orange magic marker for the ‘t-molding’, and black marker for the inside. Still need to figure out a 'non-permanent' way to attach the monitor bezel (which has the LCD panel attached to it), as well as the Control Panel. I used a Raspberry Pi for the innards, and made it boot directly into Pac-Man only. Thanks, guys! Bob
  8. 13 points
    A year ago I finally fixed my original Sears 2600. It had kicked the bucket in 2011, and after making do with a donor board for a couple of years, I finally got my original board working again by swapping out the 6507 and RIOT, plus installing Mojoatomic's re-cap kit. So I had my original 2600 (plus a CyberTech S-Video mod) all up and running again! But not quite... One of the first repairs I had to make back when I dusted it off in 2002 for the first time in over a decade, was the Select and Reset switches were broken. So I ordered a set of new ones, and much to my disappointment, they weren't the same. The toggles were aluminum. Mine had always been chrome. I didn't know at the time that the chrome caps were added to refurbished models - I just thought that's how the Sears consoles were supposed to all be. I knew mine was a factory refurb (that's how I was able to afford it), but had never made the connection. Unfortunately, you just can't go out and order replacement chrome caps. Those parts have long-since been exhausted. And an attempt I made to get one of the chrome caps off resulted in mangling it so bad it was unusable. So, I made do with the aluminum ones. But my 2600 never felt... right. My 2600 - with aluminum switches. When I repaired it a year ago (for what I hoped was the last time), I made one last effort to find chrome switches. Even if it meant finding another refurbished Sears 2600. But no luck. So I figured "Well... maybe someday", and went back to playing the console with the stock aluminum switches. Then, quite recently (probably due to my participating more than usual in the 2600 HSC this year), my Reset switch started misbehaving. At first jiggling it would make it work, but after awhile, it completely failed. So I was going to have to open my 2600 up and replace it anyway. Meanwhile, I swapped my console with a spare Vader, and kept playing. Then, this thread happened. And in it, AtariAger Osgeld responded to me asking about chrome capped switches - and he had some! They were spares - and I could have them for the cost of postage. A quick PayPal later, and I had the switches! Now, it didn't 100% solve my problem, because he had only one momentary switch, and I needed two. But - I was able to get one of my other chrome caps off with minimal fuss, so all I had to do was slide that cap over one of the aluminum ones, and I'd be in business! Three of my original switches, Osgeld's spares, and my successfully-removed cap. So today I opened up my 2600, and started swapping out the switches. All prepped for surgery. The nice part about doing a switch swap is that the main part of the 2600 - including my video mod - can stay put. The bad Reset switch is on the right. Some of the contacts in it are loose and flopping around. I had to scrape some adhesive out of the cap before it would slide over the switch. The re-capped Select switch. Since this switch was good, there was no reason to desolder it. The cap is held on with a thin strip of Poster Tape inside. All desoldered, and ready to have its proper switches restored! All done! That was fast! (No it wasn't... desoldering took awhile. I need to get one of these.) Close-up of the chrome switches. Don't they look sweet? More chrome! Including the re-capped Select and replaced Reset switch. Felt pads are back in place, and the 2600 is ready to be buttoned-up. Hopefully for the last time for a long while. I don't actually know what this is. I hit the button on my phone accidentally at some point. But it's kind of a cool abstract art thing, so there you go. And it's finished! It's hard to show how good these look in person. But what's even better, oddly enough, is how they feel. They're smoother than the aluminum ones, and they make my 2600 feel the way it used to, all those years ago! Before and after. So finally, after multiple surgeries, and many, many years, my 2600 is back! It's got its original switches again, and finally everything works! Well... except that it boots to a black screen unless my AtariVox is plugged into the right joystick port. For some reason. Whatever.
  9. 12 points
    A while ago I had some discussion with SvOlli about improving a part of his winning Bang! demo called "Snake Sprite". Initially he wanted to add more colors, but I thought more about removing the repositioning gaps. This seemed like something never done before inside a 48 pixel kernel, so I took the challenge. After making it possible, SvOlli suggested to integrate my little demo into a bigger mega demo. So I spiced up the demo a bit, scripted it into 4 parts and added some pompous demo text scroller. Unfortunately the mega demo didn't make it, so we decided that it should stand by itself, now called Coke Zero (you will understand the name when watching it). Since I have no talent for this, SvOlli contacted Skyrunner, a musician who would provide the necessary demo track. Space was very limited at that time, so it was quite a challenge for both of us to squeeze in the music. My part was optimizing for space and for that I improved Paul Slocum's old music player once again. Now it is fully customizable and even more space efficient than it was before. Skyrunner had the harder part, since he had to please me AND the space limitations. This Easter weekend the world's biggest pure Demoscene event Revison 2015 happened and Svolli and Skyrunner who both admitted the party (look out for SvOlli's seminars on YouTube and Skyrunner's other prod) submitted my little demo to the 4K Oldschool Intro competition. I have been watching much of the event via live streaming and saw some great demos. Today the Prizegiving event happened and to my big surprise, our little demo became 2nd! You can find the binary and full source code in the attachment. Enjoy! Video: http://www.dailymotion.com/video/x2m6ari_coke-zero_tech
  10. 11 points
    Creating the Retro Gaming Experience To me, sitting infront of a flat screen TV using some emulator and a wireless controller didn't really provide me with the best Retro Gaming experience. When I first tried playing the old games I used to love on emulation, it just felt empty and stale. I wasn't sure why at first, then it hit me. When I was playing the games, I was looking for that nostalgic experience. I wanted to relive the memories of my youth. Unfortunately emulation wasn't sparking that nostalgic memory. I needed a true Retro Gaming experience. I learned then, there was a difference between just playing a retro game at home and actually "experiencing" home retro gaming. I kinda compare it to the experience of playing one of the new Arcade One-Up machines in your house compared to actually going to a real (retro) arcade. Both experiences are extremely different even though you're playing the same game. So it's the atmosphere that plays a big part in contributing to the experience. (I needed to bring the atomsphere back) So a few years ago I decided to create my own Home Retro Gaming experience by creating a retro gaming nook. I had a small space in the corner of my garage to use as a template. This would take a lot of patience and hunting. Though I had plenty of Atari stuff in my collection, I still needed to hunt out the decor I needed for this retro nook. To sit down somewhere and feel like I went back in time. The act of playing on a old CRT TV, being restricted by cords. The earthy tones of the wood paneling. The simplistic decor of the late 70s/early 80s of my youth. To design something that took me back in time would offer the true experience. My first pick-up was this 1977 Sony Trinitron with matching TV Cart: So during the next year-and-a-half I combed eBay, Facebook Marketplace, Craigslist, and local thrift stores. I not only needed the right decor, but I needed it cheap (I didn't really have much of a budget). Once I accumulated enough stuff to make my design reality, it was time to begin. I decided to dedicate a small corner of my garage for a retro corner. I started with the wood paneling. Luckily, many of the home improvement stores still carries wood paneling for very cheap. After getting the wood paneling up, it was only a matter of laying the carpet down and putting the pieces in the place. When all was said and done I only spent around $300 to complete this project. A lot of the cost savings came with patience. waiting to find the right stuff for the right price without overspending (For example, the TV and cart I was able to pick up for $30). Here was the end result. The final Retro Nook came out better than I imagined. Sitting in this corner playing my Atari, I almost thought I was back in 1983. Even the copper colored wing-back chair was the same chair we had a 1983 (my family never had the heart to get rid of it). People have to remember...... Back in the early 80s, most home decor were still from the 70s (unless they recently remodeled). Add a little stale tobacco smoke to the nook to complete the Retro Gaming experience😂. For the rest of the year I often enjoyed disappearing in my little gaming area to relive some of my nostalgic memories. At times my kids even joined me. It was great to show my children how "dad" played games when he was a little boy. During the next summer I decided to do a redesign of my retro corner. I wanted to make it a themed corner, as well as incorporate one of the old cabinet TVs that I have. I have always been a fan of playing original hardware on original hardware. So I have multiple CRT TVs that my children and myself use. I do have a few cabinet TVs and I had one in particular I wanted to use for my new "themed" retro corner. Here is a old cabinet TV I have in my bedroom. It's the TV I used most of the time before I designed my retro corner. Anyways, since I wanted to redesign my retro corner I decided to do it themed design. I decided to go with a Q*Bert theme which was one of my favorite Retro Gaming characters. It took a while to gather all the stuff I needed for the redesign. I already had an old 1970 zenith cabinet TV I wanted to use, but to find the right Q*Bert themed decor was a little challenging (more specifically the wall art). Then I found the perfect piece. A Q*Bert latch hook rug became available and I just had to have it. I was also able to acquire a orange wingback chair for $20. Here is the final design...... This Q*Bert themed design I was extremely happy with. I decided to get rid of the table to bring back the good ole days of having to sit on the floor to play. Coincidentally enough, I finished this design right around Halloween. I actually had a old early 80s Q*Bert costume (one of those old vinyl Collegeville costumes). My son decided to humor me and put the costume on so I could do a Halloween photo. I tried to use an aging filter to make the photo look a little less "high def". I'm not professional photographer so I did what I could with my cell phone, lol Here was the end result. MY 2020 DESIGN..... In 2020 I decided to shrink up the design a little. To make something simpler, and to design a area that would mimic a image you would see on a Atari Ad. I used a different TV for this one (1984 Zenith). One of the best parts about having this retro corner is being able to spend time with my kids introducing them too the early gaming experience. Due to Covid-19 and spending a lot of time at home, we were able to spend a lot of time playing games together. All in all, creating a authentic Retro Gaming experience is relatively inexpensive and you only need a very small space. Playing these games takes me back to a simpler time. For some reason I find it more enjoyable playing on my retro setups then I do behind a computer screen or on some other type of emulation. The feel of the carpet, the act of inserting the cartridge, the smell of the TV tubes, the sight of the wood paneling, and being restricted to the limitations of technology all help contribute to the overall Retro Gaming experience. This is what I remember, and I find myself actually enjoying playing these old games more as I disappear in my time machine. COVID-19 The summer of 2020 I came across a old 1979 Sony Trinitron. I decided to do a very quick redesign to include that TV, as well as using my Space Invaders wall art I've been holding onto for a while. After I was done my children's school went to "virtual learning" due to the Coronavirus. My kids decided to turn my Retro Nook into a Virtual Learning Battle Station, (where old technology mixes with new technology..😂). My 2021 design In 2021 I wanted to mess around with more themes within my design. I decided to start spring off right and go with a Easter theme. About 2 weeks before Easter, we got word that the Easter Bunny was going to visit our house on Easter morning. I wanted the Easter Bunny to feel welcome and it was a perfect opportunity to use my retro corner for my children to take photos with Easter Bunny. So I quickly put my Rachel Corner together preparing for a special visitor. After the visit from the Easter Bunny I want to create a 👽 Alien 👽 themed area. This is something I wanted to do for quite some time. I've always been a fan of sci-fi and I wanted this "Alien Abduction" type of feel for my 2021 design. Green accent lights to give the whole corner a eerie glow This alien design for a 2021 is really fun to work with and I'm constantly changing it a little. I recently got rid of the green lights and decided to give it more traditional lighting. The kids and I have a great time playing games in this area and I love the fact that my children enjoy having a little retro gaming time with their dad. I'll end with one last photo. My most recent setup that I may use if I decide to redesign my Retro Corner in the future. It's my 1976 Zeinth gaming station. It's been a blast having this little retro gaming corner. In the past 3 years I have been able to spend a lot of time in my retro corner playing my old Atari with my kids (and creating awesome memories). Hopefully someday I will be able to dedicate a entire room to the simplicity days before the internet. The days before the constant bombardment of social digital stress. Thanks for reading my blog.
  11. 11 points
    I've taken quite a bit of time off 2600 projects, was burnt out after the crunch to finish Draconian in time for PRGE - I even worked on it as my folks and I made our way to Portland, by way of the Grand Canyon! I'm once again interested in working on 2600 projects and started off by porting Stay Frosty 2's music driver from DPC+ to CDF format for John's port of Mappy. Can't wait to hear iesposta's audio wizardry in that project! After finishing that I started in on my SpiceC framework. If you've not heard of it before, it's a new 2600 development environment to make it easier to write games. It'll be like batari BASIC with prewritten kernels and you only having to write the game logic. It'll differ in that it uses kernels written to take advantage of the CDF bankswitching (as seen in Draconian, Super Cobra Arcade, and the forthcoming Mappy), and all of your game logic will be written in C instead of BASIC. The game logic will run on the 70 MHz ARM processor found inside the Harmony Cartridge and Melody Board. Here's an overview of how it works so far: Initialize SpiceC environment: Create a new project called test3, presented with the menu choices: Next option is the game kernel: If you don't know what a kernel supports you can ask for more detailed info: Next up is the score kernel: If all of your choices support Enhanced Audio you'll be prompted on that (if not you'll default to TIA ONLY): You'll then be given an overview of your choices: No will let you reselect your options while Yes will create a directory for your project as well as a configuration file: Switch to your project directory and you can build it: which causes new files to show up in your project directory: The bulk of the source code is located elsewhere and currently builds a rainbow executable: Now that I have that working, I need to work on writing the various kernels - at the moment they are just full of comments: The comment line starting with SD is the Short Description and is displayed in the numbered selection list. The comment lines starting with LD contain the Long Description and are what you see if you ask for more detailed info. This means adding new kernels is just a matter of dropping them in the correct location, no changes will be required to the spicec.sh script. That comment line "supports enhanced audio" is how the script knows if a kernel can use enhanced audio or not. Quite a bit more to do before y'all can use it, but I'm excited about the progress I've made so far.
  12. 11 points
    Okay... that's a bit of a cheat. Technically, it should be Stella at 20, at 19. But that just doesn't sound as cool. Bet you never thought you'd see another post about this project... did ya'? Well, at a certain point, neither did I. Eleven years ago, almost to the week, I received the original camera tapes for the two-volume documentary Stella at 20 from Glenn Saunders, with the intent of re-editing it into an expanded version of the documentary. The goal was to put it out on DVD, since it initially only appeared on VHS, and Volume 2 had never been widely available. The problem with just releasing the original documentary to DVD was that the master tape of Volume 1 had been lost by the duplicating house, and no dub had been made of it. So there was no way to get anything better than VHS quality for Volume 1, without going through and re-editing it from the source tapes. And if you're going to do that - why not expand it, since over a dozen hours of footage was shot? Well, that was the thought anyway. But, as happens with so many other hobby-centered projects, it went nowhere. The time needed to invest in it and do it properly never materialized. Between my job, other Atari-related projects, and occasionally real-life, I just didn't have the time to do it. For all intents and purposes, I completely underestimated the amount of time and effort this was going to take. At least two other people over the years offered to re-edit it as well. None of the offers panned out. Something else that factored into this, was that video technology was rapidly changing. It became a moving target. As part of my job, I spend a great deal of time trying to hit that target. When I originally digitized the tapes, the best quality I could manage was DVCAM format. Now this could be considered - charitably - a "prosumer" format. And for editing a DVD, it would be acceptable. But for creating new masters equal to the quality of the original Betacam footage, not so much. Within a couple of years, the equipment I had access to changed significantly, and I could then capture video uncompressed. Clearly, this would be the way to go, but it meant re-digitizing over two-dozen tapes, and even then, the big problem was still carving out the time needed to re-edit it all. Within another couple of years things changed significantly again, as we moved on from standard definition to high definition. And while the tapes were never shot in HD, it still factored into the question of what was our target? Was it Blu-ray? Do we upscale everything? Do we stick with DVD? Well, that became a moot question too, as the emergence of YouTube completely changed how people consumed video. Even though it wasn't authorized, Volume 1 of Stella was already out there. From exactly the sort of grainy, low-resolution VHS source that Glenn had wanted to avoid in the first place. Glenn's solution: Skip the re-edited version, and just put all of the original camera tapes online. The two released volumes ran 2 hours and 40 minutes combined. That meant 10 hours of material had never been seen. Even with an expanded documentary, most of that material would still have remained hidden away. This way, everyone who really wanted to see this amazing time capsule, could do so in its entirety. The destination? Archive.org. To present the material in the best possible quality, the tapes needed to be recaptured with online playback in mind. I ran a number of tests, showing them to Glenn for his approval. In the end, we decided the best results were to upscale everything to 1280 x 720p, 60fps. This de-interlaced the material (essential for online playback), and upscaled the material for viewing on computer monitors (we found 1080p to be unnecessary, given the standard definition source material). We maintained the original aspect ratio (pillarboxing the video), and made no edits to the material, apart from muting the reference tone at the beginning, and overlaying titles onto the color bars. Any edits present were done in-camera, during the shoot. And now, finally, it's all done. You can watch all 27 original camera tapes (plus some rare bonus footage of Jay Miner) online, right here: https://archive.org/details/StellaAt20 Having watched through all of the tapes several times, I can tell you there's some fascinating, amazing footage in there. Great stories, technical background, industry insights, history, anecdotes - enough to keep you busy for, oh... about 14 hours altogether. Since these are unedited, there are stops and starts, off-camera comments, awkward pauses and just dead air. But it's all worth wading through to get to the good stuff. I hope you enjoy it! It's been a long road to get here. Some technical information, regarding how the tapes were captured: Hardware: Playback deck: Ampex CVR-75 Time-base corrector: Leitch DPS-475 Capture interface/scaling/de-interlacing: Blackmagic Teranex 3D Computer: Apple Mac Pro 6,1, 3GHz 8-core Xeon, 32 GB RAM Software: Capture: Blackmagic Media Express Video editing: Adobe Premiere Pro Audio editing: ProTools HD Video encoding: Adobe Media Encoder Codecs: Capture: Video: Apple Pro Res 422 (HQ), 1280x720p, 60 fps; Audio: 24-bit, 48kHz uncompressed Upload: Video: H.264, two-pass vbr, 10Mbit/sec, 1280x720p, 60 fps; Audio: AAC, 320kbps, 48kHz
  13. 10 points
  14. 10 points
    Slot car racing sets have always fascinated me, and I have owned a few over the years. Unfortunately, it was always difficult to find opponents to race against beyond just a few runs. I have dabbled many times with the idea of a computer controlled opponent over the years, and finally decided to tackle it as a demo project for the 2016 Chicago International TI Faire in October 2016. I have a lot of experience under my belt interfacing the TI computer to the real world, using the PIO, joystick and cassette port as interfaces, and therefore it was only natural for me to attempt doing this using my good old TI 99/4A computer. The first idea I came up with was outfitting one of the slot cars with a centrifugal force sensor that could send a wireless signal to the TI equipped with a compatible wireless receiver, and thus allow the computer to adjust the speed of the car in order to keep the centrifugal force under a certain limit that would keep the car on the track. The obvious advantage here is that this would be track independent regardless of how tough and twisted the track was. I may still do that at some point, but it required a fairly large scale car and track in order to be able to accommodate the needed electronics and power supply, and I did not want to invest in a large slot car race track at this time. The alternative idea required a different approach, with 2 problems to solve: How to sense the location of the car on the track How to control the speed of the car The sensing part was solved by strategically positioning photoresistors on the track which will sense when the car is over them and thus report back a location to the computer. One only needs to know where a particular type of track starts, whether a curve or a straight, and adjust the speed of the car accordingly. These track sections will be labeled as sectors with a fixed car speed for each optimized by trial and error. Here's the basic circuit diagram: When the photoresistor is fully lit, i.e. there is no overlying car, then its resistance is very low and the PIO line is connected to the positive pole of the battery, and so is in a high state or 1. When the car is on top of the photoresistor, then the latter's resistance becomes very high, therefore the PIO line goes to ground or 0. From there, it's just a matter of masking in software the appropriate bit in the PIO data lines (there are 8 of them) to find out whether it is high or low and thus figure out which photoresistor got triggered. Since there are 8 available PIO lines, it's possible to detect up to 8 sectors on the track. As for speed control, I decided to use the cassette port motor control plug for the purpose. Earlier on, I had experimented with that method to ignite a rocket motor igniter at the request of a fellow TIer (Omega) as seen in the video below: https://youtu.be/4FHgEjmP8C4 Here, I replace the igniter with the connection to the track hand controller which is nothing but a variable resistor. The problem here is that when the relay is activated, then the slot car will get full power and will very likely fly off the track in an instant. One way I came up with to mitigate that problem was to use what I call Pulse Frequency Modulation, where full power is applied for a very brief amount of time, but then repeated frequently. The frequency of the on/off cycles will then determine the speed of the car. The frequency can be easily controlled in software and again I relied on a previous project where I control a robotic arm with the TI as detailed below (skip to 14:11 for the relevant part): https://youtu.be/HrDUJUfcD2k And here's the basic control circuit. I will be using a solid state relay instead of a mechanical one for durability, speed of actuation and lack of bounce. So now we have solved both problems, and it's just a matter of experimentation and putting it all together. I created a small PCB which incorporates both the sensing and motor components as discussed above. The slot car racing set I'm using is a cheap small one which only requires 5 photoresistors. The PCB layout was designed using Circuit Wizard and the PCB was produced using a homebrew process. And the finished product. It won't win any design awards, but hey it's functional Here's the source code for the control program: Below is the video of the experimentation and the completed project: https://youtu.be/TNhTnfGklIg That was a fun one SLOTCAR.dsk
  15. 10 points
    Another game from Bob, another box from me:) This time based on the artwork of the arcade manual.
  16. 10 points
    A while back, Nathan posted some well thought out mockups detailing how to do Bosconian on the Atari 2600. There was a bit of discussion, including a suggestion by supercat for drawing the stations using players instead of the playfield. But nothing came of it - until today. Two weeks ago I approached Nathan about possibly using the routines from Space Rocks to implement his ideas. Those routines seemed ideal as they support objects with unique colors as well as the ability to set their size and do the left/right shifting for supercat's station suggestion. I expressed the desire to have something to post today, which is the eight year anniversary of that blog post. After that I decided Nathan's original idea of using the playfield would look better (less flicker) so it would make sense to use Frantic's routines instead. One problem I had was Bosconian can have a lot of shots flying around and Frantic's routines were limited to just 6 shots. So I started to revise it to support missile repositioning. Ended up having to drop the ball object to make that work but I was able to figure out how to reuse the missile objects. Tricky part was keeping the size changes of the missiles and players in sync (as each player/missile pair uses a single register to control their sizes). The solution was to only worry about the player size when repositioning the player, and likewise for the missile size and its repositioning. After all the objects have been repositioned, then run a "clean up" routine that fixes all the size changes. If you care to look in the code, available below, check out function FixSizes(). I then had second thoughts about using the playfield due to the shear amount of data that would be moving around due to the desire to use single line resolution for the station detail: So I decided to drop the playfield and add back the ball object. That's when I figured out that Slick Kernel that can reposition an object on every scanline. Since I could reuse the objects so frequently, I decided to update COLUPF when repositiong the ball instead of CTRPPF. This means the ball is a fixed size, but each instance of the ball can be a unique color. One thing not really worked out was the radar display. Nathan's mockup included the ingenious idea of using an indicator on the edges of the display: But recently Ed Fries posted Rally X were he'd worked out a rather slick radar implementation that shows the flags, cars and player position all in different colors without any flicker. I thought that would work well for Bosconian. Since the radar uses both players, the normal 6-digit score routine can't be used in the same screen section as the radar. Since the radar would look odd all by itself, I decided to go old-school and use the playfield to display the score and lives information. After a couple weeks of late night coding sessions, we have something to show. It's not yet a playable game, though you can fly around the sector (or quadrant, we haven't decided ). Start of the menu Game screen. I'm rather pleased with how the starfield turned out. The arrangement and color is randomly generated at the start of each round. Each star maintains its color, even as they move in the background. Diagnostic display showing processing time remaining for Vertical Blank and Overscan: The divider line and corners of radar are used for the "Condition Color". Above you can see Green and Yellow - it can also be Red: An early build displayed the condition using a colored character: Controls: Left Difficulty - A= Diagnostic (time remaining in Vertical Blank and OverScan) Left Difficulty - B = score display (currently just counts up and shows in hex to test the digits) Right Difficulty - A = freeze ship (useful for looking at station damage) Right Difficulty - B = ship moves SELECT = return to menu START = start game Joystick = move around in sector/quadrant Fire = shoot (collision detection is not yet in place) Please remember this is very early build. You'll see issues such as flight angles(I'm look at you 45° ) that are not compensating for the non-square pixels as well as occasional jitter. Using the diagnostic display I can tell that Vertical Blank is overrunning when there's a lot of objects onscreen (see level 6), and Over Scan is sometimes overrunning when you start a new level. I believe that's due to the level init routines that prevent the randomly placed asteroids and mines from overlapping each other or the stations. If you're checking this out with Stella, be sure to turn on phosphor mode! open Draconian in Stella hit TAB for the in-game-menu select Game Properties Select the Display tab change Use Phosphor to Yes click OK select Exit Menu Reload the ROM (Control-R) ROM draconian_20140328.bin Source Draconian_20140328.zip
  17. 10 points
    Remember the days when comic strips would fill an entire newspaper page? Well... here you go! (Click here for supermassive version) (1.6 MB) 236 < PreviousIndexNext >
  18. 9 points
    (click on image for supermassive version) 359 < PreviousIndexNext >
  19. 9 points
    Out of curiosity more than anything, although maybe with a slight tinge of hope, I recently picked up an ATGames "Atari" Flashback Portable. I was given a Flashback 2 about ten years ago as a gift from a couple of friends who knew I was into Atari. I plugged it in once, played through some of the exclusive games on it (most of which were terrible), and stuck it on a shelf in the closet, where it's been ever since (although I have used the joystick that came with it, since it's pretty good). The only thing I could think of to actually use the Flashback for would be to hack a cartridge port into it, and use it as a slightly smaller, less-compatible 2600 with composite video out. But I never bothered. Since then, umpteen revisions of the Flashback have come out, and I haven't been inclined to pick any of them up. But I'm not really part of their target demographic. I have a working real 2600 (several, actually), a 7800, all of my original carts, and a Harmony cart. And despite all of that, I do most of my 2600 gaming in Stella anyway. And as of the Flashback 3, even if you wanted to, you could no longer hack a cartridge slot into them, so you were just stuck with whatever games were included. Flashbacks aren't really for those of us who are already into the 2600, and own cartridges and consoles. That is, unless you're a completist and have to buy one of everything that has "Atari" stamped on it, or are curious to see how close (or far off) the emulation is, or can find some other use for the case. The Flashback is designed for people who fondly remember the 2600 from when they had one as a kid, had gotten rid of it long ago, and sees this in the store and thinks "Hey - that'd be fun for my kids." So for the cost of a couple of pizzas, they throw it in their shopping cart, take it home, plug it in, are amused with it for a little while, then after it's gathered enough dust, it goes into the closet. So keep that in mind when thinking of the Flashback Portable. Because it was designed for the same market. But, with two key differences. First, of course, it's portable. It has a built-in LCD screen, so no TV is required. This means parents don't have to bother with hooking it up to their TVs. They can just give it to their kids as soon as they get it home, and the kids can play with it anywhere. It's simple. There are no controllers to connect, no AC adapter to plug in. No extra parts to lose or break, except a USB cable for charging, which you can get anywhere. Sure - the kids would rather have an iPad, or an iPhone, or a Nintendo DS, but this is much cheaper. Besides the price, there are no extra games to buy and no worries about data charges or in-app-purchases. With a 20% off coupon, I was out the door of Bed Bath and Beyond with one for just under $35 including tax. And when I say this is portable, it's really portable. Much more so than I was expecting. It's noticeably smaller (and lighter) than my PSP, and much smaller than my Lynx. In fact, it weighs exactly as much as my iPhone 5 (with case), and isn't a whole lot bigger (although the Flashback's screen is certainly smaller). The second key difference, is that in addition to the 60 built-in games, the Flashback Portable also has an SD card slot. This means you can load up more Atari 2600 games on it. A lot more. The menu is limited to 103 pages of games, with 10 games per page. So unless you have a pretty extreme ROM collection, you probably aren't going to run out of room. To sort mine better, I batch renamed my ROMs with a manufacturer prefix. ACT = Activision, for example. There are a few quirks with using an SD card to be aware of which you can read about here. And if you're on a Mac, there are a couple of other things you should know about to get the SD card to work well. It's going to be non-obvious for the typical buyer to get this to work, so this was definitely something added for Atari enthusiasts. Or more likely, Sega enthusiasts. Which we'll get to shortly. Capacity aside, it's probably a good idea to pare down your ROM collection for the Flashback Portable anyway, since you can't set up subdirectories to organize your ROMs, and after a few dozen pages worth of games it becomes tedious to page through them. That, and a bunch of your games probably aren't going to work anyway. Of the games tested (as of this writing), 512 work fine, 72 have issues, and 124 are completely unplayable. Not all games have been tested yet, but it's hit-or-miss as to what works. Almost nothing from Tigervision works, yet Parker Bros. is a mixed bag. Activision fares better, but quite a few of their games have annoying (but not fatal) graphical problems. A lot homebrews do work, but there are still quite a few that have issues or just don't work at all (typically odd bankswitching schemes or DPC+ games). And you can forget about getting any SuperCharger games to work. If playing your favorite games is critical to you, it's best to check the compatibility list before buying. Even for some games that otherwise work - you may not be able to actually play them. With only a d-pad, the Flashback Portable is effectively useless for games that need paddles (or a keypad). That brings up the odd button layout of the Flashback Portable. While they managed to squeeze in all of the original console switches (and even added pause), the layout isn't exactly intuitive, and unfortunately isn't ambidextrous. This latter point is really a shame, since you only need one fire button for 2600 games and they could have easily made the existing layout ambidextrous by just swapping the S and A buttons and flipping the d-pad and display around in software (presumably). Also, as mentioned, there's no paddle control - even though there appears to be plenty of room in the unit to add a small potentiometer (to save space, it could have been recessed into the side of the unit). But the lack of the paddle control as well as the overall layout was dictated by AtGames wanting to build this as cheaply as possible, so they used the same molds for this and their Sega Genesis Portable (which requires the six-button layout and has no use for paddles). Given that the Sega unit was likely to be a bigger seller, it made sense for ATGames to put their resources behind that, rather than making something more specific to the Atari. Consequently, the Atari controls are a bit compromised. That said, I've found the d-pad to be pretty good, and the fire button is nicely responsive. Playing Joust, for example, is no problem. Note however, some people have reported issues with the d-pad registering directions, or the fire button feeling stiff, both of which are likely attributable to the inconsistent (read: cheap) build quality. In other words, save your receipt. The screen looks very nice - surprisingly so. Crisp and bright, although the viewing angle isn't great, as certain colors will appear different to each eye, making the display appear to flicker, even when it isn't. But it's still much better than what originally came on the Lynx or Nintendo GBA-SP, showing how far LCD technology has come - especially for the price. But here again, build quality seems to be a letdown, with at least one report of a dead pixel (and at this resolution, these are pretty big pixels), and some reports of the screen being installed crooked or off-center. Again - save your receipt. Don't be afraid to take it back for an exchange if the unit has noticeable issues. These were built to be disposable, so consider yourself lucky if you get a keeper the first time out. Speaking of disposable, the battery isn't replaceable. At some point, someone will figure out how to hack a new battery into it, but it's certainly not designed to be user-replaceable. While I haven't played mine to the point of failure yet, the manual claims that after a full charge you can expect 4-6 hours of battery life. That's not bad, but the charging time is really long. The manual states that the first charge will take about 11 hours (I left mine in overnight, and it was still going the next morning), and subsequent full charges will take about 7 hours. There is no charger included - just a USB cable that you can plug into a computer or standard USB charger to recharge the battery (the charger for my iPhone worked fine). I don't know if the unit will run directly off of a charger once the battery is shot, but having to plug it in while playing would sort of defeat the purpose of a portable anyway. Audio emulation is acceptable - it still sounds like a 2600, but it can be noticeably off on some games. Also, the speaker emits an annoying buzz, but it isn't bad if you don't have the volume up too loud. The unit has a headphone jack, and an A/V output jack if you want to hook it up to a TV (cable not included, of course). I haven't tried the TV output, so I can't speak to its quality. But I didn't buy this to hook up to a TV. If I were to use it like that, I'd want to be able to plug proper controllers into it as well, and that's not an option. One of my biggest disappointments with the Flashback Portable though, are the built-in games. For a lot of it, ATGames is scraping the bottom of a pretty empty barrel: Adventure Adventure II Air Raiders Aquaventure Asteroids Astroblast Atari Climber (aka Climber 5) Black Jack Bowling Breakout Centipede Circus Atari Crystal Castles Dark Cavern Demons to Diamonds Desert Falcon DodgeEm Double Dunk Fatal Run Frog Pond Frogger Frogs and Flies Fun with Numbers Golf Gravitar Hangman Haunted House Human Cannonball Millipede Miniature Golf Miss It! Missile Command Night Driver Pong (Video Olympics) Radar Lock Realsports® Basketball Return to Haunted House Saboteur Save Mary Secret Quest Shield Shifter Slot Machine Solaris Space Attack Star Strike Starship Stellar Track Strip Off Submarine Commander Super Breakout Swordquest: Earthworld Swordquest: Fireworld Swordquest: Waterworld Tempest Video Checkers Video Chess Video Pinball Wizard Yars Return Yars Revenge Frankly, this list really doesn't represent the 2600 well. Certainly not the best of what it can do. While there are a number of genuinely fun titles on there, there's too much filler. Any of the games requiring paddles are effectively unplayable. Radar Lock should have a second joystick for weapon selection. A lot of the titles are horribly dated even by the 2600's standards, and the unfinished Tempest prototype is outright garbage. Some of the games can't really be played without a proper manual (although it could be argued the Swordquest games couldn't even be played with one), and homebrews aren't very well represented as Miss It!, Shield Shifter and Strip Off are all mediocre at best. I cringe when I think of someone taking this home, hoping to re-experience some of the great gameplay the 2600 had to offer, only to be confronted with the likes of Blackjack or Fun With Numbers. Arguably, one of the best games on here (and one featured prominently on the box) is Frogger - but it's not even the 2600 version. It's a custom port - closer to the arcade game - designed to run natively on the Flashback Portable's hardware. Presumably, Konami didn't want the original Parker Bros. version to represent their brand anymore. (And yes, I know about the music issue. But it would have been relatively simple to just hack that out of the 2600 version). And while it's a nice version of Frogger (and the one game the sales clerk mentioned when I bought it) I would have rather seen them put their efforts into using the SuperCharger version. The version on the Flashback Portable has absolutely nothing to do with the Atari 2600 in any way, shape or form, so at best it seems disingenuous to me. But hey... they've gotta put something on the box to sell these. It's sure not going to be Wizard and unfortunately, it's not going to be Space Invaders either. While originally slated for the Portable (again, as another remake) it was pulled before the final units went into production. You won't find most of Atari's best arcade ports on here either: Battlezone, Berzerk, Dig Dug, Galaxian, Joust, Jungle Hunt, Moon Patrol, Ms. Pac-Man, Phoenix, Stargate, Vanguard... or any arcade ports produced by any other companies. Or any classic Activision games. Or Imagic games. Or... well, you get the point. There's so much missing here, it's hard not to be disappointed that at least some of it wasn't included. Yes - it costs money. But it could have made this unit so much better out of the box. That's why the SD card slot is this unit's saving grace. While not all of those games work, at least you can load up some of them. That makes this worth having. Without the SD slot, I never would have bought it based on the included games. So while that's fine for myself or other Atari enthusiasts, I just wish the built-in game selection was better for those casual buyers who will never, ever, load up extra games on it. However, for the rest of us, because of its price, its size, and the fact you can load games onto it, the Flashback Portable is worth a look, despite its other shortcomings. If they could have just made the emulation a little bit better, it would be an unqualified "must-buy". As it is, it's a pretty fun, cheap, portable way to play some 2600 games. And until this came along, that was not an easy thing to come by. In the end, I think Dave Dries summed it up best, "for the price, it's a really cool toy". If you think of it that way, and what you're getting for the money, it's a pretty amazing little piece of gear. If you want it to be a fully compatible, portable replacement for a real 2600, you're going to be disappointed. Check the compatibility list first - and use that as your guide for whether or not you'll get your money's worth. For me, the lack of paddle support is fairly minor, and I wouldn't expect game compatibility to extend to homebrews using DPC+ or esoteric bankswitching schemes, but I would have hoped for better vintage game compatibility. I think the Flashback Portable is about 70% of the way there. So I'll give it a 7/10.
  20. 9 points
    Between working on 7800basic, recent MESS updates, and a few side projects, I've been also working on a 7800basic game thats an update to the old classic, Crossfire. In its current state its a bit rough, with programmer graphics, preliminary sound effects, and just a few essential stats on a plain scoreboard. On the plus side its playable, the difficulty does ramp up, and there's Crossfire fun to be had. salvo2085.bas.a78 salvo2085.bas.bin The project is eventually supposed to be a re-imagining of Crossfire, as if Williams had riffed on the concept. I have the basic implementation of hyperspace/shield/smart-bomb pick-up items, though they need more glitz. Given time I'll add humanoids to save, and a few more wrinkles. (which I'll keep close to my chest for now. )
  21. 8 points
    Ilmenit's RastaConverter is an image conversion tool for Atari 8-bit computers. I wrote RastaMovie to stitch RastaConverter images together to make movies. The movie frames have to be switched very quickly to achieve a frame rate of 25-30 frames per second. This rules out SIO or IDE interfaces as you need around 500 KB/s throughput. You have to have the frames in memory. But the largest memory expansion commonly available is only 1088K. That's only enough for around 64 frames and they have to be cut down to 16K a piece from their normal size of around 22K so they don't fill the screen. Thus, the genesis of the Atari Beaglebone Expansion or ABX. Integrating the Atari with a Beaglebone as a PBI device, I was able to effectively expand available memory to 140MB on a stock Atari 600XL. This is enough to play around 3.5 minutes of video at 30 FPS. But, what's a movie without sound? So, I modified RastaConverter to reserve room on each scan line of the raster program to write a digital sample to POKEY and then to restore the register that had to be modified in order to do that. Then I positioned additional writes to POKEY in the intra-frame kernel so that the audio plays uninterrupted. You can see the result in this YouTube video: http://www.youtube.com/watch?v=1irR4TQ5aMA RastaMovie can also output versions of the movies that can be played on Atari800 and Altirra. It takes advantage of the fact that segment loads are instantaneous to simulate large amounts of RAM. These executables won't work on real hardware however. Check out birds.zip, epic.zip and im.zip in the downloads area of RastaMovie's github home page.
  22. 8 points
    checking sprite and tile "collisions" The 7800 has 2 types of display objects, sprites and character/tile graphics. Usually a game's display is made up of tiles for the background, and sprites for the moving objects. As a game designer, at some point you'll probably want to check which tile(s) your game sprites are moving over, or about to move over. Maybe you need to check if pac-man is eating a dot, or if the adventure hero is going to hit a barrier. Checking tiles underneath a sprite is slightly complicated by the fact that tile graphics use a different positioning resolution than sprite graphics do. tile/characters coordinates overlaid on a 160x192 screen. We can check which tile is under any single point on our sprite by taking the sprite coordinates and dividing the X and Y coordinates by X and Y conversion factors. The exact conversion factors you use will depend on the tile resolution you're using. Lets take the example of a full screen of 320A tiles with a zoneheight of 8. The tile resolution for this format is 40x24. The sprite positioning resolution is always 160x192, in all modes on the 7800, even the 320 ones. If we divide our max sprite resolution (160x192) by our max tile resolution (in this case, 40x24) we'll have the conversion factor. In our example with 40x24 tiles, the conversion factor is 4x8. (160/40=4, 192/24=8 ). To convert any sprite coordinate to a tile coordinate, we'll divide the sprite X by 4, and the sprite Y by 8. Now that we've converted the sprite coordinate to a character coordinate, looking up the character underneath that coordinate is a snap, with peekchar... lookupchar=peekchar(mapdata,tilex,tiley,40,24) The value returned will be the character index - literally the location that tile within the graphics block. If you're unsure which value you need to check for, you can always display the value returned by peekchar using the plotvalue command. which points should you check? If the sprites in your game are always aligned with your characters - if the sprites never overlap any tiles - then you can use any coordinate underneath the sprite. The one you use to plot the sprite is probably handy. But most games have smoothly moving sprites, which can overlap multiple tiles in both X and Y. While checking every point underneath the sprite isn't computationally feasible, in these cases you'll probably want to consider more than one point when checking for movement collision. To do a check to see if a sprite can move upwards without interference from character barriers, it's typical to check 2 points above the player - one at the top-left position of the sprite, and another at the top-right position - and see if both contain character #'s you have designated as "walkable". If so, then the player is allowed to walk upwards. For other directions you'd check another 2 points. For example, when moving left, you'd check 2 points just left of your sprite, one at the top-left corner of the sprite, and another at the bottom-left corner. Keep in mind that this isn't a recipe that you can adapt to every game. Other games will need to check other sprite points, as game mechanics require - the pac-man code checks the sprite point near the center of the pac-man sprite, to see if he's eaten a dot tile. Similarly, you'll need to decide which parts of your own sprites need to interact with the tiles.
  23. 8 points
    So it's time for a new hardware interfacing project for the TI 99/4A, namely a wireless weather station managed by that venerable computer. I think it will be a fun project but likely with a steep learning curve. The goal is to have a functional prototype in time to demo at the 2017 Chicago Fair. So where does one start? The most obvious would be finding a cost efficient and relatively easy way to achieve wireless communication between the various sensors and the computer. I believe the Xbee series 1 modules fit the bill quite nicely because they have a range of about 90 meters (300 feet) which is more than enough for the average user and they come pre-configured for serial communication. I chose the version that has a connector for an external antenna in order to maximize the transmission range. These modules have integrated ADC as well as digital inputs and transmit data serially which can be captured by a sister Xbee module connected to the computer. Unfortunately, they would not be enough by themselves because there are few sensors that can interface directly with them without some sort of processing first, and so a microcontroller is going to be needed for support and data packaging within the sensor array. With so much community support and experience available for the Arduino, I decided to go with the Arduino Uno using the Sparkfun Redboard. It comes with installed headers and connectors, making it easier to access and interface. Now for the sensors: While I could design and build my own mechanical components for wind speed, direction and rain level, it would be a pretty laborious process. So I opted to go with a ready made solution that is super easy to interface, again from Sparkfun: This is a purely mechanical device with no embedded electronics, and the data interpretation is via checking the state of various switches. What is even better is that it has a direct interface with the Sparkfun weather shield for the Arduino Uno which also includes pressure, humidity and luminosity sensors. All we need now is a temperature sensor, and the one below is inexpensive and pretty easy to use. It is analog, so it will be earmarked for one of the Xbee ADC inputs. This should round up the sensors for our weather station. The last thing we need is the Xbee serial explorer board to connect a receiver Xbee module to the TI 99/4A via the serial port. So far, this is going to cost around $215, and will likely need another $25 for various connectors and support items. So no, it's not exactly cheap, but the fun factors of putting all this together will be priceless! Now what? Well, first of all I'm going to have to get familiar with the Arduino since I have had zero previous exposure to it. I have always used the Raspberry Pi for my other projects, but it would not have been suitable for this one. That is going to take a little time. But even before that, I'm going to have to dig deep into the Xbee documentation and come up with some communication tests, likely using only the temperature sensor for starters since it can connect directly to it, and see if I can transmit data wirelessly to the TI. Update 1/28/17 First things first: Since the Xbee modules communicate via serial protocol, I needed to understand how that worked on the TI. It's definitively more involved than parallel communication, with a multitude of registers and CRU bits needed to be accessed in the 9902 UART chip in the RS232 card. Here Thierry Nouspikel's encyclopedic site ( http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm ) came in to the rescue with clear explanations and code examples. Obviously this is all done in assembly which is fine. However, I recently found out the Rich Extended Basic (RXB) by Richard Gilbertson actually has a command called CALL IO which allows direct access to the CRU without resorting to assembly language! Below is an explanation by Lee Stewart about how it works: CALL IO(type#,bits,cru-base/2,var,var) If you set a variable named CRU to half the PIO CRU-base-address of >1300/2 = >0980 (2432), you can address CRU bits by adding to CRU in the call. The following code will set, test and reset (clear) the indicated bits: 100 CRU = 2432 110 CALL IO(3,1,CRU,1) ' SBO 0 ;set bit 0 120 CALL IO(3,1,CRU+7,1) ' SBO 7 ;set bit 7 130 CALL IO(2,1,CRU+2,X) ' TB 2 ;test bit 2 and pass value to X ... 300 CALL IO(3,1,CRU,0) ' SBZ 0 ;reset bit 0 What this means is that at a minimum I could test my setup directly from within RXB without the need for coding in assembly with its associated cumbersome and time consuming development cycle of Edit/Compile/Run. And if it works out well, then there is a very good possibility that I might be able to code the entire project in RXB and bypass assembly altogether. Update 1/31/17 At this stage I have configured 2 XBee modules for 9600bps 8N1 communication protocol, and attached one to an Arduino Uno via a shield, and the other to the serial port of the TI using an XBee serial adapter. The way XBee works is that if one of the modules receives data on its Data In line, it will serialize it and transmit it wirelessly to the Data Out line of all the other XBee modules in the same network. I have therefore connected the XBee DOUT line to the Arduino's Rx (receive) line, and the XBee DIN line to the Tx (transmit) line. There is a very small test program running on the Arduino which basically watches for data to show up on the Rx line, reads it, and if it is an 'a', it turns an LED on, and if it is a 'b', it turns that LED off. On the TI side, I am running TELCO with the same communication parameters as the XBees, using a null modem serial cable. When I type 'a' in TELCO's terminal, the LED on Arduino lights up, and it turns off when I type in 'b'. Simple, but a great proof of concept nonetheless. Here's a quick video of the demo: https://youtu.be/-9D0889Mks0 Update 2/27/17 On this next step, I switched over to using RXB on the TI side using the CALL IO functionality, and it worked beautifully, thus obviating the need to use assembly for this project. It took some fiddling and lots of help from the AtariAge TI community, particularly Stuart, to properly configure the TMS9901 chip in the RS232 card to work with the Xbee given that we are only using the Tx and Rx lines with no flow control whatsoever, but we eventually figured it out. The only downside of this kind of set up is that the Arduino is much faster than RXB, and so delays had to be introduced in order to get a reliable transmission, in the order of 500 msecs per byte transmitted. From there, I moved on to actually connecting a temperature sensor to the remote arduino's analog inputs and tried to read the temperature data on the TI. The raw analog input from the sensor was converted by the Arduino to a float temperature value, which in turn was converted to a string and sent byte by byte to the TI. On the other end, the TI reassembled the string and converted the final product back to a float value. Below is the video demonstrating that experiment: https://youtu.be/c9tPZM-42uY Update 3/13/17 So I've decided to add a real time clock to the project with the idea of logging the various weather parameters for future analysis and comparison. To that effect, I acquired the Sparkfun RTC module based on the DS1307 chip and communicates to the microcontroller via the I2C (inter-inter chip) protocol. Sparkfun provides a specific library for the Arduino that makes access to the various date/time parameters trivial. Here's a demo of the process. Sorry about the quality of the video but I only had a low end camera on hand... https://youtu.be/TtzBLftsX7E Update 3/23/17 I am now in the process of testing the Sparkfun weather shield which has on board a pressure, humidity and light sensors. I'm still mulling over the use of the light sensor which would be useless if the whole setup was enclosed in a sealed box. On the other hand, if I add a clear window to the enclosure, I should be able to determine sunset and sunrise times which would be nice to have and log. In the mean time, the humidity and pressure sensors seem to work perfectly. One issue that arose from using the weather shield is the fact that it utilizes all 6 analog inputs on the Arduino, and so interferes with the analog temperature sensor I am currently using. The solution is to replace that sensor with a one wire digital sensor which connects to a single digital input. I have opted to use the DS18B20 shown below. It is much more involved to set up on the Arduino side though, so we'll see how that goes. On the plus side, the sensor is weather proofed, so I will be able to have it hanging outside the enclosure without issues. https://youtu.be/NmMLNPq2_AA Update 4/26/17 After a rather lengthy hiatus secondary to being super busy at work as well as some technical issues, I have finally managed to set up the last remaining sensors. I have replaced the analog temperature sensor with a digital one, and connected the wind speed, wind direction and rain gauge. This required getting familiar with some advanced Arduino topics, primarily the use of internal and external interrupts needed for the rain and wind sensors. I also made some boneheaded programming errors such as setting a float variable to integer instead of float and wondering why my values were always coming back as zero or forgetting to solder some of the pins to the board... Eventually everything worked out fine. I did end up connecting the two center pins of the rain RJ11 connector to ground and digital pin 9 on the weather shield so I could use internal (pin change) interrupts, but this was probably not necessary once I discovered that I had not soldered pin 2 of the shield which is used by the external interrupts. Live and learn Here's the final Arduino sketch. I borrowed heavily from code examples on the net, and frankly Arduino programming is akin to building with Lego's where most sensors and interfaces come with set libraries that handle the low level programming and make it relatively easy to connect to these extensions. I have introduced a lot of delays in the program because there is no flow control between the TI and the Arduino and so I needed to allow the TI to process the data received without losses, particularly since I am using RXB and not assembly on the TI side. This translated into roughly an full update of all the sensors about once a minute, which is more than adequate for our purposes here. And here's the RXB program. Please bear in mind that this is only a test program and definitely not the final product. And here's the demo video: https://youtu.be/51o0DZ_8CwE Next is tidying up the electronics and designing an proper enclosure which I will likely 3D print. Then I will need to create the final RXB interface program and look into data logging options. Update 5/7/17 One thing we did not discuss to date is how to power up the wireless station. I suppose I could run an electrical wire to it but that would be cumbersome at best and against the spirit of "wireless"! So the obvious solution was to use solar power. To that end, got the Sparkfun Sunny Buddy solar charger module, a 9W solar panel and a 2Ah 3.7V LIPO rechargeable battery. The Sunny Buddy is a smart module that maximizes the solar powered charging process and delivers needed power to whatever project you need. It does however come setup for 450mA output charge by default, but there is a provision to add a resistor in parallel to the sense resistor to increase that current to whatever is required. The 2Ah battery should hopefully provide enough juice for uninterrupted operation at night, and the 9W solar panel is large enough for quick battery charging providing 1500mA at peak (1.4hrs charge time). UPDATE: So I feel pretty dumb at this moment... While the Sunny Buddy coupled with the solar panel charged the battery just fine, I just realized that the Arduino Red Board I have requires at least 7V for operation... Doh... Soooo, I ordered another LIPO battery with similar specs along with a second Sunny Buddy which I will connect in parallel to the solar panel and the batteries output will be in series connecting to the Arduino. The main implication here, aside for the additional cost involved , is that now it will take 2.7hrs in full sun to charge the batteries compared to 1.4hrs previously. Still pretty decent nonetheless. I also finalized the layout of the electronics, with easy access to the various components in case repairs are needed. Next is the case design, which should be pretty straightforward... https://youtu.be/V9xVJqf-tIY Final Update 6/8/17 So everything is now put together and working as it should. Yay! I'm still struggling with the use of solar power to power up the project for the following reasons: My house is surrounded by tall trees, and so any particular spot in my back or front yard will only get a maximum of 6hrs of direct sunlight The batteries can only power up the project for at most 10hrs or so It takes approximately 3.5-4hrs of direct sunlight to fully charge the batteries Therefore, starting out with fully charged batteries when no direct sun is available anymore, say 4pm, the system remains powered up till 2am the following day, although I have found that on clear days there is still a trickle charge from the solar panel to stretch operational time by an extra 2hrs. Even then, if the batteries die out at 4am, the sun doesn't peak over the trees till 10am, so there is a 6hr gap right there. Furthermore, since it takes 3.5-4hrs to charge the batteries, the system doesn't actually get back online till 2pm, giving me a total downtime of 10hrs! And it's worse if it's cloudy... Of course I could use larger capacity batteries, but then they would not fit in the enclosure and would need proportionately larger solar panels to recharge... But this issue is really only particular to my current home location. In MN, sunrise is around 7am and sunset around 9pm in summer, and so if I had that full range of solar radiation accessible, the downtime would be much shorter... I have toyed with the idea of reducing polling frequency at night to conserve power, but then I would lose a lot of data that way, particularly if it's raining. Preliminary tests did not show a substantial saving in battery power anyway. Regardless, the project still works as expected, although in my case I might forgo solar power altogether and just use electrical power from the mains with a wireless connection to the TI in the basement. I have found that the effective maximum range was in the order of 70 feet, going through several walls, but your range might vary depending on where the TI is located. Here's a video of the final setup and testing: https://youtu.be/QPheRrUmIYE And here's the source code for the control program on the TI using RXB. So this has been a really fun and hugely educational project for me. I hope you have enjoyed it as well On to the next adventure! WEATHER.dsk
  24. 8 points
    So, I've been blogging again (in case you haven't noticed). I'd stopped blogging months ago due to the blog software here being a complete, hopeless mess. (This isn't a dig at AtariAge, but rather at InVision who makes the software, and absolutely ruined it during a previous "upgrade". The worst offense being the removal of categories, completely destroying anyone's ability to organize or find content.) What started my renewed interest in blogging was when James (of ZeroPage Homebrew) took me up on my offer to try repairing his RGB-modded Atari 2600 that he uses on his livestream. It wasn't so much the repair that got me thinking about blogging, but documenting the process and writing it all up. I found that I missed writing stuff. Or more to the point, reading peoples' responses to writing stuff. On the rare occasion that happens. You can read the whole repair story in the ZeroPage Homebrew Club here on AtariAge: https://atariage.com/forums/topic/307533-atari-rgb-light-sixer-repair/ Here are the different chapters, if you want to read it a piece at a time: Chapter 1: Unboxing Chapter 2: Tracing the problem Chapter 3: Back to RF basics Chapter 4: Testing the old mod Chapter 5: Repairing some crispy wires Chapter 6: Assembling the new mod Chapter 7: Cabling for the Framemeister Chapter 8: Testing flash carts Chapter 9: Wiring up the new mod, and initial testing Chapter 10: More Framemeister cable fun Chapter 11: Reinstalling the mod Chapter 12: Reassembling and routing wires Chapter 13: Patching the case, installing Molex connectors Chapter 14: Final assembly Truly a gripping saga. At the end of that saga, I decided to repair my own 2600. Again. But first, a little recap of its history prior to that point... I bought my 2600 from Sears as a factory refurbished unit, on August 10, 1981 for $139.99. I still have the receipt: I saved a whole $8 by buying a refurb! Score! Within a couple of years though, the console stopped working, so my dad drove me out to Martha Lake Electronics (north of Seattle) to have it repaired. I'm not sure what they replaced - I think it may have been a capacitor. Anyway, my console worked just fine after that, until it was eventually supplanted in 1987 by my Atari 7800 and put away. The 7800 was likewise put away a few years later when I moved and didn't have the space to bring my games with me. (I did buy a Lynx in September 1991 though. And yes, I still have the receipt for that, too. ) Anyway, I finally started getting back into the 2600 in 2002 when I discovered AtariAge and homebrew games. Upon unpacking my games and system (which had been shipped to me by my parents), I discovered that the springs in the Select and Reset switches were shot, so I ordered and installed a new set of switches from B & C ComputerVisions. In November 2003 I installed a CyberTech S-Video mod, adding it to my Atari 2600 Video Mods Comparison Project (long since out-of-date). In early 2008, my 2600 up and died while I was testing the 2007 AtariAge Holiday Cart (Stella's Stocking). That turned out to be the hex buffer. So I bought a new one, and socketed the new chip for easier future replacement. Then, in 2011, it up and died again. But this time it wasn't the hex buffer. I tried swapping chips with a spare console (a "Vader") given to me by a friend, but to no avail. So the Vader became my daily driver. Unfortunately, it didn't have an S-Video mod, and one of the pins had broken on mine, so I was stuck with noisy RF output. In 2015 I bought a set of populated donor boards from Best Electronics. I had hoped to use them to fix my original console, but I still couldn't make it work. So the donor boards went into my Sears shell, and that became my console for awhile. It wasn't without problems though - since whenever I pressed the fire button, the picture brightness changed. But at least it worked. In 2017 I was determined to fix my console once-and-for-all. I installed a re-cap kit and new voltage regulator, and after some more chip-swapping, finally managed to get it working again. I also managed to fix my S-Video mod. Although it turns out, that fix wouldn't be as good as I thought. But it wasn't fully working. It developed an issue where the console would only work if an AtariVox was plugged into the right joystick port. But it was working enough to use. In 2018, I restored its original chrome-capped switches (because they look super-cool), but the other issue persisted. It wasn't really a problem, except that I could never plug anything into the right joystick port except an AtariVox. No joystick, paddles, keypad, driving controller - nothing. This became a problem when Robotron went into development in early 2020, and I could only test it with dual joysticks on my RF Vader, or my RF 7800. This just wouldn't do. So that brings us to July 2020, where after fixing James' console, I decided to fix mine. Finally. Permanently. So I replaced the RIOT and hex buffer, and removed and reinstalled the mod (to test the console with stock RF out). I also used a Molotow chrome pen to restore the trim around the bezel. And finally, my original 2600 was back! For about a week. Then it died again. So that brings us up to the present. It's been my intention since July to fix my 2600. Again. Permanently. Again. (I should point out by "permanently" I don't mean actually expect it to keep working "forever", but rather that everything gets fully fixed, and nothing is lingering. So "completely" is probably more accurate, although I'm certainly hoping for some longevity.) Since restarting my blog recently, I thought this would be a good time to do the repair, and document it here. Coming sort-of full circle on what got me back to blogging in the first place. But there's another reason, too. Game reviews. (Edit: It's been so long, I actually forgot to write that as Homebreviews. You'd think that would've been almost automatic by now.) I still have a stack of homebrews sitting here to review. And another stack that hasn't been shipped to me yet. And another stack on the verge of being released. I have a lot of reviews to catch up on. And I won't review games on anything but real hardware. And I don't want to review games on anything but my own, original, S-Video modded console. So it needed fixing. And here then, is that story. The problem, is that my 2600 either outputs this (which is supposed to be Pac-Man): Or this (still Pac-Man): Audio, however, works. So is this the TIA? The hex buffer again? The S-Video mod? Well, only one way to find out! Time to tear it open! The S-Video mod is under the metal shield. Thin wires (single-strand wires from an old Cat 5 cable) come out a hole in the top, and go over to a small circuit board I used to test S-Video mods with. It has an S-Video jack and two audio jacks, with a small terminal block to easily connect and test different mods. From there, I plug in an S-Video + audio cable and run it out the back of the console. Originally, the wires were soldered directly to an S-Video + audio cable, but it made disassembly a chore. So having something I could plug and unplug made it somewhat easier to work on. The downside? A 12-foot long cable hanging out the back of my 2600, which I have to unplug from my AV receiver every time I want to move the 2600. I didn't want to install jacks on the back of the 2600 since drilling holes is, well, permanent. Another downside is that running the wires through the top of the shield means that I can't really open the 2600 up, without either disconnecting all of the wires from the board, or leaving it connected and it getting in my way. Here's a closer look at the hookup board. And here it is opened up. See the problem with the board hanging on there? The wires go through the shield, so everything is connected together. The other downside is that while the single-strand wire is incredibly easy to work with, it's not durable. Bend it a few too many times, and snap! At the base of the green wire is a capacitor that's soldered to the mod board, and is also in danger of its leads snapping off (it's happened before). So I decided as part of this endeavor, I was going to rewire the S-Video mod, fixing all of these issues. Mmmmmm... fresh solder! First though, I had to figure out the problem. I removed the S-Video mod, and reinstalled the TIA, just to see if the 2600 was working. Success! Pac-Man booted up and played just fine. So the 2600 itself was healthy. The problem was with the mod. Examining the mod board revealed the problem. Look at the space between the board in the middle, and the socket (which I'd installed as a spacer) below it. It's not even! The lower right corner kept popping back out. Pulling the lower socket off revealed why. A little excess solder on the pins on the underside of the mod was preventing the pins from fully seating into the socket. You could make them seat temporarily, but they'd pop back out. (Note: the blue resistor network isn't the culprit. I had cut a relief into the socket to clear that during the original install). A few quick hits with the desoldering gun later, and the mod snapped back together, fully seating the pins into the socket. Much better! I'm not going to bore you (too much) with the details of rewiring everything. A lot of this was effectively covered in the repair of James' console. But here's the mod, reinstalled, with fresh, new wires. They've been taped flat to go around the front edge of the board (not through the shield). The capacitor is now inline, so the leads aren't under stress. Plus they're protected with some heat-shrink tubing now, too. And finally, with the TIA back in its rightful place. And I only accidentally bent one pin the wrong way putting it back, too! So, with the mod back together. Time to work on the rest of the wires. As mentioned earlier, I wanted to get rid of the ungainly 12-foot cable that I had to drag around behind my 2600. This would now be left plugged into my AV receiver. On the 2600 side of things, I'd use short cables, about a foot long, hanging out the back. These are the sacrificial cables I'd be using, shown below. The audio cable would be from Monoprice (I really like the RCA connectors they use in their Designed For Mobile line), and the S-Video cables are from Clark Wire and Cable. (These were custom made, lossless cables for an S-Video router I had in my office, that has since been retired.) To connect the console's cables to the main AV cable, I'd simply use barrel connectors. First though, testing! Having the old mod test board around (as well as another terminal block to bridge the cables) let me do end-to-end continuity testing. Next, it was time to hook up the cables to a monitor (note the barreled connections next to the monitor), and see if everything actually worked. Presto! My 2600 was finally, fully fixed! Well, almost... Stay tuned for Part 2!
  25. 8 points
    A few years ago I came across this disk of extensions to XB and was intrigued. It had nice high resolution capabilities and some interesting clock functions. I initially did some research and found it was released by Peter Kull in Germany in the 80s and that he has since disappeared from the TI99 scene. Not much more was known about it. Well, life happened so I put this project aside for a few years. But recently, having gotten back into the TI99,I pulled the old KXBII disk and decided to finally figure out how to use it with what little info I had. What I did was use the example programs that came on the disk a just test out the functions till I figured them out, or as far as I could figure them out with the information I had. What is Kull Extended BASIC II programming package. Well the name makes it sound like it's a XB cartridge but in reality it's a series of XB CALL LINKs that add high resolution and clock functions (oddly enough) to Extended BASIC. The KXBII package is very similar to Harry's Weilheim's TML (TML is much more feature laden). The main difference being that theTML package you live in the TML environment from LOAD. KXBII, on the other hand, once you load the KXBII just lives in the background till the high res graphic are invoked. You actually can run the clock functions without turning on the hi res graphics functions. This is good and bad. Good, you don't have all the memory restrictions of using hi res graphics till you need them. Bad, you have to be a lot more careful with your string and sprite management (see notes in manual). The program can be a little tricky to use (again see notes in manual) but it looks to be stable if you stay within the bounds. Still, there are some nice features; I especially like the multi colored. And it never hurts to have another tool in you tool belt. Anyway, here's and exert from the manual I created and attached is a package with the programs for it (V9t9 format). Enjoy. ****UPDATE***** update the manual. I translated a program from the Atari 8-bit, an Uno program I wrote. Found some issues and some mistakes in the manual. Here is the new manual v2. ______________________________________________________________________ manual *************** * * * EXT/BASICII * * * *************** BY Peter Kull Extended Basic II or for short KXBII is a series of CALL LINK subroutine functions which add graphics and clock functions (among other things) to TI Extended BASIC. To start. Use the LOAD program supplied with the disk. It calls the LOADEX program which loads in the extensions to memory. SOME NOTES: Memory restrictions. If you have ever used TML you know of the lack of stack space using high resolution graphics can cause. Same here. You have about 1088 bytes of stack space after you load the high resolution utility package. From test I found that means about 200+ characters of string space available for strings. But be warned, if you exceed this limit you may not get an out of memory error but just have the upper limit strings corrupted. Be sure to test and check all large strings. Also dimension string arrays after you load in the graphics package with 'INITG' and 'GRAFIK’. Otherwise it corrupts the strings. the <Break key>. The break key will get you out of any blank or gibberish screen created by exiting the high resolution graphics unceremoniously. You may have to hit the break key twice but I found it usually works. Bugs. If you put a character on the screen at about column 9, row 6 some partial random garbage will sometimes appear on that character when a CALL LINK(“PRINT”...) command is executed. Not lethal, but annoying. Sprite commands are, unpredictable. I had all kinds of random errors happen while attempting to use the sprite commands with the high resolution graphics with a limited amount of stack space left. On the other hand, if I used the sprite commands with plenty of stack space left they usually acted fine. RANDOMIZE will sometimes causes errors with the point graphic commands such as “SET” and “DRAW”. This came up when using the trick RANDOMIZE :: CALL PEEK(-31808,A) to get a fast random number. If I just put RANDOMIZE at the beginning of the program and used RND normally, though, things usually worked as normal. Not really a bug, just a consideration. There doesn’t seem to be much error checking in the values you can insert into the CALL LINK(“... ) commands. You may not even get an error at all related to the command but instead have a random line give you a SYNTAX ERROR or such. Commands: All commands are CALL LINK(“command”....) functions. LOADEX This initially loads the package into memory from the LOAD program. Loading this a 2nd time screws up display. Initialization functions. INITG ("INITG") - initialize high resolution. Always must use before GRAFIK. GRAFIK (“GRAFIK") - opens the high resolution area for use. also can be used to clear the screen in high resolution. TEXT "TEXT" - puts you back in the standard text mode. These command functions DO NOT need 'INITG’ or the ‘GRAFIK’ to work. Timer functions. TIMER (‘TIMER’,output variable) - A timer that if you divide the output variable by 39 will you roughly give you a one second counter. TIMSET ('TIMSET') - This resets the TIMER to zero. Clock functions. STELL ('STELL',hour,minute) - This sets a clock in the upper right of the screen which stays resident. START (‘START’) - starts on-screen clock. STOP (‘STOP’) - stops the on-screen clock. UHRAUS (‘UHRAUS’) - removes the on-screen clock. UHREIN (‘UHREIN’) - puts the on-screen clock back on the screen. General functions POKEV ('POKEV',memory location,input variable) - pokes data into the VDP area PEEKV('PEEKV',memory location,output variable) - peeks at data in the VDP area These DO need 'INITG' & ‘GRAFIK’ commands before use. Draw functions. PRINT (“PRINT”,y,x,"string",foreground color,background color) - this will print a string on a screen at Y,X in whatever color and background color you wish. Probably the most useful function of the utilities. SET ("SET",y,x,color) - turns a pixel on at Y,X with specified color. DRAW ("DRAW",y,x,color) - draws a line from last point (SET or DRAW end) to Y,X coordinates. PAINT ("PAINT",y,x,color) Fill command. CIRCLE ("CIRCLE",center y,center x,right y,right x,color) - to draw a circle or ellipse. (OR) ("CIRCLE",cy,cx,ry,rx,color,begining degree, ending degree) - to draw a partial circle arc or ellipse arc. Sprite functions (use sparingly they can be kinda buggy). Normal TIXB sprite functions will corrupt the high resolution screen area so always use these sprite commands when using high resolution screens with ‘INITG’ and ‘GRAFIK’ commands. SPRITE ('SPRITE',sprite#(1-27),char$ number(32-127),color,Y,X) - Works like the sprite function in TIXB except you can not define the speed. CHAR ('CHAR',char$ number(32-127) ,’Char def of sprite’) - You MUST define each char used for the sprites with this command. They are not the same as the chars defined for the PRINT command. COINC (sprite#, sprite#, tolerance, output variable ) OR (sprite-number, dot-row, dot-column, tolerance, output variable) - works like TIXB sprite coincidence except no ALL command. DIS ('DIS',sprite#,y,x,output variable) (OR) ('DIS',sprite#,sprite#,output variable) - works like TIXB sprite DISTANCE command POS ('POS',sprite#,y,x) - Works like TIXB sprite POSITION command. DEL ('DEL',sprite#) - removes a sprite from the screen. LOC ('LOC', sprite#,newy, newx) - relocates a sprite on the screen. COL ('COL',sprite#, new color) - changes the color of a sprite. PAT ('PAT',sprite#,new char#) - changes the char pattern of a sprite. MOTION ('MOTION',sprite#,yspeed,xspeed) - changes the speed of a sprite. same values as TIXB. Kull XBII.zip
  26. 8 points
    I had a few hours to test the console and I must say, I am overall disappointed. Positives first: Very good HDMI output (it even remembers the last 16:9 or 4:3 setting, which is a surprise) Convenient form factor and nice design (though I wonder why the woodgrain is orange?) Convenient to use IF it works Very little lag The CPU seems powerful enough for newer Stella versions PAL ROMs work well too (though the picture is somewhat small for PAL50) Negatives: The software is a only stub! (at least there is hope for improvement here) Not only did they use a very outdated version of Stella (5.5 years old!), but that version is almost completely unaltered. E.g. it says "State 0 saved", which indicates that one can save more than one state (like with Stella). But you can't! So why didn't they at least remove that number? That's a one minute change! (Stephen took the time to fix it) Since the code is unaltered, Stella is writing its (of course unchanged) configuration files to the SD. If this process is interrupted, e.g. by using the cart slot or switching off the console, there is a high risk that the configuration gets corrupted. This can cause all kind of problems with Stella (e.g. not responding fire buttons) and can only be cured by manually restoring the configuration file. That's the opposite of plug and play. (fixed by Stephen Anthony) The menu is extremely simple and minimal. It has only 18 entries (hard coded!), no subdirectories, no paging and the game name gets mutilated to just 8 characters. (*) Initially, not even the license link was spelled correctly. Quality control??? You can only select a new ROM by switching off and on the console. This takes a while and I wonder how long the power button will survive this (see below). There are so many buttons on the console which could be used here (e.g. press Load and Save together). (*) Finally I had a brief look at some of Hyperkin's software and I am not impressed. It looks like a cheap hack job. A far cry from the quality of Stella's code. [*]The dumper might have been a good (marketing?) idea, but as it is now, it is pretty useless. It only works with very few bankswitching schemes (only Atari 8K and 16K, named F8 and F6, details here), so that bank switched games are prone to fail. (e.g. Parker, Tigervision, M-Network, CBS, Activision) Even some carts using a supported bankswitching scheme fail randomly. Modern homebrews (even those who don't use ARM hardware) also fail regularly. Even games <= 4K fail, sometimes an inserted cart is not even detected. If the dumper fails, there is not even an error message. The code for the dumper is not available (yet?), so there is nothing which can be done here. If the code ever become available and can be improved, it is unclear if the average user can make use of that If a dump is successful, why does it not save the ROM to the SD cart? Then it would at least make some sense now. [*]Even the emulation itself has severe flaws. The old Stella version does not support many modern homebrews and has problems with a few old games (e.g. Kool Aid Man, Meltdown) Emulator and TV are not synced, this causes massive tearing on horizontal scrolling games. For some people, Paddles are basically useless, since they react very erratically. For me they work OK. Many controllers which support extra buttons do not work, they often cause the console to crash. Keypad, trackballs, driving controllers etc. are not supported at all. AtariVox/SaveKey does not work too. [*]The build quality seems flimsy. Many people reported easily broken joysticks The console buttons are not best quality too The power switch feels like it may break soon The cartridge port is unprotected, so that dust may get into it. Also when plugging in a cart, the mechanic feels less sturdy than on an original console. (I will extend the list when I have more time for testing.) So the basic roots are there for a good alternative to a console. But in its current state, I would not suggest to buy one. (*) Look here for an improvement.
  27. 8 points
    NOTE: If you're not familiar with 6502 assembly language, take some time to check out the Easy 6502 tutorial. For my Atari 2600 Homebrew presentation I've been giving a rundown of the challenges involved in writing an Atari game, namely the limited resources and capabilities of the hardware, as well as the tools (DASM, bB, Stella, Harmony, etc) and resources(AtariAge, Mini Dig, etc) that are available to help you. I've been updating the presentation for each time I give it. On the most recent update, for the 2013 Houston Arcade Expo, I added code for a very simple 2600 program. You can see it here, starting with slide 51. You can also download the source and ROM from my website - colorful.zip. The code addition went over very well so I've decided to expand upon it for my next presentation, which will be given the weekend of August 16th at the Classic Game Fest in Austin. I decided a very simple game would be the way to go and have worked up a mockup of what it might look like: The game's going to be called Collect. It's a 1 player game and your objective is to collect as many boxes as you can before the timer runs out. My goals for code are to show: How to use TV Type, Select and Reset console switches How to use joystick to move player How to use the hardware collision detection How to use a 2 Line Kernel to draw a reflected playfield with 2 players and 2 missiles Sound Effects (timer tick, collected box, end-of-game) For this tutorial you'll need to have DASM to compile the code as well as Stella and/or a real 2600 with a Harmony cart to run your code. COLLECT TUTORIAL NAVIGATION <PREVIOUS> <INDEX> <NEXT>
  28. 8 points
    345 < PreviousIndexNext >
  29. 8 points
    335 < PreviousIndexNext >
  30. 8 points
    I got on it this weekend with this machine (and I am tired of scrubbing). I scrubbed the case down with heavy duty decreasing cleaner (says to dilute with water, bah who has time for that) and a bunch of paper towels and rags and a brush. That was fun once I did that I tore apart the keyboard, and did the same on each individual key, even more fun .. Friday afternoon I hit the dollar tree and got 3 aluminum baking pans large enough to hold everything, 6 quarts of 3% hydrogen peroxide and a bucket of generic oxy clean (which is good for the wash anyway). My stock recipe is as much peroxide as possible, and top off with hot water from the tap, which has as much oxy as it possibly can hold, set out in the sun and let her do her thang. The case was not too bad and after a full 9 hours in the sun, its pretty much going to do what its going to do. The keys on the other hand were super yellow and stubborn so they sat out all day saturday, overnight and all day sunday with a refresh in oxy. They turned out a heck of a lot better than they were, but they are still tan and still uneven, I will revisit this at another time in the process, but at least they don't look nasty anymore While messing around, its been my intent to install a SIO2SD internal to this machine, and the LCD for that will be a blue backlight, I think it looks good against the cool grey of the case. The power on indicator LED on this machine is very weak due to age and use, so since I am going to have a blue LCD screen I might as well have a blue power light ... but the default lens is red, therefore it would turn out purple, I do not want purple. I broke of a shard of thin acrylic (that I keep around for various things) from a scrap strip and started sanding, and sanding, and sanding, until matching the profile of the original lens, and I think that turned out pretty good Sanding Test fit Result
  31. 8 points
    https://www.youtube.com/watch?v=k9JihWhN4zk Quite a few updates in this one! There's all new graphics and color sequences for the explosions. To support this the existing explosion routine had to be rewritten from scratch. In fact, a number of routines have undergone revisions so let me know if you spot something odd. While play testing I discovered something about the destroyed station pods that we didn't get quite right for the vertical station. For the horizontal station, after destroying this pod it's not possible to shoot the one just below it. This matches the arcade: However, for the vertical station, after destroying this pod you have a clear shot at the pod to the left. That makes it much easier to take out a station. At the same time Nathan was play testing, and he discovered it was possible to hit the core with a diagonal shot between two destroyed pods: So destroyed pod graphics have been updated to prevent both issues: Even with that change the diagonal shot was still sometimes attainable, so we fattened up the player's shots a touch. Lastly cd-w's made some updates to the CDF driver. He fixed fix a noisy audio issue when using IRQ Audio mode (I hadn't been using that mode until now because the noise was so bad!), resolved a compatibility issue with the 7800, and changed it to zero out C Variable storage upon boot to fix a problem with static variables. We are aware of one remaining issue with the CDF driver - if you flash the Harmony with a CDF game it will boot up OK on a 2600, but might not boot on a 7800. For Harmony or Stella (requires Stella 5.0.0-pre8 or newer) draconian_20170607.bin
  32. 8 points
  33. 8 points
  34. 8 points
    Wah wah wah wah, wah wah, wah wah wah wah. Sorry... couldn't resist. I've been a Peanuts fan as far back as I can remember. I read Peanuts books and drew Peanuts cartoons as soon as I was old enough to read a book or hold a crayon. I've still got a picture I drew as a little kid of Snoopy's dog house (a cutaway view showing the inside and all of the stuff that he had in there), and there's a photo somewhere of me standing in front of a chalkboard we had at home drawing Snoopy on it. I had stacks of Peanuts books that I read and re-read endlessly. I have every volume to date of The Complete Peanuts from Fantagraphics, and am now in need of a longer book shelf to fit the last few remaining volumes. Charles M. Schulz was and is the single biggest artistic influence in my life, and out of Peanuts grew my love for cartooning. Oddly enough, Charles M. Jones (the Warner Bros. director) is the second biggest influence on me. Not sure what the deal is with artists named "Charles M." something-or-other, but there you go. That said, I'm not a collector of Peanuts memorabilia. I never kept my original, old Peanuts books in pristine shape. I read them until they were dog-eared and ragged. I own almost no other Peanuts merchandise. I don't necessarily think that everything with "Peanuts" on it is a good thing. Chocolate bars, for example. Why ruin a perfectly good chocolate bar by putting peanuts in it? It's like, you're eating this really tasty, smooth chocolate bar, and then it's like biting into a chunk of particle board. I mean, by themselves I like peanuts, or as peanut butter in a Reese's peanut butter cup, but that doesn't mean I want big, nasty hunks of them in my chocolate. Same thing with Rocky Road ice cream. Why on earth would anyone... Oh. Sorry. Right. So... not everything with "Peanuts" stamped on it is good. Particularly when it comes to animation. On one hand, A Charlie Brown Christmas and It's The Great Pumpkin, Charlie Brown nailed it. They're funny, iconic, and perfectly translate the humor and characters of Peanuts over into the world of animation. But there are others. Many others. Forty-five others. And many of them were stinkers. They never quite recaptured the spirit of the original holiday specials with It's Arbor Day, Charlie Brown. They really jumped the shark though with It's Flashbeagle, Charlie Brown, when they animated Snoopy's dancing by rotoscoping a female dancer. Even though I didn't know much about animation at the time, I knew it was creepy and weird. The four original feature films didn't fare much better. While the first two were pretty good, generally they were just television specials that ran too long. Still, between the original Christmas and Great Pumpkin specials, and a really good Saturday morning TV series which basically lifted episodes right out of the comic strip, it's easier to think of Peanuts animation in a positive light, and overlook the negative. That is until a few years ago when I read the announcement... that they were going to make a new Peanuts movie, using CG. Say what? I remember getting really upset. Every, and I mean every attempt to CG-ify a traditional cartoon or comic strip character had failed horribly. Scooby Doo, Rocky & Bullwinkle, Alvin & The Chipmunks (admittedly, no great loss there), Casper, Garfield, Dino, The Great Gazoo, The Smurfs, Underdog, Sherman and Peabody... and many of them shoehorned into impossibly awful live-action train wrecks of a movie. Seriously... have you ever watched the Flintstones movie? Single worst movie-going experience I've ever had. I felt like I needed to shower afterwards. Or rinse out my eyes with iodine. Anyway, they're all catastrophically bad. That's my point. Peanuts weren't designed to be three dimensional. Look at any toy featuring them. They never really look right from any angles but those Schulz drew in the strip. He cheated their shapes and proportions when drawing them from different angles all the time - that's what cartooning is. It's abstraction. So I was expecting the CG Peanuts movie to be pretty-much the worst thing in the history of awful things. For the next couple of years, every mention of the project made me cringe. But then, I saw the . And I thought, "Hey... that's not bad." But still, it was just a teaser, and mostly featured Snoopy. Could they make a whole film work? How would they handle all of the other characters? Then came . And I thought, "Whoa. I think they nailed it." Because what Blue Sky did, which was the right way, and the only way to animate the characters, was the way Bill Melendez had figured out 50 years ago. Stick to Schulz's designs. If a character doesn't work from an angle or in a certain pose, then they shouldn't be shown that way. Blue Sky didn't animate them as in-the-round CG characters. They restricted them based on Schulz's designs, animating with 3D tools, but as if they were working in 2D. In other words, they became abstractions - just like Schulz had done when he'd created them. It looked brilliant. A slightly textured, slightly dimensional yet still completely faithful version of Schulz's cartoons. I was really impressed. I had no confidence that a studio would ever take such a different approach, especially in this day of Pixar, Disney and Dreamworks all spewing out effectively the same character designs over and over and over again. The big question then was... would the movie itself be any good? The writing has to be true to the characters, to the voices Schulz gave each of them out of his own head and his own heart. Peanuts was an incredibly personal strip to him, which is why it's in his will that it will never be continued by anyone else. Any Peanuts strip you read now are reprints. He never used ghost artists, or gag writers (which are both extremely common in comic strips). When he could no longer continue drawing the strip due to failing health, he ended it. I don't think that it's a coincidence that the very day before the last strip ran in the papers, is the day he passed away. So then... last Friday night, we had a screening of The Peanuts Movie at work. We have a theater there with a state-of-the-art digital cinema projector, and Fox and Blue Sky were gracious enough to send a copy of the movie out for our students to watch. And while you might think animation students will automatically love any animation comes along, the truth is, they can be amongst its harshest critics. Nothing makes an animator madder than wasting their time watching a bad animated movie. However, that wasn't the case. The students genuinely enjoyed this movie - laughing along with it, being touched by the homages to Schulz, connecting with the characters... all of which in a way kind of surprised me. Because from my perspective - sure, I like Peanuts. I'm old. I grew up with Peanuts when it was phenomenally popular. They named a couple of Apollo spacecraft after Charlie Brown and Snoopy, for crying out loud. But I wasn't expecting Peanuts to have crossed generations. I guess I shouldn't have underestimated their timeless appeal. The humor and characters resonate with audiences to this day. Schulz's writing ran the gamut from funny to poignant, silly to melancholy, but always with an underlying sincerity and truthfulness to it all. So did the movie work for me? I suppose at some point, I should start writing an actual movie review. But I wanted it to be very clear - Peanuts means a lot to me. I wouldn't have pursued a life in the arts without it. Getting the movie right, in my eyes, is no trivial matter. And yes, they got it right. I sat through the whole film with a huge smile on my face. The writing was spot-on (with some really funny moments), the animation was perfect (the animators obviously had a lot of fun), but most importantly - the movie stays true to the characters and Schulz's humor. It manages to update the delivery medium of the material without trying to force it into new directions that don't fit. It's not "edgy", the kids aren't spending all their time texting or making pop culture references, the characters are who they have always been. They're timeless. And even though some of the jokes are familiar to fans of the strip, that's okay - because the source material is why all of this worked in the first place. It's Peanuts, it doesn't need to be something else. In fact, it shouldn't. I really appreciated that more is made of the friendship between Charlie Brown and Snoopy than is sometimes seen in the TV specials. They're clearly best friends, and it's really heartwarming to see that emphasized. Charlie Brown is at the center of the plot, and Snoopy is there to support him. Certainly, Snoopy gets his fair share of the spotlight in his fantasy sequences, but even those exist to drive Charlie Brown's story forward. There are a lot of wonderful nods to Charles Schulz throughout the film. It's as if his own hand begins the movie, starting us off on the right track. And there are further homages to Schulz, Bill Melendez (who created the original animated specials) and Vince Guaraldi (who created the original iconic music) throughout - always thoughtful, often funny, and very touching. Carefully selected panels from the strip run alongside and tie into the end credits, which was a perfect way to end the movie. (Plus - there is a post-credits scene, so stick around for that too.) All that said, The Peanuts Movie isn't perfect. There are a few jokes which are a bit too familiar. There are a few liberties taken which are less in line with the comic strip, and more in keeping with some of the animated specials. And there's some dialog at the end of the film which is a bit clunky and overstated. I kept thinking Schulz would have found a simpler, more eloquent way of getting to the point. But in the end, it was still a delightful film to watch, and obviously a labor of love for the people who worked on it, who clearly respect and want to celebrate the legacy of Charles Schulz and Peanuts. I wouldn't mind even waiting another eight years for the next one. Load up the kids, grab some popcorn and check it out. The Peanuts Movie gets a 9/10.
  35. 7 points
  36. 7 points
    Welcome to part 2 of my 2600 repair blog thing! Didn't have to wait very long for that, did ya'? Part 1 was just getting a little bit too long, so I decided to break this up into two parts. Or maybe three. Probably three. I haven't written that far yet. In Part 1, when I wrote that I wanted my 2600 fixed permanently, there was still one thing that had been bugging me for years... My 2600 has been taken apart and put back together so many times, several of the screw holes are stripped. Two of them are so bad, the screws don't even pretend to bite - they just fall right back out. Two of them in the top of the plastic case... And two are in the aluminum shield. So now, it's time to fix finally fix that too. With these: If you read about James' console repair, you'd recognize the J-B Weld. It's super-strong, steel-reinforced epoxy, and I used it to patch a hole in his 2600's case. But paste wax?? Yep! I was thinking about how to use J-B Weld to fix the stripped holes. I figured I could put some epoxy in there, let it cure, then carefully re-tap the threads. But I wondered if it would actually work, and what that sort of stress would do to the plastic. So I did some searching, and found someone on YouTube who had come up with a better method: fill the holes in with epoxy, coat the screws with a release agent, and let the epoxy set around the screws while they were installed. Then simply back the screws out after the epoxy cures, leaving threaded holes behind! And the paste wax? That was the release agent that worked the best (which is more oily than waxy). Now, it's one thing to do this on a big chunk of aluminum like he did. But would it work with much smaller screws, and not just on aluminum, but brittle 40-year-old plastic? As they say on Project Farm, let's find out! Here are the stripped screw holes. One just behind the fake wood grain panel: And one between two of the switches. Not just stripped, but split open! In the metal, there was one on the corner: And one along the edge, which is used to attach the lower half of the case to the 2600's internals. So this one is kind of important! With James' console I used quick-setting epoxy. But for this, I used the slow-setting version. I didn't want this setting up before I could get the screws in. So I mixed up some epoxy, and filled up the holes: Next, I coated the screws with the paste wax (and believe me, they were greasy!): Then, I simply reinstalled the screws until they bottomed-out: And waited 24 hours for it to cure. The worst case scenario at this point would be if the screws wouldn't come back out. I wasn't going to try and force the ones in the plastic to come out, since they could just break more plastic around them, causing more damage. I figured with the metal I could probably get some vice grips on the screws and give them what-for if needed. But if nothing budged, I'd simply cut the screw heads off with a Dremel. Those holes weren't holding screws anyway, so my console wouldn't have been any worse off than it had been before. First up, I tried removing the ones in the metal. It took a little bit of effort (and a screwdriver with a really good Philips bit), but they backed out of the holes, leaving threads behind! But would it work with the plastic? Or would the torque I had to apply be too much, and crack the plastic? Well, no! Actually, the screws in the plastic backed out almost effortlessly! Again, leaving nice, threaded holes: I couldn't figure out why the screws in the plastic came out easier, until I realized that the screws in the metal have self-drilling tips on them. Basically, it's a groove that allows a screw to drive itself into materials without needing to drill a hole. So some epoxy had filled those grooves, and had to be broken loose before the screws would turn. The screws in the plastic don't have that groove, so there was no resistance when removing them. You can see the groove on the short screw, below. (The longer screw with the blunt tip also has a groove, but it's facing away.) Anyway, the fix worked, and the screw holes are now repaired! Now, how durable they're going to be is another matter. But I'm not going to torque down the screws in those holes very much, and I'm going to be very careful while installing them. If they last long enough to hold the console together for now, I'll call that a win. If in some future disassembly the threads break again, well, I now know how to fix them. Well, this seems long enough for Part 2. Also, I'm about 2/3 of the way through the photos I took, so I think I'll wrap this up in Part 3. Coming... now!
  37. 7 points
    354 < PreviousIndexNext >
  38. 7 points
    Late Atari Activision was one of the most ambitious yet misguided… things that ever happened for the system. After petering out in 1984 Activision decided to release a string of games for the system, and don’t forget, the NES had been out for three years at this point and the Genesis was right around the corner, as was the Game Boy. Games Activision released were ports of popular arcade games that had popular NES ports, games like Rampage, Kung Fu Master, and Double Dragon. There was even a sequel to River Raid thrown in about four years too late. I suppose these releases were meant to coincide with the release of the 7800, as well as their re-releases of classics under the Blue Label series, just to give adopters of the 7800, and folks who stuck with the 2600, something to play. All of these late releases are worthy of their own review but I don’t have any of them, well apart from one that is. You may recall a long, long, time ago I reviewed Ikari Warriors and Front Line and I’m pretty sure I blew off Commando as just another mediocre top-down shooter. But is it? I don’t think I actually played it enough to know for sure so let’s remedy that oversight today. Well, one thing’s for certain, this is the best looking top-down shooter on the 2600. Everything is large, everything is colorful, and most importantly everything is well defined. I know what I’m shooting at, I know what I’m running through and I know what I’m dodging, which is more than can be said for most 2600 games. The enemy soldiers, despite being almost completely blue, cast shadows on the ground, and there is even a shine on the tops of their helmets, and even thought the player is just a pallet swap he’s different enough to not get confused. While the environment lacks the simple texturing of Ikari Warriors it takes the Front Line approach of having many obstacles that are full of color and gradients which is really a treat for the eyes. Another thing that Commando has over both Front Line and Ikari Warriors is that the game is in Hi-Res mode, which keeps the game from feeling cramped. So the graphics are stellar all around, how do the sounds fare though? Usually with games that focus more on one of the three categories of Graphics, Sounds, and Gameplay, Graphics in this case, the other two tend to suffer. Sounds aren’t all that bad to be honest. This game is one of the few to actually have background music alongside the other sound effects, and unlike the one in Ikari Warriors it isn’t trash. It’s played using softer instrumentation and intersperses the melody with percussion to keep things from getting repetitive. The rest of the sound effects are also fairly easy on the ears, the shooting noise is one of the most realistic I’ve heard for the system and the explosions are fantastic, though the sound for picking up grenades is a bit awful but its infrequent so I can’t really complain. The only sound I don’t particularly care for that I can talk about is the engine noise for the trucks that appear in later levels, it’s low pitched and gravely and really interrupts the whole feel of the game. Okay so this is getting a bit weird, the graphics are excellent and the sounds are good, naturally this means that the gameplay will be god awful. Ehh, it’s decent at best and tolerable at worst. Overall the controls aren’t too bad, you move fairly slowly but this doesn’t impact the difficulty all too much since everything moves as slowly as you, bullets and enemies alike, but don’t think this makes the game easy or boring. This is probably the closest the 2600 is going to get to a bullet hell shooter, when you have 3 enemies on screen each shooting two bullets at you each things can get incredibly hectic. This are made even crazier with the fact that enemies have 16 directional shooting while you’re stuck only shooting up, down, left, and right, which leads to games of bullet chicken. Bullet chicken has you try to get as close to the enemies as possible to shoot them before they shoot you, sometimes you will even have to run towards enemy bullets just to get a lucky shot. You have two weapons, a machine gun with unlimited ammo and grenades which are fairly useless. To throw grenades you have to hold down the fire button which means you have to stand still to keep your aim, and as you know standing still is suicide in these types of games, so they’re fairly useless. The overall objective to the game is to get to the end of the stage, shoot a bunch of guys, and destroy the Mega Fortress while trying not to get shot. Along the way you’ll be dodging foot soldiers, machine gun nests, and runaway cargo vehicles, you also have to deal with environmental hazards, mainly obstructive barricades and palm trees, the latter of which can be used as cover, and fox holes which will kill you if you touch them. Once you destroy eight Mega Fortresses you’re taken back to the beginning of the game to go through all over again but with the difficulty ramped up. Well this is surprising, a good-looking game with a decent sound track that is actually playable and even enjoyable? I never would have thought it possible, but Activision delivered… 5 years too late, yeah when reviewed on it’s own merits it’s quite good, maybe even a gem for the system, but when compared to the standards of the time and given the fact that there was a version released on NES it’s completely obsolete. So for people who find Front Line to be too basic and blocky, and Ikari Warriors to be just about the same, then Commando just might be the right fit for you. Unfortunately since this is a late release Atari game it is a bit difficult to find. The cheapest you’re going to get it loose on Ebay is around 11 dollars and the cheapest boxed copies are hovering around 30. If you really want this game then I’d advise for you to get it loose, and if you can find a copy in the wild then you can probably get an even better deal there.
  39. 7 points
    Well, this brings us to the halfway point of the current crop of Homebreviews! The frequency of these will be slowing down some, as I have other projects piling up that need my attention. But I'll still continue to piece away at the rest of these in the coming months. Meanwhile, here are two of the best arcade ports ever to grace the 2600. And no, I'm not biased at all. Draconian Full disclosure: I worked on this game, designing the in-game graphics, converting the arcade level layouts, and creating the artwork for the label, manual and box. Draconian is Darrell Spice, Jr.'s port of Namco's arcade classic Bosconian. Your mission is pretty straightforward: blow up every space station in a given sector, then move onto the next sector and repeat. Each station is made up of six weapons pods and a main core. To destroy the station you can either shoot all six pods, or fire a shot into the station's core when its protective shielding is open. The pods will fire a steady barrage of shots at you, and periodically the core will fire a large missile at you if you get in its way. The enemy has homing missiles patrolling around that will try to crash into you, attack formations which will mercilessly hunt you down, and Spy Ships that will report your position if allowed to escape. If that happens, the enemy will throw everything they have at you as your on-board computer yells "Condition Red" over and over. The space stations are smack-dab in the middle of an asteroid field, and the enemy has laid explosive space mines everywhere - making navigation treacherous. All you have to fight back with is your trusty spaceship and its laser cannon. In most games you'd be hopelessly outgunned, but in Draconian your laser fires out of the back of your ship too! That'll teach 'em to tailgate! Draconian is an amazing port of the original arcade game. All of the elements, enemies, gameplay, and action have been squeezed into the 2600. The number of objects on screen is truly impressive, including a parallax scrolling starfield. At times there is significant flicker, but whenever that happens you're likely to be so busy you won't really notice it. There's great attention to detail - the station cores open and close revealing reactors and missiles inside, the attack formation indicator and radar display are both included, all of the arcade levels from both the Namco and Midway arcade versions are there, and in what may be Draconian's most notable feature: the game features digitized voices! Now, digitized voices aren't entirely new, even for the 2600. Quadrun had a digitized voice in 1983, although it only spoke one word, and had to blank the screen when it played. But Draconian manages to bring all of the original arcade voice samples to the 2600, and does so without interrupting the game. From "Blast Off!" to the dreaded "Condition Red!" they're all here, and they don't require any external hardware. Mike Haas did a fantastic job converting the voice samples, as well as recreating the arcade game's other music and sound effects. Draconian is a real audio and visual treat! As great as the game looks and sounds, it shines equally as bright in terms of gameplay. Draconian perfectly captures the intense action of Bosconian, including lightning-quick controls, pixel-perfect collision detection, and difficulty ramping that challenges you without feeling unfair. A slick onscreen menu lets you choose from four difficulty settings; support for NTSC, PAL or even SECAM; the option to start in any of the first 16 sectors; and which quadrant you want to play. Each quadrant features different sector layouts: Midway arcade, Namco arcade, two sets of custom-designed levels (including some submitted by AtariAge members), and one where layouts are generated randomly. Effectively, you should never run out of new sectors to play. Draconian also has a Continue option - so you can start your next game where your last one ended, and a Pause feature. The only thing missing is high score and progress saving with an AtariVox or SaveKey. But adding that would have meant compromising elsewhere, and given how perfect everything else is, it wouldn't have been worth the trade-off. I can happily just write my scores down. Bosconian never seemed to garner the sort of attention other games of its era did. It was always a favorite of mine though, and despite one of my blog posts being the inspiration that prompted Darrell to make Draconian, I never could have dreamed it would turn out like this. This is about as perfect of an arcade port as you can get. The fact that it's on the Atari 2600 is all the more incredible, and it makes you wonder if there is anything homebrewers can't make this system do. Draconian gets a 5/5 Super Cobra Arcade Full disclosure: I worked on this game, designing the in-game graphics, converting the arcade level layouts, and creating the artwork for the label, manual and box. Super Cobra is Konami's follow-up to their classic arcade game Scramble. Instead of a spaceship, you fly a helicopter across even more challenging terrain, through tighter caverns and down twistier tunnels. There are twice as many stages to fight through, with new and more aggressive enemies: guided missiles, saucers that shoot back at you, meteors that actively try to crash into you, tanks that fire at you from below, and mines that drop from the ceiling above. As with Scramble, you still need to refuel your copter by blowing up enemy depots or you'll run out of fuel and crash. Your goal is still to get through all of the stages, but instead of merely blowing up the target at the end, you now have to use your copter to carefully scoop it up and steal it. The arcade version of Super Cobra is incredibly difficult - as if it were designed to punish players who had gotten too good at playing Scramble. Being one of the first arcade games to let you add more credits to continue your game made Super Cobra a true quarter-eater. Unlike Scramble, Super Cobra had been ported to the 2600 back-in-the-day. But the Parker Bros. version had terrible controls, the scrolling was chunky, and most of the enemies had been consolidated down into just a handful of generic shapes. It wasn't the worst arcade port ever, but like many of its day, it was certainly lacking. Not so with Champ Games' Super Cobra Arcade. John Champeau has followed up his already impressive port of Scramble with an even more impressive port of Super Cobra. The "Arcade" in the title isn't simply an affectation, it's serious. As with his version of Scramble, John brought the entire Super Cobra arcade game to the 2600 intact. Every piece of terrain, every building, every enemy, every tunnel, they're all here. The enemies look and move like the originals as well: from the arcing missiles, to spinning drones, and even the tanks that chase along the ground (which is a fun enough stage to make a game all by itself). No detail was missed - the progress bar, fuel gauge, background stars, level indicators and more are all here. Even the terrain and buildings are rendered in multiple colors, faithfully reproducing the arcade game. Despite the amount of action, objects and explosions onscreen at any given time, John has done a masterful job of keeping the flickering under control. Controls and collision detection are perfect. As he did with Scramble, John made using a single fire button work brilliantly for both guns and bombs, while also including support for gamepads with dual fire buttons. The mostly-auto-fire "burst mode" makes a welcomed thumb-saving return as well. Audio by Mike Haas and Bob DeCrescenzo is excellent, from the music to each enemy's distinctive sound effects. Super Cobra Arcade also has a Continue option (no quarters required) - allowing you to work your way further through the game without having to start over, a Pause feature, and AtariVox/SaveKey support for saving high scores and game preferences. Super Cobra Arcade is an outstanding port of the original, fully earning its "Arcade" moniker. Even including Pac-Man, Super Cobra Arcade is the most dramatic improvement that a homebrew has made over a previous 2600 release. There's just no comparison between it and the Parker Bros. version. Even more impressive, John's version actually improves on the original arcade game in one key area: difficulty. Super Cobra Arcade has four difficulty settings: Novice, Standard, Advanced and Expert. Advanced is effectively the same as the arcade game: brutally hard. The enemies are numerous and aggressive, the passageways tight and unforgiving, and you will be hard-pressed to get to the base even using all of your continues. But set the game on Standard, and suddenly you feel more at home. At that point, the game feels truly like a continuation of Scramble: new terrain, new challenges, new enemies, but without the insane jump in difficulty. The enemies are fewer and a little less aggressive, the passageways are a little more open, and there's a nice balance to the whole game. Once you think you've got the hang of Standard, then you can move onto Advanced and practice up for the arcade game. If that's not enough challenge for you, try Expert, where rockets launch on every stage and tank turrets track your movement. If you manage to get far enough - even the terrain will change! The manual is laid out as comic book, written as a sequel to the one from Scramble. Super Cobra Arcade also features what may be my favorite Easter Egg ever: you can play the game using the ship from Scramble! Finally, after over 35 years, Super Cobra is a true sequel to Scramble! Super Cobra Arcade takes everything that made Champ Games' version of Scramble great, and doubles it. More stages, more enemies, and more challenges. By giving you the option of a more playable version while still keeping the arcade difficulty intact, this is everything an arcade port should be, and makes the perfect companion to Scramble. Buy them both! Super Cobra Arcade gets a 5/5 Up next: Two unrelated games without an alliterative or rhyming catchphrase < PreviousHomebreviews IndexNext >
  40. 7 points
  41. 7 points
    These showed up yesterday: Yeah... I know. Now I'm even further behind with my reviews. But it is nice to finally get my hands on some of the games I worked on. (I didn't have anything to do with Epic Adventure. But it's on my list of games to review.)
  42. 7 points
    X:8 is a new side-scrolling shoot-em-up-style game for the Atari 8-bit computer made for the ABBUC Software Contest 2013. The game will only be available to ABBUC members during a voting period. Later it will be released to the general public. Credits - Graphics / Production: José Pereira - Code / Music: Xuel - Sprites: TMR / STE'86 The graphics are converted and inspired by several other 8-bit era games including Armalyte for the ZX Spectrum, Gradius for Nintendo Game Boy, and Nemesis for Game Boy. The music is a cover of the level one theme song of Ruff 'n' Tumble for Amiga. Requirements 64K RAM Keys Start - Start or restart at level 1 or finalize high score entry Select - Toggle music Option - Toggle sound effects Joystick - Move or enter high score Trigger - Shoot Game Play Your mission is to fight your way past waves of enemy ships, ground weapons and obstacles to defeat the forces of the X:8 empire. Along the way you can collect eight different powerups dropped by enemy ships to enhance your fighting ability against enemy ships of varying strengths. Eight levels await you. Powerups Double shot - Improves primary weapons from a damage of 1 to 2. Spread Shot - Slow weapon with damage of 2. Angle shots are ineffective in this version of the game. Fire Ball - Slow weapon with damage of 3. Piercing Shot - Fast weapon with damage of 3. Ray Gun - Fast weapon with damage of 4. Invulnerability - Places shield around your ship that prevents all damage for a short period of time. Bomb - Instantly destroys all enemy ships on the screen. Extra Life - Increases your lives by one up to a maximum of eight. Technical Details X:8 uses a combination of high-res and medium-res graphics modes. The middle part of the playfield is ANTIC mode 2 (Graphics 0). The borders and status bar are ANTIC mode 4 (Graphics 12). Player/Missile graphics are used to for the player's ship and various enemy weapons and obstacles. José conceived of the screen layout and described it on the Format War forums in May of 2013. Xuel got involved after posting an initial mock-up of a rendering engine for José's idea in that thread. The engine runs at full frame rate (50FPS on PAL, 60FPS on NTSC). To achieve fast drawing speeds, many shortcuts and approximations are made. The enemies can only be positioned on a 4x2 grid. This means that only 8 different shifted versions of the enemy ships are needed. These occupy 72 characters of the ANTIC mode 2 character set that is active in the center of the screen. The rest of the characters are used for debris, powerups, stars, and enemy projectiles with various shifts pre-applied. Drawing consists only of changing the screen ram. No changes are made to the character set except between enemy waves when a new enemy template is pre-shifted into the character set. This happens in the background without disturbing the smoothness of the scrolling, hero movement or other enemy objects. A downside to this approach is that you will occasionally see blank areas when one object is drawn on top of another, but hopefully it doesn't detract too much from the game play. Thanks - ABBUC http://www.abbuc.de/ - STE'86 for permission to use Armalyte sprites - TMR for hero ship sprites - phaeron for Altirra and VirtualDub http://www.virtualdub.org/altirra.html - fox for xasm http://atariarea.krap.pl/x-asm/ - fox for inflate http://atariarea.krap.pl/x-asm/inflate.html - jaskier for TMC2 http://jaskier.atari8.info/ - AtariAge Forums http://www.atariage.com/forums/forum/12-atari-8-bit-computers/ - Format War http://formatwar.net/ - AtariOnline.pl http://atarionline.pl/ - Tiled Qt http://www.mapeditor.org/ - ImageMagick http://www.imagemagick.org/script/index.php - BitBucket http://bitbucket.org/ Acknowledgements - Armalyte ZX Spectrum - Gradius Game Boy - Nemesis Game Boy - Ruff'N'Tumble Amiga Greets 505, +Adam+, atari8warez, candle, CharlieChaplin, CreatureXL, Cosine, drac030, emkay, Exin, Faicuai, flashjazzcat, foft, fox, Heaven/TQA, Hiassoft, ilmenit, Irgendwer, ivop, JAC!, Johny, Kaz, MaPa, Matosimi, Mclaneinc, miker, MrFish, Oswald, PG, phaeron, popmilo, Rybags, sack-c0s, SimPiko, skr, snicklin, STE'86, Stephen, stRing, Synthpopalooza, tebe, Tezz, therealbountybob, TMR, w1k, xeen, xxl Future Plans We planned many more features but ran out of time. - Enemy waves that come from the borders - Enemy ships that shoot projectiles - More enemy movement patterns - Destructible border weapons - Better ship weapons - Large end bosses Stay tuned for another release with these features and more after the contest period.
  43. 7 points
  44. 7 points
    We've finalized the CDF spec, which has seen a major overhaul, and I've finished updating Stella to support it. As such I've resumed work on Draconian. Currently the title screen & menu are back in place. All the routines have been rewritten due to the spec change. I also revised them for digital sample support, which requires 5 cycles of time on every scanline (though at the moment that's just a SLEEP 5, it'll be replaced with LDA #AMPLITUDE/STA AUDV0 when I'm ready for the samples). As before the Start option is currently used to display console (2600/7800) and timer value (used for NTSC/PAL/SECAM detection). If you start the game you'll get the typical Atari rainbow screen. Hit SELECT to go back to the menu. At the moment the ROM will only work on a Harmony Cart, and only on 2600s. There's a 7800 timing issue in the driver that Chris is still working on. Additionally, due to the change in the CDF spec, you'll need at least Stella-5.0.0-pre7 which which is scheduled to be released later this week. Do note that starting with pre7 Stella will not be able to run the earlier Draconian CDF builds as the spec change is not backwards compatible. draconian_20170502.bin
  45. 7 points
    I got the chance to see Rogue One: A Star Wars Story on Thursday night (okay - technically Friday morning) thanks to a friend of mine who invited me to a screening at Disney Feature Animation. Nothing like seeing a Star Wars movie in a room full of nerds. I'll try to keep this brief, because it's 3 AM and I'm really, really tired. Oh, and so it doesn't get all wordy and boring. That too. I'd been looking forward to Rogue One (and avoiding spoilers) because the trailers looked really cool, and the characters, as brief as they're featured in the trailers, already seemed interesting and different. Plus, not being an "episode" it would give Star Wars to stretch out into different storytelling territory. I felt that The Clone Wars and Rebels animated series did (and do) that really well. But would it translate to the big screen? In short - yes. In fact it felt very much like Rebels, since Rogue One also takes place just prior to the original Star Wars (no... I'm not calling it Episode IV) and deals with the burgeoning Rebel Alliance. Hey... I think that's the first time I've used "burgeoning" in my blog. Cool. Oh right, brevity. Now, I should mention that I saw it in 3D. I don't really recommend it, because while the 3D in the film is generally pretty good, it took me about 20 minutes before my eyes were dialed into it and just accepted it as "normal". Your mileage may vary. But I don't think it adds anything to the film, and at times is actually a little distracting because you become aware they're intentionally sticking something in the foreground. But if you do see it in 3D, during the end credits, flip your 3D glasses upside-down. It inverts the depth-of-field, and puts the credits behind the stars. It's cool! Seriously! Probably shouldn't do it during the film though. So how was the movie itself? Well, I enjoyed it quite a bit. Was it "jump out of your seats, flailing your arms and cheering like a crazy person" awesome? Well, no. But it was really good. And a lot of fun to watch. Mostly. The lead characters are excellent, and a bit different than what we've come to expect from typical Star Wars good guys. They're noticeably a bit rougher around the edges, and clearly, they have to be. It's not a happy time in the galaxy. The lead actors - Felicity Jones as Jyn Erso and Diego Luna as Cassian Andor, do a great job of carrying the movie. They bring great depth and likability to their characters. Alan Tudyk as K-2SO does a great turn as a droid with a distinct and fun personality. Unlike C-3PO (especially Episode II) or those idiotic prequel Battle droids, he doesn't wear out his welcome as comedy relief. But the standouts for me were Donnie Yen as Chirrut Îmwe and Wen Jiang as Baze Malbus. They're supporting characters that nearly steal the film. They're terrific fun to watch together, and it'd be great to see them featured in their own dedicated story (probably coming soon from Marvel Comics). The Imperial characters don't fare quite so well, since they're just there to be bad guys, and that's basically all they do. And while it shouldn't come as a surprise, There are plenty of callbacks to the original Star Wars movie, which makes sense, but at times it gets to be a bit gratuitous. Without giving too much away, if you're familiar enough with the original movie, you won't have any problem recognizing certain... elements. In fact, I had trouble trying to ignore them after awhile. And speaking of callbacks, my single biggest gripes with the film are Apart from my aforementioned gripes, the majority of special effects throughout the film are excellent, with the exception of some of the CGI aliens, which look like CGI aliens, and might have been better served by practical effects. The action scenes are first-rate though. There are some terrific battles in this movie, and while the space battles are on a larger scale than the original Star Wars, they still looked like they could have been part of that era. There are a couple of weaknesses in the film that really jumped out at me, however. One of the lead characters, who starts off uninterested in the whole Rebellion, does one of the quickest character turns I've ever seen in a movie, and seemingly in the span of one sentence becomes the Rebels' biggest cheerleader. I kept thinking, "Wait... did I miss a scene?" Maybe seeing it again would make it clearer to me. The other is predictability. And it's a problem the movie simply can't avoid. It was designed into the film, because of when it takes place, and what must take place. If you know Star Wars, you know what they have to do. What keeps you interested is how they do it, but even that has a little bit of a problem in that it's a bit too reminiscent of other film tropes. Hey... I think that might be the first time I've used "tropes" in my blog, too. Funny, I would've thought I would've used that already because it's a good, you know... um... trope. And while there are some other parts of the movie that are also nitpickyable (pretty sure I've used that word before...), the cool moments and compelling characters far outweigh them. It's a different Star Wars story to be sure, but it's a good one. Perfect? Nope. Flawed? Somewhat. But better than the prequels, and I'd put it above Return of the Jedi, too (I've said it before - not a fan). It's about on par with The Force Awakens. Interesting new characters, a few too many callbacks, fun but flawed. But since it has the real Death Star in it, and not a shoddy J. J. Abrams copy, Rogue One: A Star Wars Story gets an 8.1/10. But see it in 2D. If God had intended us to see movies in 3D, we'd have been born with polarized eyeballs. And please use Spoiler tags where appropriate in the comments. Thanks!
  46. 7 points
    Here's a funny one: I just found this letter I had written to Imagic some 33 years ago. I was trying to give them an Idea for a game I had (unfortunately I don't have the picture or the instructions; I don't know what happened to them). I can't believe I wrote 'you can even steal it if you want - I won't tell any one' I do remember the gameplay rules... maybe it will make an appearance somewhere else Bob
  47. 7 points
    Well, if it works for Charlie Brown and the Grinch... I figured since Stay Frosty 2 and the AtariVox+ are now in the AtariAge store, this would be a good time to rerun this strip. All I'm missing are the commercials for Dolly Madison. And in case you're wondering, yes - Artie has been modded so he can run Stay Frosty 2. Merry Christmas! rerun < PreviousIndexNext >
  48. 7 points
    Auto-detection of joystick or gamepad. The flicker-free two-color 48 pixel kernel, which I think was first publicly seen in a May 2011 build of Frantic, was originally developed in 2010 for the Stay Frosty 2 logo at the top of this screen. Broom = Double Jump, Present = Bonus Points. Levels use full width of screen. In contrast, Stay Frosty didn't use PF0 so the upper platforms never appeared on the left or right edges of the screen. Platform color is also updated on all 3 scan lines, Stay Frosty platforms look flat by comparison. Watchout for Firebirds, they're hot. Status line alternates between Score and Lives/Level. The firebirds look awesome in motion (@ 0:33). Elevators can take you places. Branches can move Walls Carrot = Snowball, note the Carrot Nose when powerup has been collected. Throwing a snowball is done by hitting UP on a standard joystick, or a secondary button if a gamepad was detected. Gamepads that are known to work include Amiga CD32 Joypads and Sega Genesis Gamepads (both 3 and 6 button). Taking a piece of Coal from the Bucket lets you see the invisible. But beware, fireballs love coal - they'll take it from you and become stronger. First image is after the bottom-right fireball took a piece of coal from you, second image is after it took another piece from you. Lava Platforms are also hot, Snowflakes restore ice. Corn Cob Pipe = Icy Snowman (slower melting). Lava platforms shimmer over time. Gas Cans are not your friend, they reignite extinguished fireballs.
  49. 7 points
    Wow - I feel honored (and I mean that sincerely). Howard Scott Warshaw just 'endorsed' me on LinkedIn for 'Game Development'. I don't know if that really means anything with regards to LinkedIn, but just the fact that he - someone who wrote 'Raiders Of The Lost Ark', 'Yars Revenge', and 'E.T.' for the 2600 - did that is very cool to me. That actually makes me feel a little better about myself (at least for the moment).
  50. 7 points
    Ah the Jaguar community. Without a doubt, the most hostile of all the gaming communities... this is my personal story of the Jaguar community. I hope you enjoy reading it as much as I enjoyed writing it. I've been a member of AA since 2005, and for 6 years managed to weave and dodge my way around all of the foolish nonsense. From double accounts, to heated discussions regarding roms, a blind loyalty to the system and it's games, and the constant bickering and antagonizing of members that don't fall in line with the "norm." At times it has been downright toxic. Two forums emerged from the 2 "factions" of the divide, one being FreeJag and the other being private. Neither has picked up any steam. Leaving AA the premier place for Jaguar enthusiasts, which seems appropriate. But I'm getting ahead of myself. Since I had the internet, approximately 1998, I've loved the free flow of information and the sharing of knowledge. One of my earliest obsessions was with the Sonic community, and I was huge into that scene around the time the Sonic 2 Beta was released. There was so much information being shared and discovered. And the rom was released to the public! Instead of an elite few controlling the flow of information, it was available for the whole world. From there, FAQs, hex charts, and documentation was shared and more great things happened. With Hex editing alone (meaning no source code) awesome hacks of the Genesis Sonic games were released. Beta levels were restored, beautiful palette swaps were released, and previously undiscovered badnicks were restored. Sonic Mega Mix, which is a terrific hack of Sonic CD, is freely available for you to burn to a CD and fire up on your Sega CD. Nothing is required to play this gem. You don't need to be a member. You don't need to donate money. The community is still thriving, and Sonic Retro is a HUGE forum, and even has an official relationship with Sega. You read that right, a rom hosting, sonic hacking, IP violating, group of people have an official relationship with Sega. This is just the tip of the iceberg, there are hundreds of examples of bending, and sometimes breaking, rules/laws resulting in wonderful things. A more recent example was a very dedicated chap who disassembled the original Super Mario Bros. (NES), reworked the code into a fully documented source code. I can't even fathom the amount of time and energy that went into this project. And it was released free to the community. And you want to know what happened when some gave away there hard work asking nothing in return? Someone took the source, and ported it to the Sega Genesis. And you know what he did? Released it to the world, free of charge, free of obligation. And from there, people started helping with the project, donating source code and other files to help make the Genesis Mario even better, and more accurate. This is what happens when people share their work. Wonderful things happen. But for some reason, these types of things quite simple don't happen in the Jaguar scene. Perhaps it's because the Jaguar is not terribly popular, and does not attract enough people to warrant the time and energy it takes to do such great things. But my gut tells me it's something else. Avoiding the drama that was the summer of 2009, and to keep with this blog's terms of use (specifically, not naming anyone) let's just say there was a shake up. A perfect storm of sorts was brewing. And when the dust settled, there were casualties. Member of the Jaguar community started rejected the "norm" and Jag fans started wanting a piece of that community pie. People wanted to download roms without being shunned. People wanted to talk about emulation. People wanted to hack, crack, explore, share, the games they've loved for years. But during this renaissance, there was resistance. The ugly term "piracy" reared it's ugly head. Now I must take a brief break from story for a disclaimer. This story and my thoughts are not meant to offend, anyone. If you are offended I offer you my sincerest apologies. If you think any of my comments are directed at you personally, they are not. And now to continue our broadcast. The term piracy reared it's ugly head. Yes, downloading roms of commercial games is illegal (unless the developer released it's rights... and speaking of that, check out the Amiga CD32 community, awesome). There is no doubt about it. But what does that really mean? I am not a lawyer. This is not legal advice. Generally speaking, developers and publishers do not want their intellectual property released for free to the public. Piracy is a real problem, and does negatively affect companies. But this very website is host to thousands of commercial roms. The owner of this website has not been sued. Draw your own conclusions. This leads me to my first problem with the Jaguar community. If you visit other game forums and mention how you played Darxide (rare 32x title) via an emulator, no one is going to berate you, no one is going to call you a pirate, no one is going to threaten litigation. In the summer of 2009, you couldn't mention you downloaded Rayman and played it on a Jaguar emulator. A vocal minority of the Jaguar community wouldn't allow such talk. This leads me to a personal lesson. Live and let live. Not everyone agrees with you. You won't agree with everyone. Chances are very high that nothing you say will change the other persons mind. The point of debate is not to "convert" the other person. It's not even about persuading the other person to believe what you are saying. The point of debate is to understand the other side. Not agree with the other side. Live and let live. It takes all kinds of people to make the world go round. And yes, that means I empathize (but not sympathize) with those that disagree. So here we are today. Coming up on the 2 year anniversary of the Jaguar's renaissance. Things are moving slowly, but I believe the community is slowly moving towards a new era of sharing and discovery. We've seen a few interesting hacks, including extracting Art and Voice files from the bubsy rom, and some work disassembling the code. Perhaps someday we'll have Bubsy hacks with tweaked controls, new sprites, and other things I can't even imagine. We've also seen some hex editing (very crude hacking) of Checkered Flag to start to tweak it's horrid controls. Who knows, if enough people show interest, share there findings, maybe someday Checkered Flag could be playable, maybe even fun! A Call To action If you've made it this far, perhaps you are wondering what the point of all of this is. Up until this point, I've been bobbing and weaving my way through the Jaguar Community, only stepping out of line once and a while to voice my opinion. But some recent experiences have made me want to step out of the shadows. It's something that I, and many others, should have done a long time ago. It's time for the Jaguar community to be a community. You don't even have to do anything if you don't want to! 1. Be civil, not everyone agrees with you, and you can't change there mind. That is ok! 2. Support emulation. Piracy and emulation are NOT the same thing. Emulation makes programming and debugging easier. Emulation can give you a way to play freely released games without dedicated hardware. You can support emulation by supporting those who are writing emulators. Get involved, test them, offer feedback, offer support. 3. SHARE I can't express this enough. Share your findings and your discoveries. The more you share, the more others will share. The more they share, the more you get. Some people will object to sharing for "legal" or "moral" concerns. And that's fine, everyone is entitled to there own opinion. Dig through roms and find sprites that were never used in game. Take those sprites and make animated gifs and share them with the world. Find hex edits to give games unlimited lives. Find sound clips. Document and share. If whatever you are doing violates forum rules, then start your own website! Blogger and Wordpress (among others) make for great ways to document and share. As I said at the beginning of this blog, there are 2 factions of Jaguar fans. Those who like the status quo, who refuse to allow any new ideas, and stand on what they perceive as the moral high ground with a firm stance against any sort of "hacking." The other side wants to see the Jaguar flourish in it's after life, like most classic gaming systems. Which side should you be on? Neither. There is room for everyone. If you strictly want to play commercial games on your actual system, and nothing else. That is fine! I support you! There is room in the community for you. I will not try to change your mind. And you should not try to change mine. If you want to see emulation, rom hacking, sprite ripping, and game modifying, there is room for you to! All we have to do is respect each other, from the people on the extreme ends, to the the quiet majority in the middle. So please, end the hostility. Who knows, maybe we'll see the Super Mario Bros. source ported to the Jaguar. Now wouldn't that be awesome? -Kris
×
×
  • Create New...