TailChao

Already answered some of this in the customer service email, but I'll expand upon it here for others. This looks like a side effect of the luma and chroma getting mixed improperly in your A/V mod - particularly because of the color fringing, the chroma signal may be too strong. Software using any of the high resolution modes is more sensitive to this. Unfortunately we cannot guarantee the game will work correctly through any video modifications as there is a large variety of them and they're not all robust designs. For anyone thinking of installing or designing an A/V or S-Video modification, keep in mind that not all televisions (especially new ones) obey proper signal leveling or termination. Of course, making sure your console is in tip-top shape is also a prerequisite. @-^CrossBow^-'s services have been the Official PenguiNet Recommended option since launch.

It's a softsynth, so it's all adjustable. In terms of what shipped in Rikki & Vikki and what's emulated by BupSystem... eveything is identical to BupBoop 1.2.2cz except the call stack depth has been increased from 4 -> 16 entries. The BupChip / Fusjitsu FM-3 inside each cartridge will only render in 48KHz 10-Bit Mono while the Windows version is 48KHz 16-Bit Stereo. The BupChip is also limited to only 224KB of music and sample data in order to accommodate the driver and debug shell, while the Windows version has no such restrictions. Base capabilities are 16 sample channels - each can play an 8-Bit signed waveform up to 32KB in length, singleshot or looping traversal, no filtering. Essentially a turbocharged version of the Sega CD's Ricoh RF5C164.

Some corrections, having done reverse engineering on a few of these... The SM8521 used by the Gamecom isn't too bad programmatically. Its CPU core is kinda different, but the support modules around it (both graphics and sound) were well thought out. It's not going to handle fast action scrolling games at any decent framerate - although given how trash the LCD refresh is, that's probably fine. Nonscrolling or flipscreen stuff where only the characters are redrawn would be fine. In terms of running unlicensed stuff, the Gamecom has a signature check before dispatching any software. Luckily it's not too complicated - basically a checksum of a predefined list of bytes scattered around the cartridge. The biggest problem I saw with the Gamecom's design was the limited memory. Your software only has some of the 1KB SRAM internal to the SM8521 to work with. There's 8KB of battery backed memory in the console, but it's reserved for the PDA features and high scores. You also have to play nice with the system firmware which eats up more resources. The console gets way better just by removing the built-in software and adding more RAM. Most of the cost-cutting seems to be in build quality and electronics design rather than the "numbers" - the GameBoy has this really nice little ALPS regulator board which keeps it stable across a wide range of power sources, the Gamecom (and SuperVision) have nothing like this. The board layout is also hideous, it looks like babby's first PCB. Both the SuperVision and Gamate are 6502-based, not Z80. Praise should be awarded to neither. Could you make a decent game for this handheld dot-com bubble? Yeah, sure. Should you pay real buckaroos for this hardware? No.

No worries - not my hardware, not my call.

A hardware test feature in the XM's BIOS might be a good addition, if it's not already there. Not just for the XM's hardware - but the base 7800 as well. That way when there is a problem in a user's console you won't be in the dark. I highly recommend going down this route, and thought the hardware was already designed this way. The XM adds quite a bit of junk in the trunk and a cartridge can be plugged into it. Given the age of the 7800 and unpredictability of what could be inside any cartridge, it's a good investment - there's a reason Sega did this with the 32X.

...and it's only 40KB, no expansion required. Larger ROM sizes can help, but don't correlate to a better game. To be fair, I'm not super active online and the only project I did which received wide coverage was released in 2009. So I don't even know anymore.

I see the topic of digitally distributing ROM Images for flash cartridges come up frequently here, but no real solutions proposed for it. I do think as long as it's possible, it's a good option going forward. So here's my two (small) recommendations... Humble Widget These are commonly used to distribute modern game software, but Humble actually allows (and encourages) you to attach any data to the widget. You define a set of content, and a widget attached to it. The pricing is totally up to you, and it's possible to have an item for free but with optional tipping. Once nice thing is that anyone who uses the widget is now "registered" and can download new versions of whatever content you attached to it - they don't even need an account with Humble (although as a developer, you will). I'm very impressed with this service and we used it for the standalone Windows version of Rikki & Vikki. itch.io Another popular distribution platform for "whatever" - and I've seen it used frequently by the NesDev Community to distribute games. I can't speak for firsthand experience (I favor Humble), but have heard good things.

