TailChao

Time to finish buffing my libraries for the 3DO, CD-i, and Watara SuperVision then. There's two components that'd have to be supported in order to run Rikki & Vikki 1:1 on SainT's 7800 GD (or any other flash cartridge) : SOUPER (mapper) and the BupChip (audio expansion). I've encouraged adding at least the former to help other developers use it in their software, as right now the only option is to ask for one of our surplus prototype boards. This is fairly low effort (the mapper is simple) and would at least allow you to run the game without sound. Excluding the latter is totally understandable as it's an entire microcontroller and support circuitry. At least from what I remember of the Twitter threads (when the 7800 GD was still the 7800 SD), there was some chatter of including new audio options outside of just Pokey along with another new mapper. So plenty of choices if you're not interested in designing your own hardware.

Hahaha, thanks. I wanted to ditch these but was paranoid there'd be some obscure 7800 variant which had a latching dust cover like the 2600. The "teeth" near the card edge are used to open these latches, which necessitates both holes in the label side plastics (so they can be ejected from the injection mold). The only other option was to have a spring mechanism like Atari's older cartridge design - which was out of our price point. This is very appreciated, and I think we'll be able to do a much better game next time based upon the feedback we received on this one. One promise I will definitely keep is that there will always be an "alternate" way to play if the software targets a dinosaur, akin to how Rikki & Vikki is also available on Windows.

Thanks I've gotten a few requests to cover how the game's visual effects work, and want to do a series of writeups regarding these and how the draw optimizations are implemented. But for now I've given this product enough of my time for essentially negative returns and would like to focus on other things.

Nice to see this is still being worked on, curious to see how you'll stylize the in-game content In the second intro screen ("THE SURFACE OF MARS...") - you might be able to get a little more impact with the parallax mountains by darkening the color of the ones further back, then nudging the closer ones upward to slightly overlap with them. Just the peaks would be enough (and wouldn't eat too much bandwidth).

...and this feature has been added for all file filters. ...and this one is on the way. I've also added an alternate BupSystem BIOS to the todo list, a functionally equivalent but non copyright infringing version of the 7800 BIOS which can be bundled with the emulator. Not sure if this will make it in 0.9.6.2, but it's a convenience I'd like to have. Addendum : Should we have pinned topics for both A7800 and BupSystem's development status in here? This would also help nudge users towards which emulators are actually being supported (and away from ProSystem).

Yeah, it depends upon what you're drawing. I think it's easier to understand Maria's functionality in terms of a framebuffer system (albeit without the framebuffer) rather than in terms of sprites and tiles. All she does is parse draw commands and copy texture data into a linebuffer - you can even consider the low and high address bytes as UV coordinates in a giant texture which is all of memory. If you draw a large quantity of small objects this will reduce your fillrate since Maria is spending most of her time parsing commands. So to prevent tearing and keep your fillrate up it's best to batch draws together whenever possible and avoid the use of the indirect modes. This is somewhat similar to the Jaguar's Object Processor. Ideal use of 160A or 320A would probably get around a 2.5x horizontal fillrate, 160B or 320B around 1.25x. But at that level of saturation you've also burned most of the available CPU cycles.

Hah, I think they've toured most of France by now. It's cool to see the co-op mode demoed around the world. Thanks, it's sincerely appreciated.

There's 125 units left.

From experience working with this chip family - it's easy (and relatively performant) to interleave processing channel data within the worst case write delay time for each channel rather than polling each flush. But in any case you're going to lose a good amount of cycles handling audio updates, there's a reason most arcade boards dedicated a CPU for this task. The overhead won't be bad enough that it's impossible to run anything, but it's still significantly more than none.

Since I was unable to find a donor cartridge slot (and would likely have destroyed it anyway), here's a - uh... alternate solution. I put two 2.54mm headers where the cartridge slot was located then made modules which attach to them. This way my test boards connect to the headers rather than requiring a beveled card edge, as another plus it's easier to hang logic analyzer probes off the thing. For running normal cartridges we have this monstrosity... The slot is an AMP / TE Connectivity's 5530843-3 (Mouser #571-5530843-3), it's not as tall as the original slot but the pin spacing is identical. So if you're trying to fashion a 7800 Cartridge Programmer this is a good pick.

