Pat Brady

I am probably not the best person to answer these questions, but since I sense this is directed towards me, I'll answer as best as I can. Regarding address detection logic, the idea is that for $080x mirrored up to $0FFx, a hardware implementation can generate the chip select signal from only 5 address bits, whereas for $045x it must read 12 address bits. For the device chosen for bankset cartridges, that apparently was an important consideration. After my previous post I realized you could mirror 32 bytes for 2 POKEYs, which would work just as well as mirroring each POKEY individually, so maybe I shouldn't have said anything about 2nd-POKEY-at-$081x. It's not really any worse than 2nd-POKEY-at-$0C0x. But as long as it's only for Dragonfly and emulators, dual-POKEY developers (a small group!) should just use the existing $04xx scheme IMO. As for RAM testing at boot, I have no idea. Does the NTSC BIOS access these addresses?

The purpose of POKEY@$0800 (mirrored up to $0FFF) is to minimize decoder logic. To add a second POKEY to this scheme, the sensible address is $0C00 (making one POKEY mirrored from $0800 to $0BFF and the other mirrored from $0C00 to $0FFF). OTOH if anybody just wants two POKEYs without regard to decoder complexity, just use the existing $0440 and $0450 scheme.

In gaming, "AI" has long referred to whatever algorithm a game has for computer-controlled elements.

I think your implementation is not quite correct. I think the correct way is a 2-step process: 1. Loop over the solution; if the guess contains the same letter in the same position, color it green 2. Loop over the solution again; if the corresponding letter is not green and the guess contains at least one of the same letter in a different position that has not been colored, color one yellow (There are other algorithms that will get the same result.) For example, if the solution is FIFTH and the guess is FLUFF, the first F should be green, one of the other Fs should be yellow, and the remaining F should be gray. For another example, which just happened to me, if the solution is SPASM and the guess is SPEWS, the first S and the P should be green, and the other S should be yellow. Instead the other S was gray. See screenshot. I couldn't find any other words that fit the available information so I guessed SPASM anyway. Otherwise, this is really nice!

No, just the WIP I posted several months ago. There's a lot of work yet to do.

7iX is entirely 320C.

Nice game. The darker background is a big improvement. It makes the sprites pop as opposed to blending in. If you want to experiment further, try $31 or $32 (same hue as the bricks but darker) instead of the purple. The boss is also a good addition. The first phase is much easier than what came immediately before. Not sure if that's intentional. I believe the raw .bin file is needed for Cuttle Cart 2 and Mateos carts (neither of which I have). AFAIK everything else takes .a78.

This is great but now somebody needs to create a Rage Reset logo.

Well, "Sprites as tiles" has been mentioned in several threads but AFAIK is not defined anywhere. If I understand correctly, the idea is to use direct mode with one object per grid location ("tile") that combines both background (floor) and foreground (player/enemy/generator/treasure/food) into a single bitmap for that tile. The downside I see is that it requires a lot of graphics data, so it should fit well with SOUPER or bankset. I've given some thought to Gauntlet, and this is what I've come up with: The playfield objects need to use 160B with each tile being 8 pixels wide. Shots probably need to be in separate (direct mode) objects, otherwise the number of bitmaps would explode. For the status bar, most obvious approach is 160A indirect mode. Per-line DMA time is 8+4*3=20 cycles per tile (plus 2 cycles for the first column since 5-byte header is necessary to toggle write mode) for the playfield and 10+10*6=70 cycles for the status bar. One option is 15 playfield tiles (same as arcade), and 10 status characters (1 less than arcade, probably fine), but there can be only 2 shots per zone before running out of DMA time, and 2 shots per zone is definitely not enough. More programming work (and CPU cycles and RAM), but I think the status bar can be done in a single direct mode object with the bitmap in RAM, saving enough DMA time to add 2 shots per zone for a total of 4. That's still not enough (on levels with demons or lobbers) but where to go from there is a matter of opinion. I'd be inclined to flicker shots instead of shrinking the playfield. Vertically, 15 zones of 13 pixels each would make the playfield nice and square (both overall and per tile), the same grid size as the arcade, and works out to 195 lines, a good number; score/health digits would be 3x5 which is also good. So to answer the original question, I think it is possible, but of course you never know for sure until you try. CPU cycles will be precious, and 8x13 sprites might be a challenge for the artist. I agree with this, but the work you've put into a7800 and documentation is a huge reason why that's the case.

In 7800 2-button mode, the console drives pin 6 high and these resistors pull pins 5 and 9 down unless the corresponding button is pressed.

FWIW the general term for this type of game is "flip-screen." Here is a list of flip-screen games. EDIT: Not sure if any of those would be considered similar to Gauntlet. That list contains many games that I am not familiar with.

Yes, TIA was outdated by 1984 (and even more by 1986). But it's much more capable than its reputation suggests. I think it gets a bad rap because people judge it by games that use it poorly. For example, I've seen people name Donkey Kong 7800 as an example of TIA sound. But listen to D.K. VCS (2600 homebrew with no special audio hardware) and it becomes clear that Donkey Kong 7800 should instead be cited as an example of rushed ports. And then people use TIA's bad reputation to justify further poor usage, or to use POKEY when TIA might have sounded great. From the original 7800 library, Ms. Pac-Man is pure TIA and sounds fantastic. Xevious also sounds really good. Anyway, I think the OP was asking about advantages and disadvantages of owning an actual 7800 as opposed to playing 7800 games in emulation. TIA sound from a 7800 console is no worse than in emulation.