For anyone interested in learning more about Yamaha's family of FM Synthesizers, I recommend giving hoot... a try. Hoot is an audio emulator for PC-8801, PC-9801, X68000, and many of their friends - all of which feature a 4-Op Yamaha. As mentioned before (in the last thread?), you can't always migrate techniques 1-1 among the different chips, but it's still a good start. You can also observe what the software is doing on the right ("Driver work") - and use this to guess or extract patches. This feature is especially helpful if the driver bangs the chip to make some cool sounds. Of course, it can also be used to just listen to music. I've noticed lots of cute tricks in Falcom's games and Ryu Umemoto's work is also pretty cool. Some warning - Hoot is very fussy when loading music packages. Anything on the Hoot Archive is outdated and won't work with newer versions of Hoot. What I recommend is the following... Download the latest version of hoot... Follow the directions here, but use this or this as your source of the latest *.ini enhancements (hoot_2018-06-26.7z) and music packages instead. (optional) When 1. and 2. result in every music package loading with "invalid driver" - fiddle with the *.ini set and which packages you used until something works. Enjoy some Yamaha noises.

Yes, if only Atari had offered a mapper with elegant paging, a proper raster counter, and capable audio expansion in 1988... If only Atari had paid developers for larger and more impressive system sellers... If only the board layout wasn't so noisy... If only the R/W signal was properly split into OEn and WRn so the goofy timing bodge resistor didn't need to be there... If only the controller ports had actual protection circuitry... If only I had a sentient robot dog that could hold open doors, carry groceries, and do multivariable calculus... Things would have been great! Which, all things considered, was a fairly smart business decision.

It's not absolute, but I do think developer age certainly has an impact. Both the NES and Genesis are "in" right now, so we're seeing lots of large scale projects being developed for them. It's also been long enough that many of the kids who grew up with them could have worked professionally in either the game or software industry for several years. On the flip side, because it's in "peak nostalgia" - you're likely to get coverage and purchases. I do, and I agree it's more difficult to complete a project of that scale. But I'm just not seeing a drought of activity in the NesDev community caused by it. If anything they've been constantly improving their work and learning to organize more efficiently. Not all developers are shooting for these targets either, plenty of teeny tinies. Sure, but I don't think my "Programmer Card" having 768KB of data on it should matter. My point was moreso that "too difficult" is kind of silly in a medium where everything is work. Shipping a quality product developed in Game Maker already takes significant work. When you develop for an older platform you're willingly giving yourself workier work. But that's just my opinion.

It was meant purely as what the transistors on the die are arranged to offer, not in regards to what can be cleverly done with them. The latter aspect I have no intention of belittling - ever. Rather that should be elevated because the capabilities are so limited. Same goes for POKEY. For specifics, my fuss with the TIA is entirely in the divider size. Five bits isn't enough, POKEY made this less bad at the penalty of having to pair channels and getting a more convoluted waveform generator. I can't really fault Atari for designing them this way because the TIA was supposed to drive an entire Television in 1977 and the POKEY has to also, uh... PO and KEY. Can they still be coerced into creating good music? Yes. Do I think they were still competitive in 1984 or 1986 when the 7800 was released? No.

Nah, just another idea peddler.

For music, yes - it's abysmal. I don't think Atari's style of LFSR audio generation was competitive until MIKEY rolled around, that one was a solid design. But it makes great sound effects!

Yes and no. Competing with the quality and depth of Nintendo's best (or Konami's, or Capcom's, or Sunsoft's, yadda yadda...) requires a significant amount of resources, but the userbase is also very expansive (and right now - very willing to spend cash). It's also a little difficult to make direct comparisons between platforms since the communities formed around them are very different - NesDev isn't AtariAge. Most of the coverage for "new games on old things" outside of these forums is very NES or Genesis oriented at the moment. Generally though, I think the thought process of "well it's too difficult to compete with these games so I'll develop for something else" is ridiculous. If anything it's a challenge to overcome which hopefully results in a great product. If there's an equivalent on any Atari platform to the success of Micro Mages I'd like to know about it.

