SmileyDude

I picked this up over the weekend as well -- my 15 y/o son actually found it first and showed it to me. He's actually been playing a few of the games in between the more modern games he also plays on his iPad. And I'm just happy that I can play Pitfall and Pitfall II anywhere I happen to be -- my GBA has been retired to the game shelf for a while now, so this is a much appreciated app. As for older devices, it's not as much the capability of the device as it is Apple's support for the device. iOS has been progressing at a very fast rate over the past 5 years and it is much easier to support the most recent iOS versions rather than trying to go back and support them all. Apple has made things a lot easier for developers in later versions. And with those improvements, developers can spend more time on the things that matter more in the app rather than replicating functionality that Apple provides on earlier versions of the OS. EDIT -- wanted to also point out that it appears that the TV screen with the game preview is actually running the emulator. If you watch closely, you'll see that the screen image transitions to full screen when you start a game. Very cool, IMO. Also shows just how powerful these devices are -- it's emulating a 2600 while also running a 3D UI as well. I still remember machines that couldn't emulate the 2600 at full speed back in the day...

The indentation is off because it looks ilke there is a mix of hard and soft tabs in the file. It looks like Ed has set his tabs to 8, so if you set your editor's tabs to 8, it should look better. Ed -- thanks for posting this. I hadn't paid much attention due to the fact that I'm admittedly not a big fan of Halo, but my kids are. So I'm going to share this with them in hope of getting them more interested in the older gaming machines like the 2600. Also, I was really impressed that you did this in 4k -- I had assumed that you used bankswitching initially. Great work!

I'm looking for a good recommendation for a monitor or TV that would work well with classic 8-bit systems, including the 2600, 800XL and Apple IIe. I currently have a working IIe setup with an Apple color monitor, but it doesn't really have the best image quality (partially due to the composite out on the IIe). I'm planning to mod my 2600 to get better video - most likely the s-video mod - so, really looking for something that will take s-video and composite ideally. VGA could also be useful. Also, since I'm in the US, NTSC compatibility is a must, but having PAL as well would be nice. I don't care about speakers - I can get audio separately. I really don't want an LCD for this, unless someone has one that works really well. My experience with LCDs and composite sources hasn't been great. Too blocky looking without that nice natural blending that a CRT provides. So, does anyone have any good suggestions?

Tossing in my thanks as well. I ordered it on Friday and it showed up today (Monday). And that was with a huge snowstorm over the weekend. Very nice! My order from Amazon placed at the same time isn't due to get here for another couple of days. As for the cart itself, I finally got to run my own 2600 code on a real Atari for the first time tonight. And that made it totally worth it for me. Can't wait to dig in deeper with this cart and see what I can do. Thanks again!

Batari -- what are you shooting for on the H2 release date? Not looking to hold you to anything, just curious. Will it be backwards compatible with the original Harmony? Or would it be better to have both of them around? I'm mainly interested in it for development purposes, not for playing old games, if that makes a difference. Thanks!

I picked up the cart a few weeks ago just because I didn't have it and I had wanted it as a kid. Unfortunately, it came without the keyboard controllers or overlays, so I'm still on the lookout for those as well. I do however have the controllers that came with Star Raiders around. So I might be able to give this cart a try out anyway. Does anyone know what a fair price for a complete Basic Programming cart with controllers and overlays goes for these days?

I'm pretty sure I have a bunch of Nibble and InCider magazines around still. The Nibble magazines go pretty close to the end of their run, as I recall. I would be willing to give them to someone for the price of shipping them and a copy of all of the scans. I don't currently have a scanner, and if I did, I wouldn't have the time to sit and scan all of them. If anyone is interested in getting these, contact me via a PM. Serious offers only -- I don't want to send them off and then never hear back again.

That is completely normal behavior for an Apple II with a disk controller card and no disk in the drive. Pressing Control-Reset will get you to a prompt. If you put a bootable disk in the drive, it should boot off it.

Hi Andrew -- Thanks for replying -- and sorry about the "s". I realized it too late to edit the post. I would definitely like to know more about the showstopper bugs that you (and anyone else for that matter) are encountering. My own simplistic use of macros hasn't triggered anything bad yet, but that really doesn't mean much. I've seen other people refer to the macros as broken as well, so there must be something to it. I did go ahead and put up a github repo if anyone is interested. It's at https://github.com/munsie/dasm . Feel free to use it. It's based on the last version of Peter's that I could find. I managed to fix the problem with the 64-bit Intel build on OS X as well and made dasm play a little nicer with Makefiles under Unix. I don't want to say that I'm up to the task of maintaining dasm, but I'm certainly willing to give it some attention here and there. I will definitely take a look at any pull requests that I get, and as long as they don't generally make things worse, merge them into my repo.

