SmileyDude

I'll give that a try -- the 4-switch that I have has other issues, mostly mechanical, so I can just swap out the RIOT and the 6507 while I'm at it. At the very least, I know that those chips all worked well enough for the Harmony cart, so I shouldn't be making things worse

Sorry for the double reply, but I had a chance to try it out again and no go -- my heavy sixer just does not like the Harmony cart at all. I'll try to clean out the cart slot again just to see if that might be causing a problem, but pretty much every other Atari cart that I have works in this thing. Maybe I should just see if I can get another working 2600 instead...

NTSC/PAL/Sears/Special: NTSC Sears Serial #:70623U MFG Location: Sunnyvale SmileyDude, Wilmington, MA A/B Channel Slot (Yes/No): No A/B Channel Switch (Yes/No): No Functional (Yes/No): Yes Notes (Previous owner, display only, white sticker, parts fixed, green connector, Switchboard/Motherboard Revision #): Was given to me from my dad who got it from someone who cleaned out an apartment in the Cincinnati area. Had to replace the power connector with one from a broken 4-switch Vader, also swapped the TIA chip but that appeared not to be necessary afterwards. Has the "Do Not Attempt Game Repair" sticker on it, no manufacturing date on visible on either sticker. Refurbished (Silver Label) (Yes/No): No

I was just able to update the firmware on the cart, so I plan to give it a try later this week. Hopefully it will start working on my heavy sixer and I'll forget all about the problems I had

Yes, that was what the issue ended up being. That driver is an absolute must have, even if the OS appears to detect it just fine -- I even had a tty entry in /dev without the driver, but it still wouldn't work. Installing the driver fixed everything.

Interestingly enough, I just made a ROM image that uses all 512K the new cart would allow. I guess I'll be buying one of the new carts once they are available. Are there any other changes in the Harmony Encore besides increased RAM/ROM/EEPROM limits? Is the ARM chip still clocked at the same rate?

I didn't think of swapping the CPU as well. I'll give that a shot next.

I saw the other topic where some of the carts won't physically fit, but I don't think that's the case for me. It appears to go all the way in, but it behaves as if the cart isn't actually there. Are there any issues with a heavy sixer and the Harmony cart that aren't caused by physical mechanisms? Could there be something else broken on the sixer? One thought I had was that the Harmony cart would draw more power than a typical cart and if there were any issues with the power components on the 2600 that could be the cause. But at this point, I really don't know what the problem might be. I know the cart actually works because I was able to use it in a 4-switch vader, but I had to switch to the heavy sixer because the other machine is missing a difficulty switch (one of the previous owners was a little rough with it) and the joystick ports didn't appear to work consistently. I don't know what firmware the Harmony cart is running, since I can't run the tool on either of my machines currently (see other thread). But if that's a potential solution, I'll try to get it working on another machine.

I'm running into a bug in Ms. Pac-Man where I can get stuck inside the wall (see pic). I'm pretty sure I haven't seen that before, but it's pretty much 100% reproducible on my system and cart. Has anyone ever seen this before? I thought it might be a problem with the TIA chip in my 2600, so I swapped it out, but the problem remained. This is on a real cart and system, so not a bad dump, Harmony cart issue or emulator problem. I don't have another copy around to test and my Harmony cart isn't working on this system either. Other games seem to work fine, though. So I'm inclined to think it's an issue with the cart. But it just seems weird that the game would seem to work otherwise.

I just tried using the Harmony Programming Tool on my cart with OS X Mavericks and it tells me that the Harmony Cart is not found. But if I look in System Information under USB, I can see the cart just fine. Does the tool work with Mavericks or will I have to hunt down another machine to run the update on? Thanks!

I know it's more authentic to how the machines of the day presented them, but yuck - I rather not have uppercase mnemonics these days

For my 2600 hacking, it's vim, dasm, make and Stella. Not because I want it to be retro, necessarily - it's just that those happen to be a combination of tools that work well for me. Sometimes I'll use TextMate as my editor instead, but that means having to switch apps rather than remaining in Terminal for everything. I'll usually keep my iPad handy as well for reference material, but my web browser is usually open to something as well. If I really wanted to be retro in my tools, I would probably try using an Apple II or some other 8-bit machine as my development machine and a real 2600 as my test machine. But I'm rather fond of having a debugger and a short build-deploy-run cycle

I think that perl script is just doing decimation of the 8-bit samples down to 4-bit. That introduces quantization error, which may or may not be a huge deal on the 2600 -- I still need to try some other things first before I say that's my problem. The 1-bit beeper stuff is pretty amazing, IMO. I still listen the the Chronos title music from the ZX Spectrum every once in a while. I would love to get something like that working on the 2600 or even the Apple II, which has just a 1-bit beeper as well. Amazingly good and even more impressive that it was done without the help of all the tools we have access to these days like high end PCs and instant access to knowledge via the Internet.