Great! Also... If it's helpful, here's some additional info on how I usually rig up my own fault systems. This is all Watara SuperVision (Rikki & Vikki's diagnostics were stripped for space long before release), but is still pertinent to the 7800 and other 6502 platforms. Detecting stack underflows by pushing a trap routine at the bottom is nice, but is even nicer if the fault handler dumps the stack. Another helpful approach is to push a separate trap routine to the stack at the entrance of an IRQ or NMI handler (if you have the cycles), then remove it before you leave. This way you can get a separate fault for these conditions. It's especially helpful if you're running the game tick in your NMI handler and using the time outside of it as a sort of asynchronous low priority task. For the runaway CPU condition, using a macro to place jsr [fault_handler] at the end of each bank is convenient. So then you just have to terminate your bank definitions with something like BANK_RUNAWAY or TRAP_RUNAWAY. Using the jsr also nets you the PC, so... Of course, user defined exceptions which supply a string are also nice to have.

The only other requirement is accurate replication of Maria's timing, in particular how she captures the bus. But there's some wiggle room here, too since all the DLs and DLLs reside in segments of memory which aren't affected by the mapper's address translation. Given who usually works on Analogue's cores, It'll probably be fine.

Reworking and redecorating the menu tree for coherence. Like icons? The menu is now polluted with them, and yes - the little switches move based upon your settings.

She's faster than Sally, but not too fast. Ditching the 6502 style R/W for a PHI2 gated OEn and WRn already helps. Whenever Sally is driving you only want to perform a read or write to cartridge memory when PHI2 is high - but Maria only reads and you have to ignore PHI2 when she's taken the bus.

Hmm... then let's try increasing the divider size again so you don't have to pair channels for them to be in tune, adding direct control of the LFSR taps for even more waveforms, an integrate mode, and better DACs! Oh, it's MIKEY

No problem Another one I've tried out recently is padding with NOPs ($EA), then putting a jump to your exception handler at the end of every bank (assuming your ROM uses paging). This is pretty handy if your project is using the IRQ vector for... IRQs, but as an additional perk the exception handler jump can include some info like the current bank and vaguely where the PC was.

Nothing commercial. My interest is in accurate emulation, documentation, and preservation - all of which the console lacks. Regarding the TV-Link itself, the hardware isn't a true "accessory" - but an entire reimplementation of the SuperVision with colorized NTSC / PAL output instead of an LCD Controller. There's also a few other changes which are less interesting. Either way though, all the SuperVision plugged into the thing does is send over your button presses - the TV-Link is actually running the game software. I think the prices for both the PokeyOne and PokeyMax are very reasonable for their intended purpose of replacing defective or broken Pokeys. But for new hardware, especially cartridges, using either doesn't make much sense - there's more capable audio generators available for far less.

No credit is required, but using my handle is fine. A readability technique I don't often see is to use equates for low and high offsets. So instead of... clc LDA GLO_PointerA ADC #<DATA_WIDTH STA GLO_PointerA LDA GLO_PointerA + 1 ADC #>DATA_WIDTH STA GLO_PointerA + 1 ...you'd write... clc LDA GLO_PointerA + LO ADC #<DATA_WIDTH STA GLO_PointerA + LO LDA GLO_PointerA + HI ADC #>DATA_WIDTH STA GLO_PointerA + HI This is purely a style thing, but I think it helps coherence immensely - especially if you're switching among platforms with different endianness.

You can also look at the other end of the stack, and push a soft reset handler or full exception handler at its base. That way if you use one rts too many it'll either reset or tell you about it. Similarly, if you're not using BRK or the IRQn line on the cartridge slot - drop an exception handler as your IRQ vector. Having clues as to "why" something went awry is always helpful. A perk of the 7800 here, especially compared to the 2600, is that there's enough resources to have debug features or full debug modes in your software.

If you don't plan on supporting SOUPER's full feature set, I still recommend borrowing its method of detecting and special casing Maria's accesses. This relaxes the timing fuss significantly.

Well, I'm not entirely joking since I wrote an emulator for it and are currently working on reverse engineering the TV-Link - which does require a significant amount of library work and test suites. A full game like this, though? Absolutely maybe not. I sincerely apologize for inspiring you to learn more about, and spend actual money on, this dumpster fire of a console. But have fun with Assembloids!