I managed to get this working. The key was making sure my index registers were loaded at the end of each line, but doing the actual load/stores in order from the start of the line. So I'm basically setting PF0, PF1 and PF2 just before they will be read by the TIA. Now my play field tables are 5 bytes each times 6 tables, which means I'm only spending 30 bytes to store my graphics instead of the original method I had which used around 240 or so.

As someone who has done both 6502 and ARM assembly, if you can write code for the 2600, you can definitely understand the ARM. It's a very orthogonal instruction set and very easy to get into, very much like the 6502. That shouldn't be too surprising since the ARM's origins are from the old Acorn days where they wanted a RISC CPU to replace the 6502 that they were using at the time. My own recommendations to get around your problems would be as follows. Make sure you are using THUMB code if space is a concern, run out of RAM as much as possible, and try to use 32-bit load/stores if you are writing C code. For assembly, you can use the 8-bit and 16-bit load/stores directly. Theoretically gcc should be able to use the correct versions, but I found that gcc doesn't generate the best ARM code. If you want to stick with C, you might want to try another ARM compiler -- since you are on a Mac, you might have luck with Clang. Apple has spent a lot of time getting Clang to generate optimal ARM code, so it could be worth a look. Once I get a Harmony cart, I'll probably take a look at going down that route myself.

Been mulling this one over -- I've decided to go in as well on this. Sounds like fun.

I took at look at a disassembly of the 7800 BIOS, and it looks like the interrupt mode is disabled at the start and is never re-enabled by the BIOS ever. http://atarihq.com/danb/files/7800bios.asm The only source of interrupts on the 7800 is the IRQ on the cartridge port, so for a pure 2600 game, skipping SEI shouldn't cause a problem on any system that Atari shipped. But as said above, it's a cheap form of insurance and who knows if someone will make a new version of the 2600/7800 that does use interrupts in some interesting way.

So, I'm attempting to put together a kernel that changes PF0, PF1 and PF2 twice per line, along with setting COLUBK and COLUPF at the beginning of the line. To get a stable display, I had to move the initial setting of PF0 and PF1 to the end of the line, but that means those two fields start one line lower than the others. My source data for those registers aren't line based, but instead line mod 8 so that I can keep the blocky look I was going for. Does anyone have any examples of something like this being done that doesn't waste a bunch of ROM space doing so? Right now, I'm basically keeping my current line index in X (because my colors are changed on a per-line basis, unlike the play field) and then dividing that down by 8 and stuffing it into Y to use as an index into my PF tables. I just don't have the time necessary to adjust Y as needed for the PF0 and PF1 update. I'm okay with using illegal opcodes, but there wasn't any that I saw that immediately struck me as being useful. I think for now I can just go back to my old method of updating PF0 and PF1 where I had a table that had an entry for each line, but that means that I'm going to be wasting 64 bytes. Much better than before when I was wasting 6 * 32 bytes, but hoping to improve it. Thanks!

I came to the same conclusion about the SEI instruction, but then I came across this comment in macro.h: ;------------------------------------------------------------------------------- ; CLEAN_START ; Original author: Andrew Davie ; Standardised start-up code, clears stack, all TIA registers and RAM to 0 ; Sets stack pointer to $FF, and all registers to 0 ; Sets decimal mode off, sets interrupt flag (kind of un-necessary) ; Use as very first section of code on boot (ie: at reset) ; Code written to minimise total ROM usage - uses weird 6502 knowledge Does anyone know what Andrew meant by "kind of un-necessary"? I just assumed that it was always un-necessary on the 6507 since both interrupts lines are tied to ground and therefore, it's impossible for an interrupt to go off. Unless there is some weird edge condition that I wasn't aware of that could cause an interrupt.

No responses here -- does that mean there isn't much interest or that this is wrong place or something else all together? Thinking about it on my end, I'm going to go ahead and setup a github repo for the stuff I do with dasm. I'd much prefer that at least those changes should be available for others to benefit from. And github is easy to work with. If someone wants to be the owner of the "authoritative" repo on github, I'm fine with that -- we can just work out the details when we get to that point later. Since the code is under the GPL, anyone is free to take the changes I make anyway, so it's not a big deal. I'll post up a link once I have it setup with some of my changes in place.

