TailChao
-
Content Count
861 -
Joined
-
Last visited
-
Days Won
2
Posts posted by TailChao
-
-
On 8/22/2020 at 8:13 PM, davidcalgary29 said:Four words: Rikki & Vikki plushes. They'll be the hit of any gaming convention! Please also consider the
Weighted Companion CubePhysical Support Cube for a stuffie as well! Thanks.If we rewind towards launch times, I was looking into this minus the
Physical Support CubeBox Type Objects since there's a few people in my area who design plushes. But, eh... maybe for the next thing, whenever that happens.On 8/22/2020 at 9:17 PM, MrBeefy said:I know you said moving on but I think some of us are really wanting this to be bigger.
Sure, I want that too. But if it was going to happen it already would have.
-
3
-
-
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.
-
4
-
-
1 hour ago, Starwander said:They are like the original with the handle
Haha, no worries - they still look fantastic!
-
19 hours ago, -^CrossBow^- said:I'm also not keen on those holes still being present on the label side for where the cart guide pegs were punched out. That is the #1 spot were the labels start to peel off the cartridge because of those openings allowing dust etc to creep up under that label. And honestly with 7800 games, are the pegs really that needed? The carts will still only fit in one way since the PCB isn't right in the middle and sits just low of center.
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?
-
19 minutes ago, Greg2600 said:Don't think anyone has considered that for 7800 whether XM or not, in fact I'm not sure it's been done on any 8-bit system in that same fashion.
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.
-
1
-
-
16 hours ago, RevEng said:Karl, I literally can't look at your gif without hearing that low hypnotoad drone in my head. 🤪
So this'll be added next toad break, right?
Right?
-
1
-
-
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.
-
1
-
-
30 minutes ago, RevEng said:Wow, the IO and timer being readable at Maria speeds is fascinating!
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.
QuoteOn Beef Drop... it's not always foolproof to go by one or two previous homebrew releases. 7800 aficionados will have problems that go unreported, because they assume it's just a problem with their specific 7800.
Agreed, but if any strange behavior gets (or was) reported - that's data.
7 minutes ago, batari said:The programming docs said "don't use" RIOT RAM because it may not be available in future versions of the MARIA chip, which we know now isn't true, and the 7800 BIOS itself uses RIOT RAM for executing code (for booting a 2600 game). So with this I figured it was safe, so I used it for booting all games (and for many other things.) If it said RIOT RAM is unstable, I missed that part. That said, I probably do still need to use RIOT RAM for booting 2600 games in a similar manner as the BIOS does, but I will keep its use to an absolute minimum.
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.
-
1
-
-
2 hours ago, RevEng said:I'd love to see if the 2MHz flavour of the 6532 is affected similarly, though I suspect it will be...
Only one way to find out!
2 hours ago, RevEng said:When DMA is on, failures in these modes always seem to involve DMA switching on mid or post instruction. (DMA interruption was my original hypothesis for the RIOT RAM failures)...
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.
2 hours ago, RevEng said:I didn't bother sending Maria to the RIOT RAM for graphics, since the clock is way out of spec, but your result sounds fun.
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.
2 hours ago, RevEng said:In semi-related news, the RIOT timers are actually pretty usable, provided you check the value immediately after setting and repeat if necessary. (with the obvious caveat that each TIA and RIOT access during the timer period will stall the timer by 0.5 cycles.) Reads to check the timer (absolute) never fail on my unit, even with my heavy+variable DMA test program.
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
-
5
-
-
11 hours ago, batari said:I don't know but have guesses. RevEng has been very helpful with this, and he determined that no matter *what* you do with RIOT RAM, there is no way to make it work 100%. DMA on or off, it doesn't matter.
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.
-
4
-
-
Hey, thanks!
We're down to the last 50 copies now.
On 8/16/2020 at 2:19 PM, electronicsibley said:There will probably never be the critical mass of users to make development on the 7800 financially viable on its own, but it’s inching in the right direction.
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!
-
6
-
-
51 minutes ago, KevinMos3 said:Is that because of having to port the bupsystem emulator to the Evercade chipset? Yeah, too bad there's no 2-player link support. That would have been great for the Lynx carts as well.
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.
QuoteIt's always good to see great games ported to the Switch, but I'd imagine we're only talking about a digital release?.. I only buy physical releases. I suppose a physical release would be a big investment, but there are plenty of companies that specialize in that, which might be the best way to guarantee sales since pretty much everything they put out is treated as collector items by collectors who buy no matter what (I'm kinda in that crowd). Minimal advertising needed that way too.
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.
QuoteI'm glad you've sold most of your stock, but sad to hear it wasn't what you'd hoped for. I've done my part though (bought 2 copies for myself, one for my brother, one as a gift for a friend who loves it, and I demo'd it at a gaming expo in Las Cruces - had it set up for all to play and told them where to buy).
No worries, I was aware of the risks going into this - and thanks for the support
-
1
-
-
11 hours ago, Giles N said:Have you considered a Rikki & Vikki release for the EverCade handheld?
Perhaps if you struck a deal with other indie-developers, you could figure out a sort of collection of games to pack on a Cartridge, and still have revenue or get attention?
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.
-
1
-
-
18 hours ago, GaryH917 said:Waiting for my copy to arrive! Thanks for releasing this amazing game 😀.
Hey, no problem. Thanks for giving it a try!
11 hours ago, Giles N said:... You’re aware your company has released a title for a home-console
... 30 years (!!!) after its official discontinuation...?
Its a smash-hit.
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.
7 hours ago, Theallknowingsause said:From what I've seen and read he made the game to have the polish of a normal "pixel art Indie game" and was hoping most of the sales would be from the steam and humble bundle versions (bought by people who don't really care too much for older consoles, but the demographic of people who play indie games), but what ended up happening is us nerds ended up showing it to our friends as "a super cool Atari 7800 game" rather then a "super cool indie game" like how he was intending.
I'm also guessing his profit of the game wasn't as much as he was anticipating, (because of the small player base the console has).
What I am trying to say is you're right in saying it's a "smash hit" but not in the way it was set up to be.
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.
-
2
-
1
-
-
On 7/28/2020 at 1:03 PM, Giles N said:Considering that Atari discontinued the 7800 in 1990 (!!) your game is actually a bit of a smash-hit...
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.
On 7/28/2020 at 1:44 PM, Hastor said:I've definitely seen it brought up more times than any other title since getting my 7800 less than a year ago. I was raised on the 5200, just recently got into 7800 and loving it.
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.
-
3
-
-
13 hours ago, Giles N said:How many left in stock by now?
As I type this, 59.
-
On 7/21/2020 at 10:24 PM, bizarrostormy said:If I need to put certain things at specific addresses within a bank, must I use both ORG and RORG every time? That is unwieldy. I could use ALIGN, but then dasm won’t detect overflows, so I’d want to add macros to do that, which is getting back to unwieldy.
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).
On 7/21/2020 at 10:24 PM, bizarrostormy said:And out of curiosity, does anybody else think of RORG addresses as virtual and ORG addresses as physical? Or is there some other terminology people use here?
Yeah, RORG is creating the logical addresses for your resources and ORG is generating the physical addresses in ROM (or other storage).
-
19 hours ago, RevEng said:Because POKEY was there and ready, rather than them developing something new. If I had my druthers they would have stuck in a chip with FM synthesis. But in a "why just TIA" discussion, POKEY seems like a no-brainer alternative; it's the minimum Atari should have done.
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.
QuoteMost of those 40 pins are for functions the 7800 has no need for, so yes, the chip is a little bigger, but would it really impact the board all that much over some other chip? Genuinely asking, but given it doesn't add a whole lot of space to POKEY carts, it doesn't seem like it.
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.
18 hours ago, bizarrostormy said:An audio-only (or audio+paddle) version presumably would have saved a lot on manufacturing across a lot of products. The time to do this would have been 1980 or 1981, when its sound capabilities were still relatively sophisticated. Unfortunately, by then Kassar had already laid off the R&D staff.
Pretty much, yeah...
-
5
-
-
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.
On 6/30/2020 at 11:30 AM, Crazy Climber said:
Aaahhh - this is perfect!
On 7/8/2020 at 8:18 PM, Theallknowingsause said:Wouldn't wine also work? (The application not the drink)
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.
On 7/9/2020 at 12:41 PM, the_hawk said:There's no way I can afford to shell out the $85 to get it shipped to the UK, but I've just picked up the Steam version & it's fabulous.
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.
-
7
-
-
2 hours ago, RevEng said:I think a POKEY+TIA combo built into the 7800 would have been a viable option at the 7800's release date... TIA on it's own wasn't excusable, though.
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.
-
2
-
1
-
-
1 hour ago, christo930 said:Does this mean you won't be creating new games? I hope not.
Nah, nah - I'm working on some things but can't make any promises if or when they'll happen.
1 hour ago, christo930 said:Wasn't the POKEY still being used in arcade machines?
Yes, but these were usually Quad Pokeys - four times the Pokey for four times the channels!
1 hour ago, christo930 said:From what I can tell, the POKEY was a pretty good sound chip. Is the NES's sound chip that much better? Is it better at all?
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...
1 hour ago, DrVenkman said:But again, as I stated above, that timeline never occurred.
Instead we got the alternate timeline, where it shipped in 1984 and the 7800-CED upgrade followed in late 1985.
Wait...
-
3
-
-
1 hour ago, The Usotsuki said:I'm OK with sound chips. Coprocessors...only if they're around the same power or maybe just a little step up, like the SA-1 chip. I tend to feel like putting an ARM on a 2600 or 7800 cart is kinda cheating.
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.
26 minutes ago, SmittyB said:I'm just going to chime in here to rightfully give credit to Argonaut who don't get enough recognition for the SuperFX and only got an unlubricated shafting from Nintendo for their efforts.
Yeah, they did a fantastic job on both the SuperFX and the software using it.
24 minutes ago, Keatah said:And furthermore what determines if something is actually a coprocessor or new system? When the new chip is more powerful than the original processor? Or when it is of comparable (and period correct) performance level?
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.
22 minutes ago, bizarrostormy said:The 7800’s obvious technical deficiencies are audio and RAM. Had Atari priced it at $200 (still significantly cheaper than the 5200) they could have included POKEY and more RAM. Instead they intentionally designed it to allow cartridges to address those weaknesses. The features were always available. The only question is when you paid for them.
Pretty much, and while what shipped has limitations - it's a well thought out architecture.
-
2
-
1
-
Coprocessor
-
12 hours ago, Greg2600 said:Prior to Rikki & Vikki, we've not had "special cart hardware" on the system the way the NES did for most of its run, and the Master System to some degree. Whether that proceeds is another story, because as it's creator has said, he made little on the 7800 release.
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.
QuoteI've been waiting for idk, 6, 7, 8 years for a 7800 flash cart. Meanwhile the XM is on year what of it's voyage? I'm not sure we can point to either innovation as all that promising, given the extreme and perhaps homebrew-record setting delays. TailChao's work has been David Crane level brilliant, but as I said above, it doesn't work very well fiscally so you have to wonder if that's a dead end as well? Perhaps if it could be coded in a flash cart in some way as DRM?
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.
3 hours ago, The Usotsuki said:I guess the question of any system is - what can it do without assistance? and what can it do with just bankswitching (and maybe enhanced sound, as with the SMS)?
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.
2 hours ago, zzip said:Pokey would have been better than the built-in TIA, but I think it really needed something better than Pokey. Pokey was showing its age mid-80s.
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.
43 minutes ago, Karl G said:I've hung around the 7800 forums for a couple of years now, and I really haven't seen any push for a coprocessor-enhanced cart. If someone made one, I'd be curious as a tech geek to see what could be done with it, but there's really no need or demand for it that I've seen.
It can be done, but yeah - unless there's software which requires it then what's the point?
-
6
-
-
3 hours ago, zzip said:I forget the exact issues with the 7800's 320 mode, but in general it has color limitations that makes using it a pain for many types of games.
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.
-
3
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
How difficult is it to add music to existing 7800 games?
in Atari 7800
Posted
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.