Bruce-Robert Pocock

For contrast, I just ran this on my Encore (on a '7800 with S/Video mod) for over 150 passes and no errors beyond the expected blocks in the top row. It also works fine with EF ROMs though. Dunno if that helps. (I have a couple of '2600s that I can pull out and test on as well if more data is helpful.)

Personally, I use Makefiles for what they're good at, but also Perl for simple things — like parsing sources and writing Makefiles based on their inter-dependencies — and Common Lisp for more complex things. Disclaimer: I promise my real code is nowhere near as big a mess as these utilities might lead you to believe. Convert To Speakjet All the tools used in Grizzards are in the GitHub repo, but the one that others might find useful particularly is the convert-to-speakjet Perl script. It takes a text file in the form: PhraseLabel: Say something clever DifferentUtterance: Say something different … and converts it into a series of .byte data for the individual phonemes, based on a dictionary file in the format provided in the SpeakJet developers' kits. The output has labels like Speech_PhraseLabel followed by the SpeakJet bytes (ending with $ff as “usual” for the SpeakJet). The dictionary for Grizzards has a couple of thousand words, and it's relatively simple to expand the dictionary file when you find you were missing something. I work that into the Make process and .include the phrase files to keep from having and “copy and paste” dependencies — the object file depends upon the program source, which in turn depends upon the included (generated) phrase source file, which in turn depends upon the original, editable .txt file. But the source it generates is marginally readable and could be copied-and-pasted into your source tree. really If there's interest, I could try to extract that utility into a slightly more stand-alone form, but the script is here and the dictionary file is here. You'd also need to .include the file that maps the SpeakJet constant names to their numerical values, which is here. I think that for dasm you might have to do a “replace all” of := with .equ in that last file? usage: ./convert-to-speakjet InputFileName.txt SpeakJet.dic OutputFileName.s (or .asm if you prefer) Skyline Tool The big Lisp utility monolith probably deserves also to be cleaned up, but it can do nice things like read common file formats and convert them into formats that at least I find useful on various “retro” systems. Nominally, it should compile on any modern OS with Steel Bank Common Lisp (sbcl), but I haven't actually tested it except on Linux. (It would be easy to port to another Lisp compiler, but I think I did a handful of implementation-dependent things.) In Grizzards, it converts PNG images into “big” 48×42px graphics and smaller 16×16px and 8×8px graphics from “sprite sheets.” (Those are in the usual inverted order, with each 8px wide vertical strip broken into its own table.) The only graphics not rendered through it in Grizzards are the backgrounds, although I had always meant to go that way and just never got around to it. It also converts the music from MIDI into a set of TIA register values for NTSC and PAL tunings. It somewhat randomly contains a driver for an old serial-port EPROM programmer that I sometimes was using, although now-a-days I have an el cheapo USB one like everyone else. But it is capable of burning EPROMs on a BP EP-1 on Linux, if anyone else still has one of those. They're probably useful as a doorstop or a murder weapon as well, those things are sturdy. A version of it has lately been learning to read TMX and TSX (and linked PNG) files from Tiled, and RLE compress the tile map portion, to try something new and more complicated for my next “retro” (but not 2600) project.

I didn't notice this list until djpowerplayer's comment brought it up to the top … Grizzards also uses AtariVox both for saving and prattling on quite a lot. (All signposts, all NPC dialog, and combat narration, among other bits.) I've lately noticed that the allocation list got rolled back to an earlier version that omits us (messaged Albert about it) The Demo uses Scratchpad space, but the full game uses dedicated blocks.

Pushed a new daily build (on the web site). I had to stop using SWCHB for flags, which also meant changing the way I clear RAM to avoid losing those flags, and how Pause works because I needed to merge those bits into the same byte. Chaös ensued, and there was much weeping and gnashing of teeth. An 862-line git diff later, and we have a solution. In the new daily build, you can now use any of the 3 supported controller types on either/both of the 2600 and 7800. Button I = Button B = FIRE = the main input button. Button II = Button C = Game Select = usually Stats, but also Select Slot Button III toggles the Pause on and off. (This is similar-but-different to the way the Pause button works on the 7800. If you have a 2600, you can pause with the Color/B&W switch — or right Difficulty Switch on SECAM — and it will sort-of coöperate with the gamepad button, but mixing and matching may be a little weird'ish. Also, the 7800 Pause button doesn't work nicely under UnoCart/PlusCart firmware, because they jam up the ConsoleDetect routine.) Not unexpectedly, I'm sure, ProLine controllers and equivalent will not work on either the '2600 nor the '7800. Note … the daily build is the bottom one, under full-beta-1, in the Downloads box at https://star-hope.org/games/Grizzards/ — I have not put together a “release” yet with the latest changes.

