TailChao

No offense, as I do appreciate the continued enthusiasm - but I'm not interested. There are other things right now which are more important to me than an old Atari console. Furthermore - YouTube, Patreon, and Kickstater are not funding panaceas. If you'd like to support the 7800, please support the other developers still working on it. I made my offer and it was declined long ago. Sure, and I agree with this outlook. I brought it up moreso as it's another (fully tested and documented) method of adding an easy to use audio expansion to older hardware, which could even be adapted to a certain Atari wedge.

If we rewind towards launch times, I was looking into this minus the Physical Support Cube Box Type Objects since there's a few people in my area who design plushes. But, eh... maybe for the next thing, whenever that happens. Sure, I want that too. But if it was going to happen it already would have.

Again, the compliments and enthusiasm are sincerely appreciated - but an EverCade version isn't happening. The Nintendo Switch was a far better candidate, but the Windows version's sales couldn't fund it - doing a high quality port is not a Drag 'n Drop. I cannot justify any further investment in Rikki & Vikki or the 7800 at this time.

Haha, no worries - they still look fantastic!

The teeth are used to open the dust cover on the 2600's cartridge slot rather than for orientation. If you're only going to use the shells for 7800 cartridges they can probably be removed, at least until some weird hardware variant turns up in a basement or dumpster that has a dust door. So one perk is these shells can also be used for 2600 games. Ah, but now I'm curious about the Jaguar molds - are these going to be faithful to the originals or are you going for something new like the Jaguar GameDrive's shell which removes the silly handle?

For the NES there's GTROM + GTMP3, but (off the top of my head) this isn't supported by flash cartridges yet. There was some discussion of adding a new audio expansion variant to the 7800GD (not just POKEY), but that's for the future. When we designed the SOUPER + BupChip setup it was intended to simplify migration from Atari's stock mapper and dropping in audio tracks, although this requires more effort than a folder of MP3s. Most of the challenge here is tied to how the audio expansion is implemented and whether it's easy to hook into the existing software.

So this'll be added next toad break, right? Right?

Nice work, looks like you got the original texture down as well. Only thing I'm not too keen on is the screw still residing under the game label, but it's great to have more options for fresh plastics.

The registers are yielding data, but if you look closely the reads appear to be shifted one fetch late - so it's still taking awhile for the RIOT to catch up to Maria's strobes. Although I wouldn't have expected this to work at all from the datasheet. It's quite possible PHI2 aligns closely enough to Maria's fetches for the RIOT to latch some of the addresses, or the actual silicon isn't doing exactly what the manual says. Agreed, but if any strange behavior gets (or was) reported - that's data. The manual also states it was moved off the zeropage "...because of speed discrepancy with the 6532..." which, along with the all caps DON'T USE text, felt very much like "here be dragons". I am curious though, have all these tests been with Maria enabled / MEN (INPTCTRL,1) set? RIOT shouldn't give any fuss with Maria's features disabled, since that is 2600 compatibility mode and should use safe timings.

Only one way to find out! This is where you really have to be careful in designing a mapper or bus arbiter or whatever. I'm curious as to what's going on with Maria's chipselect signals here as she's the one enabling RIOT and any stuttering while she's capturing the bus could gunk up a pending write. The timing requirements for accessing the R and IOT portions of RIOT might differ, too. On the note of designing cartridges, we observed a lot of variance in PHI2 integrity from unit to unit - especially on the PAL boards. Some were extremely sensitive to how the signal was routed, which is why Rikki & Vikki's PCB has a nice thick trace which runs directly to the mapper and that's it. It's not always fun, but was left in our hidden Maria Diagnostic feature for easy access... ...here the RIOT's RAM is pretty dead, with a bit of gunk on the start of every 64px segment from Maria parsing DLs elsewhere - but the IO and Timer are still readable this far out of spec. Yeah, I've observed similar - and if there were any timer stability issues they would have manifested in Beef Drop since it uses them. In any case I'd recommend sticking with only the IO of RIOT's feature set for 7800 software... unless the point of said software is reverse engineering

I'm not entirely surprised by this, as components from this era aren't always tolerant of having their clock changed. If you're going for completeness, it might be worth investigating if different manufacturer's implementations exhibit different behaviors. But yeah, in this case the manual's warning is correct - RIOT's RAM isn't stable. Once you do enable DMA - Maria's fetches aren't PHI2 aligned which is definitely out of RIOT's spec. Having Maria read graphic data from RIOT's SRAM gets your some pretty chaotic textures.

