ZackAttack

I like this!

Weather and daylight could be interesting too.

The latest mockup looks feasible. A few color changes mid scanline should be fine. How exactly would this be played? I bet it's going to be tricky to tune the controls.

When you say flashing games is that from a dev perspective? I have plans for using the USART to accomplish this. A python script could be called from the make file to upload the build and the cart can automatically switch to playing it. Unless the system gets crashed this should be possible without a power cycle or any controller input. USB would be nice for firmware recovery without an st-link. Though that situation should be rare. Firmware dev is easier with st-link. I'll try to include USB if it's not already there.

Neither did I for most of the time I spent developing it.🤣 I'm flattered that you still remember this 7 years later. @ZeroPage Homebrew it was a pleasure being a guest on your show. I'm really glad that you and Tanya enjoyed playing Octopusher. It really motivates me to get a demo posted and eventually a cart release.

As was recently announced on ZPH, I've developed a new cart to complement the uno/plus family. It's called the Chameleon Cart and features an STM32G0, 16MB of flash, and wifi support. It's intended to provide a path to publishing 2600 and 7800 ARM enhanced games to carts. It supports the new elf type roms so you can share games for it with uno and plus users once updated firmware is released. With all the issues of acquiring good f407 dev boards, I think this would be a good time to create a new pluscart PCB that places all the components directly on a single board. It would also be a good opportunity to combine SD, WiFi, SPI Flash, etc into a single board. I'm happy to take the initiative of designing the PCB and funding the initial run of 5-10 prototype boards. Before I begin, I'd like to know if anyone else has already started work on this and is willing to share or collaborate to save me some effort. Also, please let me know if there are any other hardware features that should be included. Thanks.

We should avoid firmware in the name since we could also throw the kicad project for the all-in-one multicart in there too. How about MultiCart10400 ("MC10K" for short)? Multicart has a dual meaning because there are multiple cart designs and the carts themselves are multicarts. The 10400 because of support for both 2600 and 7800.

I bought a few off e-bay. Did you see my comment about using the stand alone stm32 programmer, setting Shared=Enabled, and then refreshing the Serial Number? I often get a bad serial number, but doing that seems to always fix it.

Always set to boot from flash. st-link doesn't care about the boot pins. It can initiate the flash programming at any time. Once the firmware programming is done, power cycling the atari is the only step.

I flash my PlusCart firmware via ST-Link all the time. I only connect SCLK, SDIO, and GND to the ST-Link. The cart is programmed while sitting in a powered-on Atari 7800 for power. I've never needed to bother with resistors. It's just wired directly to the st-link as shown in the post below. I've also seen that sometime STM32 Cube Programmer has trouble detecting the st-link properly. If the Serial Number is not populated with a valid number, try enabling Shared, and refreshing the Serial Number.

Here's the source code for a display kernel which could be used to make a Dr. Mario clone. It was something that @MayDay and I had worked on a while back. For now, we don't have any plans on finishing this project. I figured I'd post the binary and source here in case it's useful to anyone. Feel free to add to it, learn from it, or turn it into something else completely. antivirus2600.bin antivirus2600.zip

Yes, it's basically a variation of the Strong-ARM Framework I posted a while back. It's targeting a much weaker ARM chip though to make a cart release feasible. There will be more details on that later when I release the source code for this game. No, I don't think this would count as bus-stuffing since there is no intentional conflict. At no point is the ARM stuffing its own value over an existing value placed on the bus by TIA/6507. I implemented controls for P0 last night, but it felt very awkward trying to push around blocks when P0 movement has 1pixel resolution. Then I tried limiting P0 to moving one block at a time. Pushed blocks instantly move to their new positions for obvious technical reasons. However, P0 will move smoothly and animated to the next block position. Almost ready to post a build. Just need to handle removing blocks when 3 are lined up and it will qualify as a playable game. If anyone has any suggestions for the missiles, that would be great. I'm thinking they could serve as a power up, but not sure what or how.