@SmittyB had the solution. I was out of RAM and used the “unused” bits on port SWCHB to indicate if I detected a '7800 (for Pause purposes) or a Genesis/Joy2b+ gamepad. Turns out, even in '2600 mode, the '7800 will “cheerfully” accept those bits to engage the two-button ProLine support, and therefore jam up the Joy2b+ support. I've started a rewrite to pack those flags into actual RAM, but a test with some code commented-out suggests that it should work, once I shake out the fallout from re-arranging RAM at this stage. I think I can now honestly say that the amount of free RAM in this game is 5 bits, give or take a couple of bytes of stack overflow that I allow to happen under semi-controlled circumstances. (Or, looked at another way, the free RAM is a negative 11 bits.)

Well … I guess it confuses the PlusCart, because hitting Reset a second time I see it begin to flash up the word “Copying” before I get sent back to the menu with “emulation exited” Via (original) Harmony, first, I used your SaveKey Editor, and edited block $1040 to contain $10 $40 on the target SaveKey, and did a “non-destructive” copy from my AtariVox, which had only $ff $ff in that block. The Editor confirmed that the data was not overwritten. I also fired up Grizzards from the PlusCart. Where before the SaveKey had slot 1 = BAKU, slots 2 & 3 = unused; now I see slot 1 = BAKU (unaltered), slot 2 = TESTER, and slot 3 = deleted. That means it (correctly) did not copy slot 1 = ZEPHIE from the AtariVox, but did copy TESTER. … Grizzards save games occupy 4 blocks each (max 12 blocks for 3 slots) so that seems to have worked flawlessly. Trying to copy again in overwrite mode: this time, the PlusCart coöperated fine (did not drop back to menu). Confirmed the Grizzards save games now read ZEPHIE and TESTER, confirming the overwrite. Block $1040 now shows $00 $ff $ff … which is a little surprising — I had expected all $ff in that block, so that's a little odd.

Sure, I'll fire it up — possibly tonight? — my SaveKey gets trashed for testing regularly anyway. Just hopefully it doesn't eat my AtariVox

OK, I feel better a little bit. It works fine on the 2600. I'd been testing on my 7800 with the nifty S/Video mod and assuming that it was 100% compatible (with the quirk of the Pause button, of course). It's not … The above code just worked fine on a 4-switch Vader with composite output. The fire button (button I) however “sticks” on the 7800.

Thanks for the assembly version, @Al_Nafuur. That's about what I thought it compiled into … I actually read the joystick once in VBlank.s and then make use of it all over the code, rather than reading it directly (and debouncing it) all over the place. (As you might imagine, there are a lot of different “kernel” loops for the 35-40 different screens in the game.) Ignoring some conditional-compilation bits … the bulk of DetectGenesis.s does a full frame dumping the paddle caps, followed by lda INPT0 bpl NotGenesis lda INPT1 bpl NotGenesis lda SWCHB ora #SWCHBP0Genesis gne DoneGenesis NotGenesis: lda SWCHB and #~SWCHBP0Genesis DoneGenesis: sta SWCHB … where SWCHBP0Genesis is defined as $10, and SWCHB is already configured to allow that as a flag bit. (Yeah, I ran out of places to store things in RAM.) This part seems to have been working all right for quite a while. The relevant part of VBlank.s, without some conditional-assembly noise, now reads as follows on my local branch lda SWCHB and #SWCHBP0Genesis beq NotGenesis tya ; Y = 0 bit INPT0 bmi DoneButtonIII lda #ButtonIII ; $20 DoneButtonIII: bit INPT1 bmi DoneButtonII ora #ButtonII ; $40 DoneButtonII: NotGenesis: ;; A is now either 0 (no Genesis) or possibly some permutation of (ButtonII, ButtonIII) bit INPT4 bmi DoneButtonI ora #ButtonI ; $80 DoneButtonI: ;; A is now a permutation of (ButtonI, ButtonII, ButtonIII) i.e. $00-$e0 sta NewButtons sta Score + 1 ; XXX ldx DebounceButtons ; XXX stx Score + 2 ; XXX cmp DebounceButtons ; buttons down bits are ones here too bne ButtonsChanged ButtonsSame: sty NewButtons ; Y = 0 sty Score ; XXX jmp DoneButtons ButtonsChanged: sta DebounceButtons eor #ButtonI | ButtonII | ButtonIII | 1 sta NewButtons ; buttons down are now 0 bits, $01 indicates new information sta Score ; XXX The rest of the game's code generally just references NewButtons from that point. The write to Score is barely visible as a flicker for only one frame, but it is visually detectable that something happened … except that nothing happens on hardware with a Joy2b+ gamepad button I after the first press. Works fine with CX-40 and (original, 3-button) Genesis controllers and in Stella configured for either of those. Over the week-end I'm fixing to keep beating my head against the above code because it seems entirely responsible for the issue, if I could only think of why or how. I'm sure it's something utterly silly that I'm just not seeing. Any insight is greatly appreciated.