Hey, thanks! We're down to the last 50 copies now. Despite what happened with Rikki & Vikki I'm still convinced this is feasible. Not by moving cartridges, rather by developing a game with wide enough appeal to net significant digital sales. But 7800 or not, that part is never easy!

It's a combination of porting BupSystem's core and the desire to add quality of life features expected by console owners, particularly the latter. New in-game menu system, support for multiple save slots, rad video filters, yadda yadda - little things that make the package more than just an emulator and binary tossed together. It's already an investment to move the software over so I rather we'd put the effort in or not pursue it at all. Yeah, it would have been digital only unless the original launch was wildly successful. While it can be argued a bling box release for the Switch would net more eyes on the product - we didn't have the funds or the demand to justify it at the time. I apologize for constantly harping on it, but we couldn't run the studio for free and there was little interest from outside in supporting a product which didn't garner much attention - we tried, too. No worries, I was aware of the risks going into this - and thanks for the support

We've received a few (and I mean few - as in three) requests for an Evercade version, and I don't think it makes sense for Rikki & Vikki. As of writing there's no functional two player features on the Evercade, which saws off about half the game's content. It'd also require an investment comparable to bringing the software over to any other modern platform. If we were to do another version I'd rather it be for the Nintendo Switch - that's a much better fit. Aside from shipping out the last handful of cartridges and occasional maintenance of the Steam version, I have moved on to other projects. Rikki & Vikki had its chance over a year and a half ago and I see no reason to continue pushing it.

Hey, no problem. Thanks for giving it a try! Sure, but we're not the first to do so - generally or on the 7800. The only thing in this category I'd classify as a "smash-hit" is Morphcat's Micro Mages - which was both well received and able to net fairly good sales, it's a great product. Sort of. When I say the goal was "to make a good game which happens to be on the 7800" it was moreso that players can still enjoy the game without any hardware nostalgia. So the cases like yours where someone found out the game was actually written for some electric dinosaur after playing the Steam version are really cool. That was the point I wanted to make. But if you also enjoy the game because it's running on an Atari wedge - that's great! Mostly I cared that people gave it a try and responded with honest feedback. I think the biggest issue wasn't how the game was covered, moreso that it just wasn't covered sufficiently. If you're targeting something more popular like the NES, SNES, or Genesis - it's not trivial to get good cartridge sales, but it's much easier because of the larger userbase. Promotion is similar. With the 7800 there's basically zero chance of the cartridge sales recovering your budget or paying for another game. You can eventually make back the cost of designing and manufacturing the plastics, boards, yadda yadda - but not the software. So it's not just that I wanted digital sales, but we were entirely dependent upon moving units through Steam and Humble Bundle during the first six months to do, say, a Switch port or fund another project. My expectations for profit were actually quite low - the mechanics and content are unique, but not super accessible. So even if Rikki & Vikki was Windows or Switch exclusive I was expecting more of a niche response. But yeah, what we got was far below that. Where I wanted to go with this was doing more releases for older hardware - but always with an alternate version for modern platforms, and always on a schedule. So a CD-i game? Yeah, let's do it! Jaguar? Why not! Then allocate some of the development time for reverse engineering, designing new hardware, and releasing all this for free. We would eventually have to transition purely to modern platforms, but I thought this was a good deal. If you're not interested in the game content, the cash is still going towards something useful and the digital versions would be pretty cheap. Basically, I don't mean to be overly depressive with the "abloobloobloo, no revenue" shtick - rather to be clear. There's a lot of noise over developers creating solely out of love of the medium rather than for profit or whatever, and that's fine - but that doesn't scale or follow a schedule well. When we're discussing the success of a project, it needs to be both in terms of player response and sales. Because these are the metrics, especially the latter, that net you another game from the same staff in two years rather than ten or never. I don't intended for this reality to take away from your enjoyment of the game, they're separate things. You're allowed to really enjoy a product which was not financially successful. My gold standard for "new software on old hardware" is still M2's Fantasy Zone II DX - which set an unbelievably high bar and gets very little recognition for it. I'm really happy it exists. But it didn't sell well, so I don't expect another one.

I'd word it moreso that the game was able to attract players to the hardware who previously wouldn't have been interested in it - a smash hit implies there's a significant number of copies moved and widespread awareness of the product. We didn't really get either, so it was more a firm press of the index finger against the snout. It's a bit cyclic at this point, but I feel the repetition is warranted - when you're doing development full time the requirements both for schedule and sales are extremely strict. We did not need crazy numbers to do another project right off the bat (and not even necessarily on the same hardware), but we needed far more than we got. Yeah, it's a pretty good doorstop that can also play Ballblazer and Joust. I don't own a boat that needs to be anchored, so it was already a big improvement in practicality over the 5200.

