wallaby

I'm only a novice with electronics, but I've made my own simple cartridge recently. I've also learned a lot from ZackAttack. It's too bad this cartridge design didn't pan out. Although the Harmony is a proven design, I wouldn't want to clone it. It has some unusual limitations and I think a little bit of extra thought could bypass them. If you're looking for a standalone version of the Harmony - there is the Melody board. If you read their product page on it, it sounds like the perfect fit. Until you either A: try to get someone to make some or B: factor in the cost of the board. It is not a developer-friendly solution.

The problem is only a few people can make a Harmony cartridge and I don't think the design is open source. I'd rather have other options even if they're re-inventing the wheel. At least you're not subject to a single person or small group of peoples' whim.

Regarding bus stuffing: Is it still considered bus stuffing if your FPGA or CPLD or whatever outputs to the data bus? For example, you have the VCS -> ROM. However, what if I wanted to intercept the ROM access and output a NOP (or whatever) instead from the FPGA? So instead of accessing the ROM for the instruction, the FPGA handles it? That's just a normal operation as far as the VCS is concerned? The idea is that the VCS accesses the ROM like normal for most of its operation, but the FPGA takes over for some of that time. I'd like to avoid bus stuffing because of the difficulty ZackAttack mentioned above.

Yes, I was baffled. But it works rock solid with no ground connection on the EEPROM. As soon as I make that one connection, everything goes south. I wiggled the wires and pulled them out. That's how I found the ground disconnection actually fixed it. Nothing else has any effect at all. The wires are stranded though. I wonder if the problem stems from that. I'll recreate the interface with single core wires and see how it goes. Thanks again!

I think I sorted the stability problem. I had the GND connection from the cartridge connected to the GND on the EEPROM. Now the EEPROM GND isn't connected to anything but everything works?

So I could have 12 + 8: 20 bits for logic? How does the PLA know which direction the data is coming from? (Sorry, these are obviously very newb questions.) I imagine it works like this: [Atari] -> [PLA pass-through except inverting A12] -> [EEPROM] -> [PLA logic] -> [sRAM possibly] -> [Atari] Do I need to worry about the PLA CE or does it turn on at the same time as the EEPROM? I'm also confused about timing and bus contention. Trying to learn by doing.

I've managed to get a custom cartridge working and now I'm interested in how to utilize more ROM and RAM. I'm not clear on how this is done, so I was hoping someone could correct any misconceptions. Bank-switching: For more ROM, you would bank switch more code into the Atari's 4k window. You can do this by using a custom logic chip (CPLA?) to monitor the address bus and when the program triggers the right pattern, the CPLA knows to change the bank to whatever logic you have set that bank to. For example, 10101010101 could mean switch to bank 2? Prior to this, you'd store the program counter in RAM so you know where to return to? RAM: For reading and writing RAM, could you use the same CPLA to monitor the custom logic on the address bus? You would need commands for writing and reading RAM and you'd have to store the RAM address in the Atari's internal memory before calling the 'function'. So, you could store two bytes in the Atari RAM for your custom address and depending whether it is a read or a write, another byte for the data to store? Is it worse than that or am I over complicating it?

Ah yes. It was incorrect because there were some connections on the PCB. I had to make a jumper wire and a few changes. About every 20 or 30 tries the game will show. But a strong breeze can disrupt it. I'm guessing this is because I made all the connections on a breadboard. Or would a capacitor between power and ground improve the stability?

This is where I'm confused. The Skiing PCB has A9 and A11 connected to +5v. My Atari Defender PCB has A11 connected to +5v. But don't you need those address lines to access the full ROM? If you only have 11 address bits that only allows 2,048 bytes (in the case of Defender). And Skiing is even worse at 1,024. I'm misunderstanding something fundamental. I have grounded A12 on the EEPROM. Is the address bus active low? I might be redirecting the address to $1000 but only have FF at that location. When I programmed the ROM, I just programmed it from the start. Should I put the ROM at $1000 on the EEPROM?

Ahhh. Is the address space set when I program it? I'm using a hex inverter to invert the A12 line and pretty sure everything else is wired correctly.