Has there been any thought into putting dasm up on github instead of sourceforge? I have a couple of things I was thinking of doing with dasm (fix 64-bit Intel OS X builds, Apple II header files, enhanced ERR pseudo-op) and having worked with github before, I thought it might be a nice home for it. It might spur some experimentation with it. Is Andrew Davies still the maintainer for dasm these days? If not, who is?

This sounds like the best option. Looks like I will be ordering a Harmony card soon. Thanks everyone!

Hi everyone -- I've been toying with writing another 2600 demo again lately (wrote a copper bars demo waaay back in 2003 -- see this post for more details), but I really want to see it on real HW while in development this time. I know there is the Harmony cart, but my initial look over at the specs gives me the impression that it's great for when you have something final that you want to load onto an SD card, but it might be a bit tedious to use in the midst of the code/assemble/run cycle. Ideally, I would like to have something that I could have connected up to the 2600 and my computer at the same time (MacOS X machine) and that I could upload a new version of my code from the command line. Does the Harmony support that option? If not, is there something else that could be used? I'm not planning to go over the 4K size, so even something that only supports 4K and smaller ROMs would work for me.

J2ME seems completely unlikely, since it would require an entirely new codebase. Symbian (and when you say Symbian, I assume you really mean S60) could happen, but only if you find someone who really loves S60 and Atari 2600. Otherwise, the pain of developing on that platform just isn't worth it. Interestingly enough, the core of the app could be ported to Android with a new front end to handle the GUI side in Java. That might be the more likely scenario going forward. And while technically possible, I wouldn't expect to see Stella show up on the App Store for the iPhone or iPad anytime soon given Apple's current policies regarding emulators (you can't provide a generic emulator and allow the user to download their own ROMS -- everything has to be bundled up within the app or downloaded through in-app purchases).

If you can't find a Max Media Dock (and maybe even if you can), I would recommend getting an R4 instead at this time. I personally think it's a cleaner solution (1 slot-1 device with a MicroSD slot instead of a slot-1 device and slot-2 device that extends out of the DS). You can pick one up at http://www.electrobee.com/ -- there are other places to buy, but this happens to be the site of one of the developers that is responsible for getting DS homebrew to where it is -- natrium42. So, you're directly supporting at least part of the homebrew scene by buying from him instead of elsewhere. As for the MMD, I happened to be at Wal-Mart the other day, and they had a few of them out. So, I'm pretty sure that Wal-Mart hasn't stopped selling them -- they are probably just out of stock at that location. I've also seen the Games n' Music card at a Wal-Mart as well, which is similar to the R4 (microSD card, slot-1 device). If you want to purchase one of those 2, just check around at Wally Mart, Target, Circuit City, Best Buy, etc, etc. One of those is bound to have it.

The cart is additional RAM for use by the browser when it is running. It is like normal RAM, and it's contents disappear when you turn off the DS. Bookmarks are stored in the flash memory on the slot-1 DS cart. The browser is not upgradable -- what you get is what you get. Sorry.

Yes -- they work in both the Phat and Lite. Though, at this point, I would probably steer clear of Wal-Mart... It's better -- thanks to DLDI support, the MMD works just as good as anything else out there. The trick is that all homebrew doesn't support DLDI at this point, but that list is getting smaller all the time. With the latest DevKitPro, if you use the FAT lib, you automatically get DLDI support. Works great -- I've even used it in my ongoing port of Handy to the DS (dunno if I'll ever be able to release it, though -- I'll save that story for another time).

honestly, I would probably recommend going with something like the R4 instead for the DS. It's a slot-1 solution instead of a slot-1 and slot-2 solution like the MMD. I really dislike having to put two things in my DS to play around with the homebrew stuff. The R4 is nice and compact and would fit in the same container I put the rest of my DS games in. On the other hand, for development purposes, the MMD is more convenient because you don't have to remove the CF to connect it up to the computer -- simply use the USB port instead. But, you can't have the MMD plugged into the DS (even with it off) at the same time as you are trying to use the USB port. It just won't work. Annoying, but workable, I guess.

Part of the price tag is that they have to bundle a 10MB RAM cartridge with it as well. Luckily, you can just leave it in all the time, only swapping it out when you want to use the rumble pack or a GBA game. Without that extra cart, it probably would've been $20. EDIT: Sorry, 10MB not 32MB.