duh. it occurred to me later. Since only the high bit is set, the lower 6 bits are left floating and $0c is the address for INPT4 which was left on the data bus from fetching the operand. I took the liberty of looking into 1942's GitHub repository and I see that it just "peeks" at the joystick register at arbitrary times in the code using the BASIC joy0fire keyword, which translates to a bit INPT4 presumably followed by a bmi/bpl, so I'm just gonna completely rewrite the VBlank routine to use bit in stead of lda / and #$80 and see if it magically makes things better.

Since GitHub is down'ish, I got a minute to try and dump debugging values to the score, and I'm finding: Button I = B = FIRE = $80 is registering once, and then staying "pinned down." Button II = C =$40 is registering only whilst pressed, as is Button III = $20. Weirdly, unplugging the game pad, I see it stay the same, but when I plug it back in, it immediately resets to $00 and stays there until I press button I again, and then stay pinned at $80. (INPT4 seems to be strangely pinned at $0c precisely.) The Genesis pad reacts as expected to both B and C buttons (momentarily whilst pressed). It's gotta be something in my VBlank / input code. Will review that code more later. BtW, thanks @Al_Nafuur the PlusCart has definitely made this development cycle faster!

If I don't find something tonight with the "score debugger" build I'll dig in farther, but generally I've been enabling VBLANK with just bit 2 (enabled) and no other bits (to ground INPT0123 or latch INPT45). I just (before work here) tried a quick test with bit 6 (latch INPT4/5) as well, as in the first example there. With the latch enabled I'm seeing similar behavior as without: Genesis working, but Joy2b+ not registering the buttons properly. I wonder what is the value that bB resets the VBLANK to, and when, but I imagine that will require a dive into the assembly code on the bB engine itself. I'm lying the blame on the VBlank work code for input debouncing being wrong, so I've gutted and rewritten it a bit and am playing with the maths. I'm thinking to hex dump the three bytes: DebounceButtons, current value of buttons in Temp here, and NewButtons (and just disable their actions in the main map screen for now) to see if the values are significantly different than what I get in Stella. The goal is that: if a button is pressed now, but was not pressed last frame, then it should have a 0 bit in NewButtons (at least $80=FIRE/B/I and $40=C/II, and maybe $20=III if it works out conveniently, although I don't really need button III for Grizzards.). That all will have to wait until this evening, though, most likely.

Tried this as well. Strangely, button I acts like button II and button II does nothing. Ditto for the Genesis controller — B acts like C, and C does nothing. Definitely will be trying some visual feedback for the DebounceButtons & NewButtons locations on-hardware tomorrow.

It would definitely seem to be. Button II — the same as button C — is tied to INPT0, button III to INPT1, and I'm simply testing for the high bit to be clear = button down. My button scan routine combines the two buttons into one byte, and seems to be failing to debounce them correctly and “crossing signals.” I'm experimenting to figure out the pattern precisely, but it seems like: Button I works until you press button II, and button II registers as a press once when it goes down and a second time when it comes back up (so the stats screen stays up only as long as you hold it down) … and then … button I doesn't work properly after that. I'm thinking the debounce value is getting corrupted at some point and staying corrupted. I'm fixing to try plugging the score into the button registers or something to try to watch it. The only other one I can lay hands on immediately was 1942, which seemed to work (flip the plane) in a whole 30 seconds of testing. Good thought, I have not been doing so … maybe the pull-ups in the Joy2b+ are just different enough …