I read A12 is used for chip-enable. I just wired my chip-enable directly to ground. Does it get switched on and off continuously? I could put a not-gate on A12 and wire it to my CE line.

Hey everyone. I'm trying to make my own custom cartridge but I've run into some problems. Here are the steps I took: 1. Got a donor cartridge PCB (Skiing by Activision). This is a 2k game but the layout looked straight forward. 2. I got an Atmel 8-bit 5-volt 64k EEPROM. 3. I desoldered the skiing EPROM and soldered pin headers in instead. (since the Atmel EEPROM doesn't actually fit because it has more pins.) 4. I programmed the EEPROM with the Skiing ROM. I checked the data in Stella and on the programmer and the bytes match. 5. I placed wires from the headers on the cartridge to the EEPROM on a breadboard. When I turn the Atari on, it usually makes random sounds and scrambled screens. It's almost like the Atari is getting random data every time it turns on. The sounds and screen data changes every time if anything is displayed at all. Checking with a logic probe, it looks like everything is high. The address pins and the data pins all register as high. I'm not sure what to do with the sGND and the A12 address bit. If I connect the sGND to the GND the Atari won't start. Do I just connect the A12 to the EEPROM's A12? Does the Atari use A12 or is it always on? Outside of wiring it wrong, is there anything that stands out? When I programmed the EEPROM, I left the remaining ~62k empty (FF) assuming the Atari can't address it anyway. Thanks!

Yes, Albert was very helpful. Love the idea of creating Genesis games. Interesting it has BASIC compilers too. I wonder why not C or C# syntax? They're more elegant (especially C#) and you could use a world class IDE like Visual Studio to write your game.

Are these stored as binary machine language commands? So when you compile your C program, you'll need to translate any outgoing register into a machine language counterpart? If I had say: myPlayerSpriteX++; myPlayerSpriteY++; When compiled, it would have to know how to move sprite0 one right and one down. Moving sprites depends on where the Atari is on the scanline. That would be difficult! Would it be easier to have a complete frame buffer where your C program changes the sprite locations, colors, and whatnot in memory, and then some other process that looks at the buffer and translates it to whatever scanline it is on. Or is that exactly how you described it?

Okay, so let me see if I have this right: The 6507 is instructed to STY $FF in an infinite loop. At the same time, C code is running on an ARM core that is updating registers in memory based on how you've programmed your game. The ARM is timed to copy the registers (bus stuff) to the data bus when it intercepts the STY command. It does this continually so the game never rolls or bounces. The 6507 stores the Y register depending on what data was on the bus. Updating TIA and playfield and sprite information. In this arrangement, the 6507 is really just a bus driver and the ARM does all the logic and memory manipulation. That's how you can program your game in C! The Harmony cartridge implementation differs in that it stores a compiled binary in flash. It watches the address lines and then fetches data from a flash location and outputs that on the data bus. Sort of like a normal cartridge but with the benefits of not having to program an EPROM. In this implementation, how do you get input information from the Atari RIOT? You can write data to the Atari, but how do you read joysticks and paddles?

That's a great point. I guess the thing that is bothering me is the promise on the Melody page isn't matching my expectations. I assumed I could just order what I needed and didn't consider how low volume could change that. This is a great helpful community and I've learned a lot. Stilllll... I'll finish this current project, but I'm fairly certain my next one won't use DPC+.

I wouldn't assume anything, of course. That doesn't change the fact that making a game where someone holds all the cards (in this case, limited PCBs) is a bad idea. I read all about the DPC+ features and all the options on the order page made it sound like this great thing that developers could really utilize. As time went on though, I started sensing a little indifference in some of the threads I was reading. That got me wondering if I should have just used a normal cartridge or designed my own. Now I'm wondering if DPC+ as a platform is mostly dead. As for carts, it's not about cost. The time span from the current day to when the Atari was released is only going to increase. Eventually, cannibalizing old carts is going to have an effect on their availability. Maybe I don't want a stock Atari cart? Maybe I don't want to mimic Atari's design? I'll release a demo. I'm sure it will have many bugs initially. It uses a lot of DPC+ features so if I decide to switch gears I'm going to have to re-evaluate what I can reasonably accomplish.

Seems like an opportunity for enterprising person. It might not have happened because the homebrew market isn't large enough. Or one person has the die and machine and everyone orders their carts from them. I wouldn't use Shapeways. Those cost alone isn't worth it. You could 3D print your mold. Get a cheap injection mold machine and go from there. I read 3D printed molds can last for 20 or more uses. That's good enough. Not sure how much pressure you need to fill a half shell of an Atari cart. That thin wall would probably be difficult. Messing around with that would be a lot of fun. Steel die are what keep that cost prohibitive. 3D print your mold, test it, if all is well, get the die made.

That's fair enough. I can understand that. If there is only one source for these PCBs then there is a danger that your game could go "out of print" without you being able to do anything about it. I wonder if it's a better idea to create a custom PCB? I remember seeing an ARM binary somewhere. I haven't opened my Harmony cartridge, but I imagine it's the processor, some ram, and flash to hold the ARM code. Another option would be to re-write the entire game without using Harmony/Melody features. But I spent a fair amount of time learning the system and there seems to have been a lot of effort in creating it. Would be a shame to ignore it. I think it depends on the type of 3D printer. The filament types leave lines and ridges on the plastic, but there are types that don't. I wonder how SLA stacks up, for example. You can also smooth out the ridges after printing the object. Also, there is the benefit of making your own completely new design for cartridges.

Thanks for that. I ended up caching my change sound requests and calling my routine once per drawscreen. That eliminated a lot of the space trouble I was having.

Wouldn't 13 signals allow the Atari to see 8k instead of 4? Is one of the lines on the address bus used for something else (the direction?) That's a nice abstraction I hadn't considered. In the slide you have at the bottom that you only drive 0s and that 1s are dangerous. Why is this? Is it because if you drive a 1 on a data line that is already a 1 you're doubling the voltage? Thanks for the excellent explanation!

I think the worry about the ROM having a bug is a universal fear. The manuals and boxes and things are no problem. Tons of places can sort you out there. Not sure about using cartridge donor shells for new games. Granted, there are a lot of Pac-man and Combat carts, it seems like there are better options in today's age of 3D printers and print on demand companies. I haven't looked into that as the Melody cart ordering says it offers the shell and labels as part of the package. What I'm worried about is the lead time and if it's actually counted in months (and possibly years) then all bets are off.

I'm fairly close to having a finished prototype for my DPC+ game and it slowly dawned on me that I've effectively locked myself in to the Harmony/Melody ecosystem. That wouldn't be a big deal, but there are no competitors and the cartridge is expensive. Okay fine, so it's more expensive than making your own cartridge. It still has some nice features. But what about the lead time and the shipping costs? Now I wonder if I might have made a mistake. I've read in a few threads on AtariAge, games that have been waiting years for a physical release. Why is this? Are they just waiting around to get published by Atari Age? Or have they never ordered cartridges? I don't want to wait around. I'm ready now. I figured it would be a good idea to know the total cost for a hundred or so cartridges but the "Contact" form never seems to complete properly. So anyone with experience: Why does it seem to take so long to get a physical release? And what have your experiences been with publishing your own cartridge / ordering through AtariAge?

How does bus stuffing work? I'm a novice at this but here is my very simplified understanding: Atari requests data at an address. The address is made up of 12 (11?) signals. These are single bits? On or off? The EEPROM gets the address, locates the data at the address, and outputs a byte back to the CPU (8 lines, single bits?) So, to stuff the bus, you load the data on the 8 bit line without having to do a "LDA" instruction? Which saves the CPU from having to do it? How do you intercept the LDA command before the CPU sees it? Finally, how do you program the game in C when the Atari expects a 6507 binary? Are you converting the C code to assembly/binary (like batari basic) and loading it on the EEPROM?

That's really clever! Any other way to store memory addresses so I can just place the high and low bits without having to look them up first? The way I do it now, works, but it's slow and cumbersome. I load them up here when the game starts. When I need a sprite or color data, I have to look them up again, retrieve the values, then store them in the right places. If I could cut out the looking up and storing and just use a constant value I'd save a lot of messing around.