Most seem to have been found, or at least the in-game ones which are tied to Steam Achievements.

This is definitely on the todo list (and I'll add it to the first post), but I'm not sure it'll make it into the next release. I'd rather go fully custom here, since visible overscan is highly dependent upon which sort of display you're using and how it's calibrated. For example, Atari's recommended 192-line safe area is very accurate to what my old Sharp Linytron displays - but I can see nearly 240 lines on my Sony PVM. It'll eventually go into an "Advanced..." configuration section. Since a short cartridge history is already part of 0.9.6.2 - a type history would also be appropriate. I'll try to add the latter behavior where BupSystem will remember your last type of file used. In the meantime, you can already load a cartridge by dragging and dropping its file onto BupSystem's window - and this doesn't require any extension scoping. As a reminder, new versions will take some time since I'm not exclusively working with the 7800 anymore. But I did finally repair the console I use for development. I'd like to at least release a new version before the end of this year with minor polishing and a draft implementation of my new mapper design.

After we've sold all 550 I'd like to manufacture more copies as long as there's demand. This is outlined in the first post, but essentially I'd like for the game to be available for purchase as long as there's interest in playing it. I just can't guarantee that will happen soon, especially considering the game was not commercially successful. Because the whole package (box, manual, feelies, plastics, and board) are designed for bulk production (i.e. we can't just make one or two copies, it has to be in the hundreds) the whole loose cartridge thing isn't really feasible.

Nah, more like "I'm ready for all this junk to be out of my house" ...starring Misery.

Heads up for anyone still on the fence about ordering a copy, we're down to 138 units in stock.

Only very early on, long before the 7800 was even chosen as the target platform. I eventually decided against it for clarity. You've got two players characters and enemies, all of whom can pick up solid objects and mess with the stage geometry. Even with split screen, there'd be too much risk for an enemy flipping a switch or some other element offscreen and the players not catching it. So everything was made single screen and the vertical wrapping added to allow layouts to be denser.

This was the idea, yeah. I'd love to try stylizing for 320A if we were to do another game for the 7800. We had one for internal use by the team... ...but this will not be publicly released. The stages require large amounts of manual tagging in order to operate properly. Getting map data into builds is also a little complicated, since stage scripts are allowed to instantiate basically any object, set or clear any flags, or call arbitrary code. If you'd like a puzzle game with built-in editor, give Penguin Land on the Sega Master System a try. I don't recall promising this. My stance has been consistent since the game was announced - if the sales are good enough we'll do another game, but it's unlikely to be a sequel to Rikki & Vikki.

Hooray 2020! Despite the new decade, Rikki & Vikki is still on for 90% off until January 2. Two players for one dollar. The MMC3 doesn't add many new graphical enhancements outside of more addressable memory, but the MMC5 definitely gives a helpful nudge. Not quite We gave Maria and Sally separate paging, but it's infeasible for both of them to operate simultaneously. One way to think of it is that the cartridge is a book which can be read by either Maria or Sally. The existing mappers only allowed one bookmark to be placed at a time. We added a second bookmark for Maria so there's less requirements for each chip to accommodate the other's needs. I'd like to think we got the 7800 vs NES vs CD-i comparisons taken care of around twenty pages back - but do want to point out the "simultaneous" aspect is extremely important. On the NES, the PPU operates independently of the CPU and can fetch data while the CPU processes game logic. The 7800 only allows one of them to operate at a time - so the performance is significantly reduced right out of the gate. Not that I don't appreciate the complements (I do) - but there seems to be a belief here that the MMCs are the equivalent of bolting an aircraft's engine onto a vespa when this is absolutely not the case. The NES and 7800 have very different design priorities, which is fine - they both exist and you can pick whichever you like. But one isn't universally able to trounce the other, even in their stock configurations. Thanks! We've been getting a lot of feedback from customers who bought a 7800 just to play the game, or tried it on Windows and wanted to get the hardware experience afterward. It's pretty wild.

Not quite. The MMC3's design is fairly simple and I wouldn't consider what it adds madness - that's more MMC5. But it still has a few features I would have liked (proper raster counter, better subdivision of textures, bla bla bla). Much of the sorcery in the above screenshots is accomplished through skilled software and graphic design by the developers rather than some magic chip in the cartridge. Keep in mind games like Battletoads or the more recent Micro Mages use a very primitive or absolutely no mapper, respectively. I think we managed to get okay movement in Rikki & Vikki (i.e. the animation has good weight), and there's far more that could be done with the hardware. But I wouldn't consider it up to snuff with any of the 16-Bit'sters with the amount of fuss required on the developer's behalf to get there. It'd have to be stylized very heavily and what caters well to Maria's strengths is completely different than any of the 7800's contemporaries.

Thanks everyone for the feedback. Oh, hey - it's now been a year since the game's release! You're 100% correct on this. The game's score was all @RushJet1 , but yes - I fully support moving away from Pokey. Regarding the mapper and audio expansion, they were both released for use by other developers along with an emulator which supports them (and has more tidbits in its help file). The big jump over existing designs is a cleaner separation between Sally and Maria's view of the cartridge address space , but we're not even up to MMC3 class here. Plenty more that could be added to give the hardware a further boost. Noted

You're welcome to make whatever content you like. Of course, I'm quite flattered that it's about something I did. The only thing I'd caution about is making assumptions regarding the game's development process - especially with changes or what is considered unused. We had nearly zero public facing content until two weeks before launch, and while I did dump some of my design notes on Twitter they don't reflect what was actually going on behind the scenes. I kept archive of every major build and all the test footage back to the first time the game was running on the hardware in early 2015. Most of these I cannot give out, but I was planning on releasing select prototype footage at a later date (prefix "later" with one or more "much"es). If you have specific questions on anything (i.e. "the stage in this photo didn't appear in the final game, what happened?" or "why is Direct Dutposit offered after two game overs rather than at the start?") - I'm always happy to answer these over DM, it may just take some time. This goes for anyone. That's really the biggest constraint for me, and I've gone through the loop of "we'd like to do an interview, are you interested?" - replying "yes" and that's the extent of it around six times in the last year. So right now I can only guarantee answers to clear questions, not much else.

Regarding cooperative play, I'd not actually recommend Rikki & Vikki as an introductory experience to this. Something like World of Illusion on the Genesis offers a much more relaxed difficulty but still mandates that both players work together to solve problems, one can't drag the other through the whole game. Any of 8bitdo's products come highly recommended, and most include mapping profiles in Rikki & Vikki's Windows version - M30 included.

That is very strange, it almost looks like the television is losing sync. The checksum only verifies the integrity of the flash, it's possible the mapper or some other component could have been damaged in transit. Some thoughts... You just purchased this 7800, right - has it been refurbished (new electrolytic capacitors, voltage regulator, etc.)? It looks like you're connected to the television using RF or Composite - has the 7800 been modified for any other video output and (if so) do the same issues appear when using these? As of writing, Rikki & Vikki is the only title which uses the HALTn pin to discern between code and graphic fetches. If this pin has a poor contact it can cause instability or graphic corruption in this game and no other. This might be something as simple as a dirty cartridge slot. Are you able to start the game (i.e. enter the menu and start playing) despite the issues? If the issue persists send an email to the support address to arrange a replacement, refund, or further investigation.

That's a reasonable staff for that era, Sonic the Hedgehog had a team of seven - you didn't start to see larger teams until the multimedia craze really took off. But if we're comparing titles like this to low budget / independent games developed now, it can't be done just by team size. These guys were working full time with a stable salary and project schedule. You'll get a much higher (and I'd argue more predictable) output this way even though development back then was more difficult. Also, Gimmick was a late release (1992) - by that point Sunsoft had been working with the hardware for a significant amount of time and could probably leverage existing resources, tools, or whatever from their previous titles. Like, Ufouria just came out the year prior.

This was a gag rooted in light truth, yes. From my experience getting good weight in the character movement and gratifying interactions between objects are the most difficult parts of working with limited hardware, primarily because of the limited space and cycles. What feels right does not always correspond to what's correct, and you need to manually key all of it. Games like Super Mario Bros. 3 or Kirby's Adventure are absolutely stellar in this respect, and it this sort of feel becomes much easier with the resources available in 16-Bit platforms.