Sorry for the slow response — I didn't have a chance to get back on the big rig until just now. With this one I did see some instability during gameplay, especially on level 2 after all but one box was in place, but no flashing between levels.

Mac: I installed the arm-none-eabi-gcc package from macports then built and ran your CDFJ Collect3 program without any problems. (Likely using some other stuff I already had installed.)

If it's fine with them, it's fine with me.

Have you heard from @Eagle? Their SN76489 project exists (at least as a prototype), they already asked for a carttype bit, and they were told they could have it — which was the catalyst for this entire discussion. I think it would be uncool to now yank that away from them and instead give that bit to EXRAM/M2-without-bankset (which AFAIK currently has neither an implementation nor an application) without their consent. If @Eagle does not consent, then I suggest using those last two bits for SN76489 and POKEY@$0800, and deferring EXRAM/M2-without-bankset to v4 headers. Other than that, no objections from me.

This is great! 40 is a good number of levels, and I like the new rolling color effect on the title text. Looks like there is still a brief scanline instability between levels, causing an unsightly flash on my digital rig. During gameplay it seems rock-solid. Haven't tried it on CRT yet but I believe those are more forgiving than digital setups. I have a few minor suggestions — which you may have thought of, but I want to say them just in case: It might be nice to change the colors every 8 (or some other number) levels. If possible, make the boxes taller. 3 lines (drawn across 6 scanlines), aligned one scanline higher than the targets, could represent the boxes going on top of the target. 4 lines drawn across 7 scanlines would also look good. I assume the title text is pushed over to the left to minimize writes to playfield registers. But if possible, horizontally centering it would look a lot better. Moving it down to slightly above the play area (which varies from level to level) might also help. A move counter would be nice, more useful IMO than the title text. Regardless of those quibbles: you've done a very, very nice job here.

Oh. I was thinking to use FFFF only when the new headers are necessary (i.e. older emulators should not attempt to run this program), not whenever they are present.

I was just curious whether a board that can host Popeye or Pengo/Penta is something that exists, and about the urgency of switching new SuperGame homebrews (with ROM or RAM at $4000) from POKEY@$0450 to POKEY@$0800. Right. I recently changed my game to use a RAM buffer for the primary enemy, and I was shocked at how many SALLY cycles it takes just to clear my relatively small buffer. (I also use RAM buffers for playfield, but the big updates to that don't have to meet screen timing.) I'm a bit confused here. Bit 15 is $8000. I don't have an iguana in this fight — deferring SN76489 is totally fine with me if it's fine with @Eagle — but what's the compatibility issue with $FFFF?

?? Looking forward to seeing what this enables. FWIW my feeling is that we're approaching agreement on the v4 stuff. But, I know that you've got a game that's nearly ready to go, and if I was in that situation I would not want to delay it for committee deliberations. I think the best way to go is: use bit 14 for @Eagle's SN76489 project (which was the impetus for this entire discussion), bit 15 for POKEY@$0800, and specify $FFFF as the warning signal. Based on @TailChao's analysis, which determined that some readers mask the high bits, $FFFF seems like a better warning signal than $8000 anyway. The other option I thought of was to repurpose bit 10 under circumstances where POKEY@$0440 doesn't make sense. But this adds more complexity. Semi-related: is there a stand-alone board that provides POKEY@$0450?

As the (only?) person who's been banging the drum for supporting things that don't currently exist in hardware form, I want to explicitly endorse this definition. My intent was never to enable emulation of implausible hardware. This is a good balance. And for the combinations in the 2nd and 3rd categories: I am totally on board with emulator and/or header-generator warnings. Alert developers that they need to do the boards (or get somebody else to) without blocking development.

Very nice! How many levels?

Apologies if this sounded pushy. It just seemed like @batari wants to do this but thought programmers particularly want $0450. And I should also not speak for other developers, but my expectation is that most will use whatever address works.

Yes, with the current combinations. But new features are being added frequently. I don't think that's fair. I've taken feedback from you and @TailChao and updated my proposal accordingly. In particular, my last update (post #89) specifically allows you to list the currently valid combinations. It's really not very far at all from what I think you had in mind. First of all, thank you for providing Concerto. It may not have come through in my comments, but having a Concerto has been a huge boon for me as a developer and also very nice as a player. The situation with POKEY@$0450 (as opposed to somewhere else) is chicken and egg. Programmers use $0450 because that's what's supported. Provide POKEY@$0800 (or wherever you want) on Concerto, one of us will add it to a7800, and we'll start using it. And, if it's not too late, and if @RevEng and @mksmith are on board, do it now, before banksets are released into the wild. Especially if that means you can do more other stuff on the bankset board!

This seems to be the big area of disagreement now. I'm apparently falling on the end of being more permissive. It's mostly based on my observation that flashcart firmware does not get updated very often. If emulators are restrictive, no big deal: a7800 is open source, any developer can patch in whatever they need whenever they need it. But if flashcarts are restrictive then it is a big barrier. To be clear, I am talking about combinations of features that are already supported. I am not asking anybody to code up some fantasy mapper or sound chip. OK, point taken. Well, following your logic above, if you mirror the whatever-it-is, you can save some lines. For example POKEY@$0400 with 7 mirrors up to $047F would save 3 address lines. Is there anything between $0800 and $0FFF? Giving that entire chunk to a POKEY would save another 2 lines. (Since there is precedent for 2xPOKEY it might be best to split that area into two; that would still save 4 lines compared to $0450.) Anyway, I don't know if that's what @batari had in mind but he certainly seemed to have something in mind. I hope he proposes it.