This turned out to be just what I needed. I had to jump through some hoops to make it all fit. The kernel is exactly 76 cycles now. To free up the missiles I replaced the center border with a PHP, using the status register as the border color. There's not enough time to use ldx/txs/ldx to reset the stack pointer to the COLUPF register. Since AUDV0 only uses D3:D0 and TIA Read registers only drive D7:D6 a PLA can be used to fix SP and put the next audio sample in the A register. This saves 2 cycles. Here's the pseudo code for the kernel as well as the results in Gopher2600. pla ;4 4 Resets SP back to COLUPF and loads a 4-bit audio sample sta AUDV0 ;3 7 lda # ;2 9 sta GRP0 ;3 12 When the row doesn't contain P0, replace this with a JMP to keep the PC in the ROM region. lda # ;2 14 sta GRP1 ;3 17 lda #ColorA ;2 19 st? ENAM0 ;3 22 A and X colors have opposite bit values, so use one or the other to enable/disable respectively st? ENAM1 ;3 25 Same as M0 st? COLUPF ;3 28 store A,X, or Y depending on which color the blocks should be st? COLUPF ;3 31 st? COLUPF ;3 34 st? COLUPF ;3 37 st? COLUPF ;3 40 st? COLUPF ;3 43 st? COLUPF ;3 46 st? COLUPF ;3 49 php ;3 52 P=BorderColor and SP=COLUPF st? COLUPF ;3 55 st? COLUPF ;3 58 st? COLUPF ;3 61 st? COLUPF ;3 64 st? COLUPF ;3 67 st? COLUPF ;3 70 st? COLUPF ;3 73 st? COLUPF ;3 76 Now I just need a good use for those Missiles!

Well now that you pointed it out, it's very annoying. Ball is already used to widen the center border to 9 pixels. Otherwise, the 1st column for the right grid would be a pixel too big. But you got me thinking, why not fill in the other side with M0. P0 won't ever cross the center border and there's a 3 cycle gap between the sides that's just enough to write COLUP0 with the color of the last column's block. The right most border is now 3 pixels though. Dynamically generated by ARM. Thanks. I'm afraid there aren't any cycles left to do much more. 16 COLUBK stores = 48 cycles 2 COLUP0 writes = 8 cycles (save a lda# because registers already have the block colors loaded) GRP0/1 writes = 10 cycles AUDV0 write = 5 cycles (sampled audio) LDA block color = 2 cycles That leaves 3 cycles to write ENAM1. M1 could be serve as an object that can only be used by one player at a time. The other option would be to truncate that rightmost column and have missiles available for both players simultaneously. I think I prefer the first option because the blocks are the most important aspect of the gameplay, and it would be much cleaner to have them all the same size. If there's a good reason to need multiple missiles, that could always be done with flicker. Here's what it looks like with the column size fixed, and blocks randomly added. I'll post a playable bin once P0 controls are fully functional.

No, the border is playfield. The blocks are drawn by a series of writes to COLUBK. The colors were carefully chosen so SAX results in black. STA, STX, and STY give the three different colors for the blocks.

I've been playing around with the idea of a simple game that puts two players in competition with each other. I'd like to get some ideas on how I could enhance the game play. Here is what I have so far. The screen is divided into left/right regions with each region comprised of an 8x16 grid. Each block in the grid can be one of 3 colors or no block. Each player will move their sprite to push/pull blocks into position. Grouping enough like colored blocks would clear them from the grid. New blocks will appear at random in unoccupied spaces. Whoever goes the longest without their grid being filled is the winner.

Shouldn't be too difficult to accomplish assuming you're talking about a cart with a microcontroller in it. You'd just need to add some sort of pre-amp and route it to an available Analog-Digital-Converter (ADC) pin. If you have an UnoCart, st-link, and some basic electronic skills, you could test this out fairly easily by repurposing the NTSC/PAL/PAL60 jumper. The schematic shows that PAL60 and PAL go to PC0 and PC1 respectively. The datasheet for the stm32F407 shows that there are ADC functions on both of those pins. I would think something similar could be accomplished with the PlusCart as well. Though you'd probably have to do some soldering for that one. I don't think Harmony hardware supports USB-OTG. PlusCart should in theory, but I haven't had a chance to try that out yet. This would take a lot more effort than the ADC solution mentioned above.