As I type this, 59.

If you're creating labels to access this data, then yes - ORG and RORG or ALIGN it. Don't forget you can do math in the ORG and RORG directives to make this a little cleaner, something like ORG (ADDR_CD_STG2 + SS_A). Yeah, RORG is creating the logical addresses for your resources and ORG is generating the physical addresses in ROM (or other storage).

Sure - and I've got the impression there was a lot of hesitation to develop anything new. Especially from how long the Atari 800's chipset went without any significant changes. Yamaha's YM series were still very expensive at the time and required an external DAC, so while it'd be fantastic to toss one in it'd also bump the unit cost. I wasn't there, so I don't want to say with any sort of certainty what would have been feasible. But in the spirit of how the hardware was designed, I think shipping with only the TIA was fine - with an asterisk that a new audio chip for cartridges should have been available from the get-go rather than later. Luckily while we didn't get it then, we can add it now. It'd be a tight fit with the current layout, but it's still physically possible. However - my reasons for favoring a newly designed audio core have more to do with long term cost, capability, and getting rid of some quirks that a stock Pokey has when used in the 7800. If you're going to manufacture millions of a chip - then sawing off unnecessary features or reducing the package size will drop the cost a teeny tiny bit per unit, scale does the rest. The 6507 is a great example of this. There's a tradeoff between setup cost and the number of chips you're going to need, and since we never moved beyond a full sized Pokey in two cartridges - Atari's opinion on the matter was pretty clear. The thing I can't speak for how much silicon work could have been done, and how cramped the dies are. If there was enough real-estate available on Maria she could have been repinned and given a small audio generator. This may have been the best route since no other components would have to be changed, and it wouldn't add another chip to the board which requires more routing and mapping. If we're assuming more time to rework silicon - then by all means buff what's in the TIA and tie the new features to whenever 7800 mode is enabled. Ah, the PHI2 clock skew is another irritant - I brought this up during the last audio expansion discussion (or maybe it was the last one before...) but it's still kinda frustrating. Pokey is designed to be clocked entirely off PHI2, and this will skew in the 7800 whenever Sally accesses the TIA or RIOT. While most software has very brief interactions with either chip in the slow access club (and most Pokey cartridges sound fine), it's pretty rude to have an audio generator which can drift out of tune just by banging a register. Using one of the stable clocks (i.e. 3.58MHz or 7.16MHz) to run the channels is vastly preferred here. Again, this is all just architectural handwaving - and the hardware as-is feels fine considering backwards compatibility with VCS software was a prominent feature. But including another denizen in each wedge should require it coalesce well with everything else. Pretty much, yeah...

Woof! It's been awhile, let's get caught up here... First off, thanks for promoting the game during the Steam Sale - it's sincerely appreciated. We're also down to the last 62 copies of the 7800 version. Aaahhh - this is perfect! When we were putting the game through focus testing a few players were running it though Wine on Macintoshes. If I remember right... it worked outside of a few features like gamepad automapping. So probably maybe yes. If the former doesn't work, get a box of the latter and consume it until the game appears to run correctly. This procedure has been tested exclusively with Franzia but will probably work with other brands, too. Thanks, glad to hear you're enjoying it! If you have time, please leave a review - even if you change your mind and it's bad! It helps us deal with Valve's algorithms significantly.

I've been seeing this recommendation come up for years, either to drop in a Pokey or merge it with another chip, and it's very odd to me. Not because of some personal vendetta against Pokey, but from an engineering standpoint it makes no sense. You wouldn't want to drop a Pokey in as-is since the keyboard features are extraneous and it's a honkin' 40-pins and takes up board real-estate. If you're going to add an audio generator to either the TIA or Maria - why copy Pokey's design as-is with all those limitations? You could have something which follows the same principles but is vastly improved (i.e. Mikey). Now that we're seeing the use of FPGA or CPLD Pokeys in cartridges, why not go for a Pokey Plus outside of arbitrary authenticity points? Hmm... In the end, "which sound chip is best sound chip" is a religious argument and we should all probably be banned.

Nah, nah - I'm working on some things but can't make any promises if or when they'll happen. Yes, but these were usually Quad Pokeys - four times the Pokey for four times the channels! I'm of the opinion that the NES is more in line with what you'd want for 1983 - 1984. There's good waveform diversity, the dividers are accurate enough to hit most notes without the need for paired channels, and it can stream DPCM. Consumer device wise it's a pretty big step over everything but the SID. But it's also not made by Atari, and eh... Instead we got the alternate timeline, where it shipped in 1984 and the 7800-CED upgrade followed in late 1985. Wait...