I just got a Joy2b+ control pad today, and there seems to be some bugs with handling it properly in the game. I've opened a ticket https://github.com/brpocock/grizzards/issues/422 to track fixing it. I've already eliminated the hardware — Test Cart confirms everything is working properly. I suspect my “debounce” code is somehow at fault, but it works fine on Genesis (MegaDrive) controllers. We shall see …

I had thought that you were sending the start address on every call to LoadSaveKey and maybe the EEPROM could get confused between the address writes. I see now on a closer read that you're only doing the address write every 64 bytes, so that's probably not a concern really. (I do do random reads more-or-less back-to-back without a wait-for-ack.) One thing that's probably completely irrelevant is that the data sheet (p.13, § 8.3) says > Following the final byte transmitted to the master [the console], the master will NOT [emph. orig.] generate an Acknowledge, but will generate a Stop condition. … but the driver code does always send an ack in your i2c_rxbyte[l] routines. My code (which is closely based on the same original) does the same thing, though, without issues. Sorry to not be more helpful. I'll have to look that up now (now that it's “too late for me” I suppose, but I am curious.)

LoL. I was just about to offer to test on hardware but you beat me to it. I did see that the comments in the “left” source seem to be incorrect w.r.t. the longer procedures. eg: if I2C_TXBITL takes 30 cycles rather than 22, then i2c_startreadl is really more like 38/39 cycles. I ran into a problem when trying to do back-to-back writes, and had to inject something to wait for ACK. Looking at the offending code (around ll. 516-539) briefly it looks like you're reading two bytes per operation, (per frame, I think?) and maybe the write of the new start address on each pass is not registering because there's no wait-for-ack after the last stop reading? That seems like a real stretch, though, if that's really a whole frame apart. I'm also a little curious about the `clv` at line 517, as I don't recall ever having to do that.

I'm looking at that as base-32 (5b/ch, 0-9A-X kind of coding), thus 36 chars ⇒ 180 bits of save data. It might be possible to squeeze it a little bit more, but that's already pretty “tight” — it's actually about 27B (216b) of data being represented. I use 6b/ch encoding but the font actually only has around 40 chars, so 32 is the next nice power-of-two. I kinda thought about doing some funky base-36 thing, but that would be a lot of math to scrape off 1-2 chars at the end, max. True … The “free space” is some map areas that are not reachable in the demo, which gives me 618B of ROM. I probably won't re-use it for anything else in the demo, at this point.

Daily build updated … two changes: Bug Fix: The “T” in “LOST MINE” on the road past Mt Peshon was showing up like a Greek Pi instead Enhancement: During a combat encounter, your last selected move will be once again selected when it's your turn again. (I found 2 unused bytes of RAM in the combat mode… one of which is now “LastPlayerCombatMove”) I don't usually post about dailies, but the latter one was something James mentioned on @ZeroPage Homebrew and I was kinda thrilled to find that I do have the RAM to implement it after all. (… and 18 bytes of ROM and 1 byte of RAM left for combat, remarkably.) In other news: It might be possible to fix up the NoSave version to have a very simple password continue feature, but it looks like the password would be something like 36 characters long — 6 × 6. Given that completing the demo takes around an hour or two, is it worthwhile to add a password continue like that? Put another way, would anyone really write down and then re-enter using the joystick a 36-character password for a relatively short game? (For the full game it would have to be more like a 320 character password, so I'm not even pondering pursuing that one.)

Mini-spoilers: This post contains some spoilers about the first 10-20% of the game, most of which are revealed in the demo and in the ZPH broadcast. I've taken some care to hide spoilers about the last 30-50% of the game. For the record, here are the improvements from the previous version. First public release of the "full game." Added interiors to houses in Anchor village Fixed debounce of Pause on '7800 Decimal number displays can show 3-digit numbers now Monsters in title sequence reflect early-game monsters and have correct colors Leveling work on areas from Treble Village (Anchor, Spiral Woods, Tunnel Complex, Lost Mine, Fire Bog) Implemented Left Difficulty Switch on combat Dark caves in Province 0 (Tunnel Complex) Fixed bug in scores > 9,999 Fixed bug in Critical Hits Fixed bug in DrawMonsterGroup showing wrong monsters New Game Plus support Learn moves by general XP (as well as by observing them) Cursor position misaligned in column 3 (of CombatMainScreen) (again) Finish animation for boss (16×16) monsters Fixed colorization of all monsters HMOVE errors on CombatMainScreen Completed the bestiary assigned correct Moves to all Monsters assigned monsters to areas by Tier monsters assigned to Port Lion monsters assigned to Lost Mine monsters partially assigned to (secret area last ⅓ of the game) Grizzards art and colors finalized Updated manual with monster art Added Radish Goblin and Turnip Goblin by Zephyi General rewrite of the manual for terseness Colorized all monsters (line-by-line colors) Compressed dialogue ROM usage in “speech” banks Music added for Port Lion Metamorphosēs assigned for those Grizzards which can do so Final music for first area (Treble, Anchor, et al) Fixed sprites refusing to exist “spawning” (“poof of smoke”) mode Scanline error on “Your Grizzard is Killed” going to “Game Over” (end bosses before the final boss) names were not spoken aloud (said “monster”) Starts should evolve at least once before traveling to Port Lion under normal game play (if you stick with them) Per-line coloring (highlighting) for Grizzards Sprites were teleporting on screens with no random-placement spawns Intermittent scanline count error on Run Away No “chirp” moving to/from Aquax in Grizzard Chooser (new game) Show number of Grizzards caught in “you won” screen Waterline animations (Port Lion beaches south/north) Music encoder now chooses best AUDC voice for fidelity Map screen instability (scanline count) on SECAM AtariVox goes “blip” on AtariAge/initials screen (still can occur) Glitch at bottom of Airex screen (title / Grizzard Chooser) Added missing / updated existing screenshots in manual Make saving more obvious in manual Fix on finding a mirror Assigned “reasonable” point scores to all monsters Full health bar was missing part of top scanline Ball (as a wall) extended above the map area a scanline or two “Cut scene” animation for the entrance to the area after Port Lion Display Grizzard “ID numbers” in the Depot Hint on how to navigate the Lost Mine Monsters materializing in walls Pronunciation of “Cure/Sure” sounded like “kooyer/shooyer” Scanline counts: CombatMainScreen Dirtex moves were too weak Weaseling past monsters could get stuck in wall near Lost Mine NoSave: When catching a Grizzard, its stats will be boosted to at least those of your previous (current) Grizzard New combat core logic Increased height of HP bar Announce Critical Hits on kills When a Grizzard metamorphoses the old form would stay selected (with 0 max HP) if you died before saving Support for multi-color monsters in all forms (small, large/boss, extra large/final boss) And, the following are (most of) the differences between the NoSave and Demo versions and the full game. Almost all of these are due to space constraints. Demo has only part of the world, from Treble to the Tunnel Complex, excluding the Lost Mine and Sprial Woods. Some NPC and other interactions are cut (eg. one of the guys on the very first screen) Once you open the tunnels to Anchor, there is no further progress possible. (The tunnels don't actually “open,” it just tells you you've finished the demo.) NoSave: Can't save. Only Aquax is available as a starter. Limited title sequence and no Grizzard Chooser as a result. Entering your name is a bit jankier. Works on (original, non-Encore) Harmony cartridge Demo saves to “scratchpad” area of AtariVox/SaveKey memory, and may be overwritten by other demos or test programs. Demo save games are not transferable to the full game. (slightly different “file” format) No potions No confirmation when erasing a saved game slot No ability to “un-erase” a saved game slot When a Grizzard metamorphoses, it says “CAUGHT (new Grizzard)” rather than “(old Grizzard) BECAME (new Grizzard)” Monsters appear in monochrome “Boss” monsters are just upscaled version of the regular (8×8px) monster graphics. (In the full game, bosses have distinct 16×16px graphics, and the final boss has a distinct 48×42px animation set.)

Tonight @ZeroPage Homebrew has premiered the beta version of the full game of Grizzards. Thanks to all the ZPH crew for their time! And thanks to everyone in the forums who have been so supportive and helpful. The new version of the web site should also be live now, but here's what you really wanted: new binaries! and new manuals to go with them. Let's also thank @Prizrak who has been doing an amazing job uploading these ROM files to the PlusCart PlusStore. I'm sure they'll have the latest binaries in the PlusStore in no time. (EDIT: They are!) Just for the PlusStore there's also this super-brief manual: Grizzards.Manual.txt There are a tonne of binaries here, so here's the break-down: If you only have a Flashback Portable, you want the Portable version. The game is “playable” but full-screen text (eg NPC interactions) and "high res" bitmaps (eg title screen) are still garbled. If there's interest I will try to sort those things out. Grizzards.Portable.NTSC.bin (refer to the NTSC NoSave manual in the next section for now) If you do not have a SaveKey nor AtariVox, you want the NoSave demo version Grizzards.NoSave.NTSC.full-beta-1.a26 Grizzards.NoSave.NTSC.full-beta-1.pdf Grizzards.NoSave.PAL.full-beta-1.a26 Grizzards.NoSave.PAL.full-beta-1.pdf Grizzards.NoSave.SECAM.full-beta-1.a26 Grizzards.NoSave.SECAM.full-beta-1.pdf If you have a SaveKey or AtariVox, but just want the demo, or you want to use a non-Encore (original) Harmony cartridge (limited to 32kiB ROMs), you want the Demo version. Grizzards.Demo.NTSC.full-beta-1.a26 Grizzards.Demo.NTSC.full-beta-1.pdf Grizzards.Demo.PAL.full-beta-1.a26 Grizzards.Demo.PAL.full-beta-1.pdf Grizzards.Demo.SECAM.full-beta-1.a26 Grizzards.Demo.SECAM.full-beta-1.pdf If you have a SaveKey or AtariVox, and use a Harmony Encore, an UnoCart, or a PlusCart (and you want to upload it yourself), you want the full game without “NoSave” or “Demo” in the name. This will also work on Stella and I expect it should work with the Krokodile Cart but I no longer have a way to upload ROMs to mine. Note that if you use Gopher you have to specify -savekey on the command-line (and I have not tested in Gopher). Grizzards.NTSC.full-beta-1.a26 Grizzards.NTSC.full-beta-1.pdf Grizzards.PAL.full-beta-1.a26 Grizzards.PAL.full-beta-1.pdf Grizzards.SECAM.full-beta-1.a26 Grizzards.SECAM.full-beta-1.pdf For each ROM, there's a matching manual. The contents do differ depending on your version, so make sure you grab the manual that matches your ROM. Have fun all!

In hindsight, I may have had the Difficulty Switch on A and tried it as a "wild guess" which I think is not allowed in that mode? TBH I didn't diagnose it deeply and just guessed something else to move it along. I'm using “interpolation” very broadly there … the TV upscaler has some kind of AI routines that try to smoothe the video and may have decided that the RF lines alternating were meant to be mixed, or something. EG: In Grizzards when two of the same monster sprite get within ±10px of one another a third "phantom" sprite appears between them (although that's flicker there). IE: LG is sometimes too “smart” for its own good. It only occurred with RF out, and I think it only happens when I use the TV's own tuner. For my own video capture I use a nice “dumb” tuner and the RetroTink to avoid those artifacts but I didn't have the tuner handy last night. (The ticking noise is a complete surprise to me and I have not seen that before. It was around 1-2 ticks per second.)

Short answer: I did not see any answers flash up, or letters colored incorrectly, having played a couple of rounds in each of the six configurations below. I “skimmed” the ZPH show from yesterday, as Twitch issues kept me from watching live and I haven't sat down to the full thing yet. I happen to have broken my Uno Cart (the little dust cover spikey bit!) so I can only test with Encore and Plus at the moment. Tested with the same ROM (2600words-9-NTSC.bin) and same AtariVox+ on each system NTSC 7800 with S/Video mod through RetroTink 5x Pro and Harmony Encore … OK " with PlusCart … OK That's currently my “normal” rig for testing, but I happen to have all 3 of my Ataris out for testing and recording, so I can quickly lay hands upon and plug in … NTSC vader with composite mod + RetroTink + Encore … OK, except not allowing me to guess “ELBOW” for some reason. " with PlusCart … probably my rig, but I noticed a rhythmic glitching in the video accompanied by a faint ticking noise from my AtariVox+ speakers. Otherwise, OK NTSC woody 4-switch, RF out + Encore — direct connection, no RetroTInk … color was VERY desaturated, more than usual for this set-up, and only on the game screen (not the title screen). But no real bugs visible. " with PlusCart … still a bit desaturated, but otherwise OK still. The desaturation might be because of our TV's upscaler trying to interpolate the “Venetian blinds.” It does the same thing to the Harmony cart menu (but not the PlusCart's menu).

I got completely disconnected a few times and then gave up The Twitch in-browser feature kept giving me a big red button labeled something like "reload viewer" (edit: I usually watch on TV with the browser just open for chat, but did not last night, so I don't know if the FireTV Twitch app would have worked better…)