Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

15 Good

About wallaby

  • Rank
    Chopper Commander

Recent Profile Visitors

2,194 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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!
  5. 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?
  6. 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.
  7. 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?
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. 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!
  13. 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.
  14. 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?
  15. 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?
  • Create New...