Pat Brady

Thank you! I was doing one very dumb thing that showed up almost immediately in the a7800 debugger. Once I fixed that, vcs_joystick works fine in a7800. Unfortunately still nothing on real hardware. The fact that it's working in a7800 makes me think that my read logic is correct and something in initialization is wrong.

Meganecrobump. I'm hoping to support all 3 options — 7800 2-button, 2600 1-button, and Genesis — in my game. I've read this thread, and controller pinouts for all 3, and other documents a bunch, I think I understand it, I think it should be possible. My code (in 3 parts): ; EDIT: broken code deleted; see post #26 for working code Running on a Concerto cart, this still works fine with a 2-button 7800 controller. It also works fine in a7800. But with either a 2600 controller or a Genesis controller, it does not respond to any buttons. And over in a7800, I tried tab key -> Controller Selection -> joy1 -> vcs_joystick, but that doesn't seem to make any difference at all. Console & Controller Inputs still shows root:joy1:proline_joystick and it behaves as such. So I'm not sure how to emulate either a 2600 controller or a Genesis controller. Questions: Currently I don't set the controller flag in the a78 header. Should I? Can you see anything wrong with my code? Does the second write to INPTCTRL even do anything, since the first write locked it? TIA. EDIT: mods feel free to move this to the 7800 Programming forum.

Try these exact examples. Try them with SEC before the SBC, and then try them again but with CLC instead of SEC.

Yes of course, though I didn't know the exact breakdown for 7800basic and neither of us knows how big @karri's hand-written DLs will be. I thought I was generally positive towards 7800basic. It's certainly been used to produce a bunch of good games quickly lately.

Looks doable to me. Fewer colors than the Lynx, yes, but I think you can still make it look good. The way I see it, you have 2 choices: Learn the nuts and bolts of how the 7800 draws graphics (read the Software Guide repeatedly until it makes sense, which for me was about 5 times, maybe more) and write your own code to generate display lists. Use 7800basic, have it handle the graphics, and include your game logic compiled by cc65 in assembly form. This does not necessarily mean much actual BASIC code, just some calls to the graphics routines and your code. The big disadvantage I see is that 7800basic consumes more than half of the 7800's built-in RAM. But if 1.5K is enough for you, this option will probably get you up and running faster than option #1. Either way, don't hesitate to ask questions. Graphically, the standard (I think) way to do this sort of thing is to use indirect 160A mode for the background and direct 160A or 160B mode for the player, enemies, and NPCs. In your case, each background region (ocean, road, grassland) will need a separate character map (so that each can have its own 3-color palette). The trees could also have separate character maps, or be done as direct mode objects on top of grassland. The 7800 doesn't have any hardware support for scrolling, so you'll have to do that in software.

I attached a file containing macros I use to check assumptions at build-time. assert itself is similar to assert() in C. It confirms the expression evaluates to non-zero. It uses setstr, so if your dasm is not up-to-date, delete the setstr and the following echo. It will still work and will report the line number but not the failed expression. There are a bunch of macros to confirm parts of addresses are the same. These can be used to ensure that branches and indirect reads don't cross pages, and that data striped across pages is correctly aligned. Probably other purposes too. Finally, validateindirectjmp confirms the low byte of an address is not the last byte on a page. Rationale is that jmp (indirect), when given such an address, will jump to an address that is probably not what you want. In all cases, "confirm" means it throws an assembly error if the condition is untrue. I find these useful. Hopefully someone else does too. assert.s

Is this what you need? Ghosts'N_Goblins_(Ghosts'N_Goblins).zip

"This looks like a loop, but it isn’t." I have read that sentence many times. I think I finally understand it. In fact it *is* a loop, but it is a loop that occurs at build-time, not at run-time. It's equivalent to a loop in template metaprogramming.

khinsider also has mp3s from the arcade version.

Congratulations!