Another option would be to make it configurable so each user can get the font they like best.

They are still in active development. James, I plan to reach out to you again once I have something close to the final release. You were already kind enough to show off the early prototypes and I didn't want to take up anymore of your time until we have a cart worthy version to send you. As @DirtyHairy said, I have been working on a fork with support for bus stuffing. I plan to release it and the source as a universal bootloader once it's fully functional. I'm aiming to have it released before July of this year.

The amount of time it takes to read the address bus and put the corresponding value on the data bus is fairly large. There's only about 400ns (rough estimate) between when the 6502 puts an address value on the bus and when it expects the data value to be returned. Tight polling helps ensure that as soon as the address value changes the new value is worked on right away. If you only polled at a 2.4MHz rate it would eventually be at just the wrong time so that you end up missing the deadline and leave the previous value on the bus too long. There's also the overhead of interrupt processing. That is fairly minimal on ARM, but if you're doing it 2.4 million times per second it's consuming quite a few cycles and leaving very little time for useful work. What I've done with my projects is to anticipate what the next address will be, pre-calculate the corresponding data value, and then poll for it. As soon as the address changes to what I expect I put the data value on the bus and then use the rest of that cycle to do some computations for the next value. This allows time spent on reversing bits for playfield values, looking up colors in a table, masking sprites etc. Regarding DMA. Most banking schemes should be updating pointers or offsets to switch banks because copying a block of data would take too long. If there were block transfers being done, DMA would definitely be a good idea though. If you're asking this because you've encountered a banking scheme which has too much latency it may be the flash cache mechanism. ST claims 0 cycle wait states with their flash accelerators, but I've noticed when debugging firmware with a logic analyzer that there are occasionally visible delays due to flash caching that can cause a missed deadline. It's a bigger problem on the 7800 because the 6502 is clocked faster in that one. Eventually we should run all the critical banking code from SRAM to avoid these caching penalties. I've also noticed that it's dependent on code location in the flash. So making a change to a completely unrelated portion of code can move everything over just enough to cause a problem. Just like in 6502 ASM when you forget to org a lookup table and some changes push it across a page boundary and leave you with an extra cycle in your display kernel all of a sudden.

Yeah, just make sure to leave the system powered on for a minute after running the firmware.bin or until the "update complete" screen is displayed. Whichever comes first. If your firmware is too old to support updates it won't even be able to load the firmware bin file format. Should be safe.

Rather than disabling the carts, you could create a simple rom that puts up some text with a message to the end user and then redirect all their downloads to it. That way they can be informed that the device they purchased is in violation of GPL and where to legally obtain harmony, uno, and plus carts.

I agree with @DirtyHairy, pirated harmony carts is not acceptable and I don't want work with anyone that continues to do so. My stance is either he comes into full compliance for all projects or he's not welcome in any of them. Hopefully he goes with the former since he appears to be capable of making some good contributions to the community. Btw, are we sure that they are in fact pirated? If he designed the board and firmware from scratch that wouldn't be any different than uno and plus cart supporting dpc+ games.

I've been toying around with building my own PCB for the 2600 and I've noticed that the price difference between ENIG gold fingers and hardened gold is quite a bit. Especially in low volumes. Does anyone know if there are existing cart PCBs that have used ENIG for the gold fingers plating and how well they have held up? My concern is that ENIG might seem to work fine for the first couple of years, but will eventually have corrosion or wear problems that only show up after years of service.

That might be a good choice if you have a need for the JTAG functionality in other projects. STM and ESP can use JTAG too, but I have yet to encounter a scenario where it was actually needed or helpful. I just use one of the cheap usb stick type ones from amazon. Just search amazon for st-link v2 and you'll find a bunch of choices like this: https://www.amazon.com/HiLetgo-Emulator-Downloader-Programmer-STM32F103C8T6/dp/B07SQV6VLZ/