Good call on the low pass filter -- that's probably where a good chunk of my noise is coming from. I'll give that a try to see how it effects the sound. As for ADPCM -- would that help in the case of the 2600? You only have 4-bits to work with on the output side. You would have to squeeze it down to 2-bits to really make it worthwhile, but you would be sacrificing a huge chunk of your dynamic range (which is already a fraction of what a CD has). I was also thinking of doing some sort of compression as well. Was going to experiment with trying to RLE the samples to see if that saved any space. With the Harmony cart, I bet you could pull off some nice audio. The ARM in the Harmony could just feed samples to the 2600 in a tight loop without having to worry about any unpacking, loop overhead or bank switching on the 6502 side. I might have to play with that at some point as well.

I've been playing a little bit with PCM audio (AUDCx = 0 and changing AUDVx quickly to produce sound). I was able to get some decent results fairly quickly, but I think my naive 8-to-4-bit (s >> 4) quantization method is introducing too much noise into the conversion. I've done some looking into ways to clean up the audio, including dithering and FIR, but the results just aren't sounding that much better than the naive method. I'm currently using 15720Hz as my sampling rate -- just using WSYNC right before filling in AUDVx. I could try to tighten up the code a bit and increase the rate, but I really don't want to spend *all* the CPU time handling audio. At least I should have enough time with my current method to put something on the display, even if it isn't very advanced. Has anyone else here tackled the quantization error issue?

Perhaps I misunderstood what you are doing here -- I thought this was a value that the 6507 code was possibly changing and you were reading it from the ARM side, which is exactly the sort of thing you need volatile for. Are you sure you're not just getting lucky with the optimizer? Perhaps the loads are happening too infrequently for it to end up in a register long term and thats why you can leave it out without a problem. If this is something you read once per frame (haven't looked at the actual code in this case), you can probably get away with not having the volatile keyword.

Re: volatile That is a weird behavior, I wouldn't have expected that adding the volatile keyword would've increased ROM size like that, especially since removing it didn't appear to have any effect. I wonder if this is just an issue with your particular compiler? It would be interesting to know what is going on here, since your original usage of volatile was appropriate (reading memory that could be changed outside of your code).

Any chance of a bin file at some point (I assume after you sell all the carts you plan to make first) for us Harmony cart owners? This looks fantastic - it has me wanting to take a crack at making something with DPC+ ... Just need to make some time

"I had a situation after one OS X upgrade where Parallels wasn't happy - and Parallels is critical for Stay Frosty 2 as I use a Linux VM for the ARM compiler that's used for Harmony/Melody development." Yikes -- that would drive me nuts. Surely there has to be an ARM compiler that would work for Harmony/Melody that runs under OS X, right? If I ever get a chance to do some more 2600 hacking, I'll probably see what can be done about that. I can't stand having to flip between OSes, especially for something that should be able to work.

Count me in - I love the community here at AA and despite Atari being in the name, I think of it as a great place to go for discussion about any classic gaming/computing topics. Would love to see more things like this as well.

The Apple II is really just a 6502 with just enough logic in place to get something to the display. The later 8-bits (C64 and Atari) were all about their custom hardware and the 6502 is just the conductor. Two very different approaches, but both nice in their own ways. I will say this, to get good results out of the Apple, you really have to be good with 6502 assembly. It's also a simpler system to understand completely. The Atari and C64 are tougher to get started with, but have way more potential on the higher end. Personally, I like the challenge of the Apple II - figuring out how to get the II to do something is really cool because its almost purely a figure out the best way to do something with just the CPU. But if I was trying to make a game rather than a demo, I would probably stick with the Atari or C64 - you spend less time trying to figure out tricks in software and more time making a game.

I've got some code around that will generate a WAV file that can be used to load in to a II/II+/IIe via the tape interface. I've actually loaded code from my iPad to my IIe this way. There is also a website around that has a bunch of games for the II in tape format.

I thought that at first, but the mouse text is in the first half of the ROM already at entries 64-95 (starting from 0). Also, this ROM has an early version of mouse text, because the running man characters are still in it (#70 & 71) -- these were removed in later versions for more "practical" images instead.

I was extracting out the font bitmap for the Apple IIe from the video ROM chip (342-0265-A) and while the first half of the chip is what I expected, the second half of the chip is completely puzzling me. It looks like it could be bitmap data, but I can't for the life of me make out anything meaningful out of it. Does anyone know what was stored in the 2nd half of the video ROM on the IIe? Is it actually bitmap data? Or is it just filler data because it was easier to get a 4k ROM than a 2k ROM?

Allan -- Thanks a bunch for this, it's fantastic and exactly what I was looking for.