Yes. I run a high-quality RF cable from the 7800 to a fancy tuner, then composite to a Sony PVM. In other words: in the ballpark of as good as it gets for an RF-CRT setup. 160-mode games and 2600 games look great. 320 has a lot of color fringing. I wouldn't say horrible, but it is definitely an issue. I believe it would be better with an S-Video mod — but I'm not certain about that. Want me to look at anything in particular?

@HSW3ET Congrats on the wins! Plus two close runner-ups. In your acceptance remarks, you mentioned an Odyssey game by Rafael Cardoso. Which game were you referring to? I see he has been very prolific, but none of the games I looked at seemed similar to ZΔRKSTΔRS I at all.

Stay. It's good to have different perspectives. Awakening categorized as a port got a sharply raised eyebrow from me. Would it make more sense to you if the formats were described in terms of when they became feasible, or the other games using each cartridge type? For instance, instead of 2K we could say 1977 (or: Air-Sea Battle, Combat, Surround), instead of 4K we could say 1980 (Adventure, Pitfall!, Yars' Revenge), instead of F6SC we could say 1983 (Dig Dug, Millipede), instead of DPC we could say 1984 (Pitfall II), and instead of ARM we could say 2000 (Draconian, Galagon, Space Rocks, Zoo Keeper). It's a bit imprecise because a lot was happening in 1982 and 1983 but it's a decent way to look at it. Does that help?

Oh yeah? Well, I am famous for writing things that don't read as I intended.

Oh. Apologies for dragging you into this. And thank you for the insight you provided about your games and your process. Oops! I did not intend any criticism of your speech at all. I just meant that at that point in the show, I hadn't heard any mention of that aspect. I mentioned your speech only to acknowledge that you did mention it, and your mention was appropriate, it just was not in my thoughts at the time because it hadn't happened yet. It was completely clear that your thanks to Fred were sincere and not tacked on. You said at the time that you re-ordered your acknowledgements, which was appropriate in the situation. Sorry for my wording. As for "not get the credit they deserve." Hmm. Those are not the exact words I'd choose. I know you've been consistent, and your voice ought to be the loudest on this subject, but my perception is that in the community, the point gets blurred and glossed over. Thank you for the kind words! I'm definitely interested, whether the audio is TIA, DPC, or CDFJ. And… it would be great if something constructive came out of this thread . Need to make some progress on a few existing projects first. Will PM you.

No, you're absolutely right, and I should have worded it differently. And last night I was irritated by the notion that constraints are a "comfortable security blanket." That may be true in some contexts, but in the context of Atari 2600 game development, it is bullshit. This is a piece of hardware that has been obsolete for almost as long as it has existed, and we're all trying to do interesting things on it. It is not a source of comfort. It is a challenge. The challenge is the point. What I meant about work was that, in the context of the Awards, speculation on how much work went into each game is not a factor in my voting at all. WRT Game of the Bear and RobotWar:2684, I intentionally chose two deserving winners that did not compete against each other. And though I wasn't thinking of this at the time, they were both written by prolific authors whose full catalogs are pretty much award-worthy.

"We all know it." ? For starters, I do not think amount of work is an interesting metric to anybody but the developers' spouses. But I am almost certain that a lot of work has gone into K-Jo Chases the Cheese, Soul of the Beast, Hellway, and Runes of Moria even though those are only 4K each and don't have a huge number of assets. Squeezing gameplay and content into limited resources is also a form of work. And to me, all four of those games are incredible achievements. Game of the Bear is 32K ROM-only. RobotWar:2684 is 32K ROM plus 8K RAM and a 70 MHz ARM chip. Does that mean RobotWar:2684 was more work than Game of the Bear? Does anybody besides you care? In my particular case, music and sound for 1942, I have an entire 4K bank for in-game music and sound effects (data and drivers). Compared to many games, that is a luxury. The hard part is just coaxing the desired sounds out of TIA. Filling up the space is easy. And I haven't had to devise an optimal storage format, or make difficult decisions about what to exclude. On the other hand, if it was a DPC game, I'd have 3 8-bit oscillators plus one conventional TIA channel to work with. DPC is an additional resource that makes the job easier, not harder. DPC+, with its 16-bit oscillators, is even more of a boon. Okay. Has anybody said enhanced carts are a problem?

