RevEng

I know I was @'ed for technical advice, but I'm mostly going to just co-sign comments by Karl and Pat. I know firsthand that midi conversions can take up a fair bit of rom, since it's "performance" data and missing pattern structure. You might consider switching from memcpy to using lz4 (de)compression at some point, if rom is tight.

I'm in the "games are art" camp, and I see these sorts of works as not that much different than a study... In our case, composition and technique is usually hidden away in the code.

This should fix the pokey pitch shift issue. Stick it in your project directory, or in the 7800basic includes directory. pokeysound.asm

The pokey support into playsfx was a bit beta, so the lack of pitch shift is probably a bug on my side. it's not like there's much required from the game in terms of pitch shift. I'll take a look. Originally the idea with the 7800basic MML tracker was that pokey would be integrated right into it, with you just needing to select a pokey instrument for a track instead of a tia one. I kind of stopped working along those lines when it was apparent XM wasn't going to happen. It also seemed like most of the 7800basic coder base wanted to sub out to the music to musicians, and the built-in MML tracker isn't well suited for that since it's more of a programmer-musician tool. I could be wrong, but I think it's just you and me that have used the MML tracker for full songs at this point. I'll look at taking on the MML pokey integration at some point, but it's not trivial, so I wouldn't count on it for this game. I've been busy working on already promised stuff, like banksets and pokey RMT tracker support, and even when those I done there's other stuff queued up ahead of MML pokey.

It was a treat to drink my morning coffee and watch this! I always find myself wandering a bit, thinking along the lines of "hmmm... I wonder if they did X to achieve that effect, or maybe it was Y." which adds to the fun. Congrats @Eagle and @playsoft!!! A solid showing from both of you on our little but growing platform!

Seems to work fine for me. Maybe your vblank routine isn't in the kernel bank? bbstarfield_16ksc.bas

It's not a train station, and you don't need to announce your departure, especially if you're saying it might not be permanent.

Documentation is a big thankless job. We do it, but it's obviously it's rather scattershot at the moment, and as a result it's not a hand-holding experience. It's a matter of there being probably less than a dozen active 7800 devs, and usually it's a small subset of devs contributing to docs. It isn't documentation leading to more active developers, as you're supposing, but rather a feedback loop of more devs producing more docs and tools which in turn leads to more devs.. Our feedback loop isn't that strong yet (7800 install base is tiny compared to c64 and nes) but it's been growing year by year. If you doubt that, have a look at the number of new homebrew projects announced and finished over recent years. If you're the type who likes to make their mark, the 7800 is the wild west right now. If you need a mature set of docs that hold your hand, then the 7800 might not be for you. Check back in a few years. 7800 devs exchange this info and show off techniques all of the time. 7800 devs cheer each others projects all of the time. Drop by the dev forum some time. As the guy that spends his own money on running the 7800 dev wiki, spent countless hours revising and polishing the GCC docs, composed all kinds of original docs and tools, and has privately helped assembly and 7800basic devs alike with issues, I find this implication that we're all locking away our secret techniques to be utter trash. If you don't think enough is being done, jump in and help out where you can, rather than criticising how far along we are compared to platforms with hundreds of active devs. Or not. But your armchair critique is dead wrong. Apologies to OP for adding to the off-topic discussion.

TIA sound being used as stock, due to Maria die restrictions, wasn't the worst plan. Bear in mind that the original plan was supposed to be an in-cart Minnie chip supplemented by TIA, with TIA providing the SFX and Minnie bringing per-game customisable proto-wavetable music. (for under $2 per cart) When Atari changed hands that plan was scrapped, for typical Tramiel reason$. Even as the situation stands, TIA is a lot more capable for music than people give it credit for, especially when driven by a system with more than 128 bytes of ram, and more than 4k of addressable rom. You just need the smallest bit of music theory, an understanding of where the issues are, and willingness to work around them. Unfortunately, BITD frequently the person doing TIA game music wasn't a musician, and didn't have sufficient aptitude or caring. Contrast that with NES music being done by staff composers. TBH I think I'd rate the ergonomics of the proline joysticks as the more problematic issue, compared to TIA sound. And sound would be a total non-issue if Atari had actually followed through on the original Minnie plan.

Please. Just. Stop. For your own sake.

Ok, then we're on the same page. FWIW acknowledging NES advantages hasn't been taboo for me. I could dig up more, but I can't stomach going down memory lane through all of the VS threads.

