ZackAttack

I would recommend against cloning the harmony/melody boards. There are much more powerful microcontrollers available now. Something with hardware FPU would be nice. There's still some uncertainty around bus-stuffing, so I think it makes sense to get it working on the harmony first. Then if the harmony isn't strong enough the driver could easily be ported over to a more powerful microcontroller with minimal effort. It's already known that the melody board just wires an NXP LPC2103 directly to the VCS buses. It would be fairly trivial to do the same thing with a newer LPC series. Something like a LPC4078fbd100 would probably work nicely. In low volumes I think you'll be surprised with the total cost of each assembled board though. I can't imagine there is much margin on the harmony carts. I've always been disappointed that the DPC+ driver wasn't open source. Had it been I'm pretty sure we'd already have bus-stuffing by now. The harmony is a good piece of hardware that has been held back by software. It's just a shame that the entire community wasn't able to contribute to the software.

The deciding factor is whether or not there is bus contention. Sounds like your plan is to use the pld as a proxy between the VCS and ROM. In that case you've created a new banking scheme that's more complex than most, but it's not bus stuffing and you shouldn't have to deal with any of the bus stuffing related issues I mentioned above.

It's been a while since I've had time to work on this. The work that some of the other guys on here have been doing with the harmony cart uncovered an issue with bus-stuffing that would impact my design as well. Through some collaboration, several experiments, and the help of many AA members I've reached the following conclusions. Some systems can only be bus-stuffed with 0's forced onto the bus Some systems can only be bus-stuffed with 1's forced onto the bus Some systems can only be bus-stuffed with a specific combination of 0's and 1's forced onto the bus Some systems have very noisy address buses which makes it difficult to accurately read the next address in a timely manner. My proposed hardware design would not work on systems where one or more bits must be stuffed with a 1 instead of a 0 One of my biggest motivations for this project was to learn more about all the technologies involved and that has certainly been the case. The changes I would need to make to the hardware would make it so similar to the Harmony cart that it just wouldn't be worth the effort. At this point designing a cartridge that supports 100% C/C++ game development is just a matter of building a new software suite for the Harmony hardware. This would include a brand new driver that operates much differently than what's out there now. I was able to put together a POC where the entire Atari game was written in ARM assembly. The biggest uncertainty right now is whether or not I'll find the time to continue working on this.

I'm calling it a success. Hopefully everyone agrees. Could always enhance the driver to include a "fast jump" feature. JMP FastJump would be detected and the 2 byte address is pulled from ARM memory instead of the ROM. Similar to how fast fetch works.

That's great. Based on your previous post the Jr was the only one that failed with the stuffing low test program. So at least one of the test programs has worked on every system you own, correct? Thanks for testing this! I posted it again here. Please try again. Thanks.

I'm pretty sure we've ruled out timing related issues at this point. I was able to verify with a logic analyzer that the stuffed value is always put on the bus at least 100ns before the 6507 asserts its own value. The ARM syncs with the VCS on every VCS clock cycle so there isn't really an opportunity for them to drift apart.

The plan is to detect which method works and use that on a system. So if the first test program works there's no need to test the stuff high test program. As long as one or the other works we're in good shape. Do the three systems you show failure with stuff high all work with the other test program?

We've found that some of the failures can be corrected in software by stuffing in 1's instead of 0's. Would you please try this new test program on any systems that the first test program failed on?

Thanks for providing the pictures. That's very helpful. What's really interesting is that it was always working where it stuffs a single bit per byte, but the same bit failed when stuffing 7 bits per byte. Could you also post a picture of the power transformer you use with that system. Specifically I want to see what voltage and amperage it's rated for and if it's AC or DC. I'm not really sure it means a system is unhealthy if it doesn't handle bus-stuffing. I think it's more of a variation thing. There are internal resistances that vary from one system to the next and in some cases the resistance is such that bus-stuffing doesn't work. Temperature changes can change the internal resistance of some of the components. That may be why it took some time to start working. There are also some variations in the voltage threshold that determines if a signal is interpreted as a 1 or 0. I think that's why stuffing high works on some systems where stuffing low doesn't work and vice versa.

Sorry, I had originally posted in a private conversation and didn't realize it works like that. Try this one. stuff test 2 - going high.bin

Would the three of you please try the following test program on the systems where the previous test program failed? Instead of stuffing a 0 over a 1, it stuffs a 1 over a 0. This fixed the problem for MayDay and I'd like to see if it works for you too. If it's working correctly you should see this:

The clock speed is relatively low. Long wires and breadboards shouldn't prevent it from being stable. It should work better with the grounds all connected, not worse. One thing I can think of is that there is a loose connection somewhere and you moved other wires while removing the ground connection. It could be a bad solder joint, open hookup wire, loose socket in the PCB, etc. I'd wiggle each wire one at a time while it's running and see if wiggling a wire causes it to stop working. If it does then I'd carefully inspect all connections related to that wire. Are you using solid core hookup wire? I've always used that for these type of experiments and it's always worked well. If you're using stranded wire it may not work as well.