Proud to have played a small role in this. Thanks to @darryl1970 and @Synthpopalooza for letting me join the fun and also to Darryl for the nice comments during the show.

Well-deserved. I'm really looking forward to both E.X.O. and Millie and Mollie.

Hope this isn't beating a dead horse. I've been thinking about this a lot, particularly yesterday during the @ZeroPage Homebrew awards show. Full disclosure: I am doing music and sound for 1942, which was nominated for Atari 2600 Best WIP Homebrew (Port), and did not finish in the top 3. I don't feel like this post is sour grapes and I hope it doesn't come across as such. Turbo Arcade is spectacular and certainly deserved the win. Actually all 6 nominees look really good (though I haven't played Qix yet for unrelated reasons). Anyway: The ARM-using games dominated the 2600 categories, again. @johnnywc and his collaborators (among others) do a fantastic job of putting this technology to use. I own a few of his games — some using ARM, some not — on cart and plan to buy RobotWar: 2684. It takes talent and effort to produce games of this quality, regardless of platform. His original Lady Bug port, 16K ROM only, is still one of the best games on the 2600 and one of the best ports of Lady Bug for any console. When James started talking about a Lifetime Achievement Award, I immediately thought of @batari. At that moment I was specifically thinking about, among numerous accomplishments, his invention of the cartridge board that makes possible all of these games that continue to dominate the awards. At that point in the show I had heard barely any mention of either his name or that technology. (John's nice acceptance speech for Atari 2600 Best Homebrew (Port) came later.) If the nominations are going to list the ROM size, then they should list ARM-ness too. The differences between 32K bankswitched ROM — with or without 128 bytes of RAM — and 32K ROM plus 8K RAM plus a 70 MHz ARM are huge, in terms of both what it allows the developer to do and when it became technologically feasible. But currently they are all marked simply 32K. More than anything else: it's time to retire the "I never thought game X was possible on the 2600" claim, at least regarding games that use an on-cart CPU. When someone says that, they mean: "I know something about the constraints imposed by the 2600, and I did not think game X was possible under those constraints." Doing a game using an ARM massively relaxes 2 of the 3 biggest constraints (processing power and RAM), and also lets the programmer do a lot more stuff in the display kernel. This technology has rewritten our expectations of what is possible on the 2600. It has been obvious for several years now. Please don't read anything between the lines above. To be extra-clear: I unequivocally reject the word "cheating" to describe the general use of an on-cart CPU. EDIT: #6 was not intended to call out any individual. I've heard or read that statement from a lot of people and was already thinking about it before yesterday.

Yes, thank you @ZeroPage Homebrew team for putting this on. Congratulations to all the winners and nominees. Most of the categories had numerous worthy candidates. EDIT: when you started talking about Lifetime Achievement Award, my immediate thought was: @batari should have one of those.

On its own, the dark blue panel gives me a hospitalish vibe. But atop a mostly-blue playfield, it might look aquatic. Very nice game here!

Right, I meant bullseye. If you want to toy with it some more, you could make it so that the two forms of extra damage (power-up and bullseye) do not stack, or cap the damage. Or, of course, you could just leave it as it is. Anyway, thanks for the response, I don't mean to be pushy, and I am really looking forward to playing this.

Solstice presumably uses sprites to draw any element — even static ones — that can be in front of any other element, and background tiles only for elements that are always in back. The 7800 equivalent would be direct mode objects for any element that can be in front of any other element, and character maps for elements that are always in back. That's definitely a good way to do it.

I bought a 7800 game from @xucaen. Communication, shipment time, and condition were all excellent.