Yeah, I'm still going to submit that's your preference, rather than some objective truth. 256 vertical resolution is indeed a good middle-ground mode, but 32-character display isn't ideal for text heavy games. Ever get sick of pressing A over and over again during NES character dialogue? There's something to be said about being able to section the screen into 160 and 320 modes. I guess we're doing the full comparison, then. Ok, lets carry on the VS thread.🙄 You seem to have overlooked that sprites on the NES are limited to 8x8 or 8x16 pixels, and putting any more than 8 sprites on a given scanline will result in flicker. I'll take the better sprites with loss of cpu time to dma any day, because I can always be clever with my cpu usage elsewhere. You can't clever more hardware sprites out of the NES. It's also a shame that the NES doesn't have an audio-pin on the cart connector. It would be pretty cool if it could have a cart with FM synthesis, or a custom diy sound chip, like you can on the 7800. You know, it's almost like we're talking about different machines, with different strengths.

The display for 7800 petscii robots doesn't rely on any mapper tricks - the tile engine can run on a supergame cart no problem, but it would just have access to half as many tile graphics. That's not enough to implement the petscii game, but certainly enough to run a game with the same 160b tile type display. Supergame or even a flat 48k would even be enough to recreate any one particular petscii robots screenshot. It's just the arbitrary combinations of the 256 24x24 tiles that demanded the new mapper. I do think that trying to judge a console superior by looking at a particular port, or declaring one console superior due to lack of a port of some native huge-budget game, is stupid. As Defender_2600 said earlier, 7800 and NES are different machines, each with their own strengths. The ports might be instructive of particular platform strengths, like petscii robots showing off the 7800's 12+1 colors vs the NES 4 color tiles, but that's as far as you can take it. Anybody thinking one of these consoles is generally better or worse than the other, from a technical perspective, has a severe case of Dunning Kruger effect.

A filmmaker doing a twitch stream is a bit like a novelist doing slam poetry. How do the two compare and contrast, and what itch does each scratch for you? Everybody has pivotal moments in their life, where a single decision leads them down a unique path. Was there a particular moment that brought about the ZPH stream, and what are the mirror-universe James and Tanya doing now instead? What's your favorite color? (j/k)

No, keep the header ORGed at $3F80. This will produce an a78 file that's 48k plus the 128 byte header, which is what you want.

Even though you might ORG the header at $3F80 for the purposes of pre-pending it to the ROM, the header doesn't actually live in that address space. The header gets parsed+skipped by the emulator or flashcart when it's loading the rom into memory. Your ROM starts at $4000, not $3F80.

With the 7800basic high score code, or with loadmemory/savememory, a new slot will automatically be initialized with 0's. You won't run into FF fill for either savekey or hsc.

Thanks for that, Trebor! One thing for that "among other things" list that I keep meaning to mention - our robots are all sprites that are overlaid on top of the tiles, rather than replacing the tiles they stand on like most of the other ports. (AFAIK only the 16-bit console ports of the game overlay the enemies like we do) Delving in a bit deeper, the game uses a sprites-as-tiles design, which means the main game area is composed of 231 sprites, and another 84 sprites for the robots, the hero, and other overlay objects. So 315 sprites in total, not including the sprite graphics for the "doom guy" health, active weapon, and active item. The 7800 is truly a sprite monster.

Congratulations, James - that's so cool! Double Fine is one of my favourite game studios. Tim is not only an industry legend, but he's also managed to remain highly relevant and completely original.

Dasm isn't able to seek around in the rom like that - it can jump forward, but jumping backward in between two previously filled areas doesn't work right - so I have no way to implement that.

Thanks for the kind words, guys!

It is calculated, and something I've never heard a single teenager actually say about themselves.

Thanks Karl, Due to it being an edge case that's easily worked around in game code, it's probably better to just document it as a limitation. I don't think the extra rom and cycles are warranted.

Yeah, but there may be exceptions. Sometimes authors put optional controllers on port 2, to avoid making the user unplug their main controller from the game. Having an oddball controller plugged into port 1 also makes it difficult or impossible to navigate flashcart menus, depending on the cart. Yup to all of that, with the slight correction that it's the high-bit of INPT4/5 we're dealing with.

That is a stunning development. For various reasons, I don't think you can count on the snes2atari being in a particular port. e.g. If a game supports atarivox and snes2atari, then the snes2atari will almost certainly be expected to be plugged into port 1. Does A7800DS pull and use controller info from the a78 header?