Programmable logic chip would be the easiest thing to prototype with. If you have enough I/O pins on the logic chip I'd connect the full VCS address and data buses to it as inputs. Depending on what your smallest bank size is you will connect that many VCS address bits directly to the eeprom. The remaining eeprom address bits should be driven by the logic chip.

I've been researching how to perform quad bus stuffing with the harmony. Thought I'd share some of my analysis of the VCS bus timing in case anyone is curios what a read modify write looks like on a NTSC system. PAL would be almost identical since they only differ by 7ns per cycle. Please note that due to lack of additional logic analyzer channels only A0-A7 and D0-D7 is captured.

Sounds like you may have an incorrect pinout. 2KB games should ignore A11 and 4KB games should use all 13 (A0-A12) address bits. A12 is used for CE so that leaves 12 bits for 4KB and 11 bits for 2KB games which is exactly what is required. Here's what the eeprom memory map should look like for a 2KB game. VCS EEPROM $0000 Not Enabled $0fff Not Enabled $1000 $0000 $17ff $07ff $1800 $0000 $1fff $07ff

Did you double up the 2k image to fill the first 4k or wire eeprom A11 to ground? As you described it in your first post it sounds like you have $1800-$1fff set to $ff. The address map is determined by the hardware. What you do with address bus and chip enable is what decides what gets mapped where

Also, since it's a 2k ROM you need to either program it twice to fill the ROM out to 4k or tie ROM A11 to ground so the first 2K is mirrored at $f800

You need to map your ROM into the address space of $1000-$1fff. A0-A11 should be wired directly to the ROM's A0-A11. A12 should be wired to a not gate and then to /CE. The remaining address pins on the ROM should be tied to ground.

Is there a drawback to the ZP RAM method? If it's not reliable enough, you could try to do the 2600 vs 7800 detection at power on when the 7800 is still clocked at a much higher rate. Of course, that's going to have to be supported in the harmony firmware since it happens before the DPC+ file is loaded.

Shouldn't the timing be the same for both since the 7800 is operating in the backward compatible mode where it intentionally slows down the clock to match the 2600 spec? Also, what would be the practical application of detecting it's 7800 vs 2600?

I think you have to count frames. For 500ms it's only 5 bits though. Just increment the variable every frame. And with $e0 if button isn't pressed. If count exceeds threshold switch modes. You could make $20 the flag for displaying the other mode so you switch modes for free once it counts to 32 frames. Then you can and with $C0 regardless of the display mode and releasing the button switches back to the original mode.

The problem is that you've put the missile code in GameLoop which precedes GameLoop1. GameLoop1: jsr VerticalSync jsr VerticalBlank jsr Kernel jsr Overscan1 jmp GameLoop Move any code in GameLoop1 to Overscan or VerticalBlank subroutines. Remove GameLoop1 since it should now be equivalent to GameLoop Rename Overscan1 to just Overscan Only ever have a single VSync, VBlank, Kernel, and Overscan routine/label. This reason this is a problem is because the PositionPlayer subroutine you're using will take 1 or 2 scanlines to execute depending on the position it's setting. Since VerticalBlank and Overscan1 use the timer to determine when the right number of scanlines has passed they are agnostic to that detail. Basically you have 30 scanlines to execute some code in overscan, but it's ok if it takes less. Also a style tip is to keep the subroutines located in your source file according to where they are in the call hierarchy. So the following order would be appropriate: Reset: GameLoop: VerticalSync VerticalBlank Kernel Overscan Next would be any routines that are called from the routines I've already listed. The idea is that you should be able to open a source file and immediately get a feel for what it's doing at the highest level of abstraction. Then you can drill down further to get more details if desired.

Space invaders uses triplicated players to generate 6 sprites without flicker. That's why each row of aliens is the same exact graphic. In stella simply press alt+, to enabled fixed debug colors. Then you can see which object is used to draw what. alt+z and alt+x can be used to enable/disable P0 and P1 respectively. That also makes it easy to tell what came from where.

open stella debug (press ~ key) trapwrite ShowMissile1 resume execution (press ~ key) never breaks open stella debug (press ~ key) break GameLoop resume execution (press ~ key) breakpoint is hit step through code reveals that branch is taken at bmi IHateThis, this skips the check for Missile1X as well Solution: Merge MissileFired and ShowMissile1 into a single variable. Treat this as a simple finite state machine (FSM). States are Missile1InFlight $02 amd Missile1ReadyToFire $00. Renaming to Missile1State during the merge has the added benefit that the code will break in every place that the MissileFired and ShowMissile1 are used. So it won't assemble until every relevant spot has been reviewed and updated. Still doesn't work. Stella debug reveals that Missile1X never changes. Add instructions to keep variable in sync with actual missile position. Updated source attached. fice3.asm

Which data pin did you collect this data from?