You could also just clock the ARM very slowly to peg its performance. Personally I draw the line at moving nearly all the game logic onto the coprocessor - at that point it's time to move to the next generation of console hardware. If you have a fast ARM (or DSP) that's just helping with math or rendering with Sally still running the show, that's cool. But in the end I'd rather have more games than not. That's more important than hitting some authenticity metric. Yeah, they did a fantastic job on both the SuperFX and the software using it. Hmm, I think it goes like this... Coprocessor Works in tandem with whatever is already in the console. Sound Chip Makes extravagant new noises which were previously difficult or impossible to generate on the stock hardware like "hhhh", "bbbb", and "gwaghgh". Expansion Pack Required to play Majora's Mask. Certain third party Expansion Packs may release a faint aroma of burning plastic after extended use. Video Passthrough Uses the console for controller input and audio/video output exclusively. Upgrade Module Vastly increases the console's girth and may require one or more additional wall warts. Known to horribly fragment your userbase and are commonly mushroom shaped. Miracle Piano The future of gaming. New System Atari Jaguar. Pretty much, and while what shipped has limitations - it's a well thought out architecture.

It's not so much that we made little on the 7800 release - the cartridge sales have been fine relative to the popularity of the console. Moreso we were dependent upon digital sales to recoup the cost of the game software and fund further development, and in that area we fell flat. I do feel there is an outlook here that designing exotic cartridge hardware is some strange voodoo magic, it is not. While I worked as a hardware designer professionally, most of these skills are self taught and I'd like to encourage more developers to learn them. Or if they don't want to - don't hesitate to reach outside the community here to those who can help. I'm confident in @SainT's efforts and believe that while his 7800GD might not be available tomorrow, it will be a significant plus whenever it arrives. Regarding whether developing new mappers and enhancements is a dead end, I hope not - because that's not where the difficulty lies here. A skilled hardware designer can draft a mapper and design a prototype in a few work days. What's expensive is developing the software to utilize this - which is enormously challenging if you want to match the scope of what the better studios were doing in the early 1990s, or what the more successful independent developers are achieving now. It doesn't matter if you're working in DASM and Notepad for the 7800 or using Game Maker for Windows, creating new and original content is the most time consuming step. It's also extremely risky, but that's kind of the idea. I decided to go through with Rikki & Vikki because the unique mechanics and way everything in the game is arranged meant something to me. We developed the new hardware because it would strengthen that, not to run arbitrary technical rings around the existing library. The point was to make a good game that happened to be on the Atari 7800, not a good Atari 7800 game. We also shipped that over a year and a half ago with no preorders or crowdfunding and (at least I hope) relatively little fuss for customers. Whether or not the game is everyone's cup of tea isn't the point. What I wanted to stress was that we could reliably bring you more software on a schedule, would invest in reverse engineering and hardware development that would be given back to the community, and were really listening to feedback. In particular, after the repeated drama with Watermelon's Paprium on the Genesis. The difficulties we had with coverage and vast indifference by most retrogaming communities did more to indicate this relationship isn't worth pursuing than any number of cartridge sales. It depends upon what you consider assistance, the mapper in Rare's Battletoads (AxROM) is rougly equivalent to what Scrapyard Dog uses. No EXRAM at all and honestly AxROM's paging setup is even worse. But honestly, I don't care. What matters to me is if the game itself is well crafted rather than what's in the cartridge. This came up before, but I agree Pokey was vastly outdated by 1984. Atari's best variant on this style of LFSR sound generator was Mikey in the Lynx. Something along those lines built into Maria's silicon would have been nice, but we got what we got. It can be done, but yeah - unless there's software which requires it then what's the point?

The color limitations aren't that bad, in my opinion the bandwidth requirements are much more of a problem. Going from 160A to 320B doubles the number of pixels to move which effectively halves your fillrate. Using 320A will net you identical performance but is much trickier to stylize - you'll likely have to layer draws to get appealing visuals. But in any mode you're always dealing with Maria eating Sally's cycles. Adding more RAM can help simplify Display List management significantly, just from being able to cache them. They take significant CPU time to generate and if you have mapper hardware which helps partition them into different segments (i.e. background and foreground) that's also a huge boost. My ideal would be nearing MMC5 level craziness where you'd have a mapper negotiate all interactions with the cartridge's EXRAM and be able to "nudge" select Display Lists' horizontal positions. So then you could just write to a register to move your entire backdrop left or right by (let's say) eight pixels. Drop the fuss of horizontal scrolling to nearly zero.