TailChao

Does the Cuttle Cart II map anything which could respond to reads when A12, A14, and A15 are low? Secret registers from $0000 - $0FFF or $2000 - $2FFF are suspect, as these would be enabled when the BIOS reads from $8000-ish. The NTSC and PAL BIOSes stay above $C000 which would prevent a conflict like this.

It's been awhile, actually several whiles - let's catch up. This is, although theoretically possible, far too much of an ask. I cannot justify the necessary time investment relative to other things right now. Yes, and since there's now support for running the game in something other than our own software, let's dig into this one for a minute. If you open the root folder of the Steam or Standalone (Humble Bundle) versions of Rikki & Vikki the files and folders below are of interest... ./Data FoxBox.cdf The Cartridge Descriptor File used for running the game in BupSystem and also parsed by the Windows version. As pointed out by @Trebor and @RevEng, this is an alternative to the *.a78 file format. We used a bin/cue style structure as it better caters to our development workflow and how we were using the hardware. More details are in BupSystem's HTML Help. FoxBox.bin The game's raw binary - this is what Sally and Maria are actually executing. ./Music RV_Samples.smp RV_Macros.ins Default samples and patches, these are identical to what's in every cartridge's BupChip. GN_Samples.smp GN_Macros.ins Sega Genesis alternate patch set. ZX_Samples.smp ZX_Macros.ins Sinclair ZX Spectrum alternate patch set. *.mus Music tracks. Now this part is important, so I'm going to write it LOUD in hopes that it'll actually be heard... Rikki & Vikki's binary (./Data/FoxBox.bin) and music data (./Music/*) were made user accessible from day one so it could be run outside of the Windows version's sandbox. However, we cannot provide support or troubleshooting for any configurations outside of this or BupSystem. You're on your own. When we designed the custom hardware used in Rikki & Vikki it was not intended as copy protection or any sort of lockout - it was so the game would achieve the level of visual and audio fidelity that we felt was necessary. These were released under an open license prior to the game itself and (as of writing) have been available and thoroughly documented for over two years. I apologize if exclusion was your experience, but there is a hard limit on what we can and cannot do. If you'd like to add support for these to your own software - I'm happy to answer questions, but cannot write the implementation for you. Thanks! I'll add a link to this in the FAQ and support for SOUPER in *.a78 files will be available in BupSystem's 0.9.6.4 update next month. This depends upon which signals are routed to the CLPD / FPGA on these devices and how many gates are available to implement SOUPER's feature set. I think the Dragonfly could pull it off and I've asked @SainT to implement SOUPER support in the 7800GD if there's enough resources. No idea about the Concerto.

The Atari 7800 version is now sold out. Some lucky buyer managed to squeeze their order between the inventory running out and disabling a button, so they'll be receiving an unclaimed press copy for a total of 551 units. Regarding what happens next, I'll be taking a break from the board and scene for awhile. There may be an additional run produced in the future but I'm not making any promises on what will or will not happen. The Windows version will continue to be maintained. I am not smart enough to manage preorders so this sort of thing will not happen. Thanks again to everyone who gave the game a try.

We also offer a standalone Windows version through a Humble Widget, which will run full speed on a 1.2GHz Pentium III and (in my opinion) is the definitive version. Aside from some of the Steam and BupChip work, the game was developed entirely on one of these - so I tried to keep the requirements low. No problem, orders usually go out in 1 - 2 business days. I'm impressed you're willing to use a genuine PainLine! Might want to consider an upgrade 3 Copies left.

This is normal - the brackets on the game's board which mate with its plastic shell are slightly oversized, giving it a little too much wiggle room. But what you have should still be sturdy enough to last. Unfortunately, I didn't catch this issue before manufacturing since our development boards had a large socketed flash which was pressing against the bottom of the shell and holding it in place. If we were to do another 7800 game or production run of Rikki & Vikki, the board's dimensions could be adjusted to fit the plastics a little more snugly. ...and this was an absolute pain. We had to do at least 5 - 6 revisions of the shell design to make sure the plastics would fit in all variations of the cartridge guide. Definitely not one of the hardware's more elegant parts.

I've been trying to nudge support for the game's mapper, or at least something similar, into the 7800GD. Not necessarily for compatibility with Rikki & Vikki but because I don't feel there's many (any?) good options for giving the 7800 a nudge in graphics - most effort has been in the audio department. I'd still like to try and finish the PMC1's hardware tests for similar reasons, as this really helps put the console on par with comparable offerings on the NES. Getting full BupChip support into any flash card is somewhat convoluted since you'd need not only a microcontroller, but standardized way to load music data into it. I'd actually be fine with someone ripping ./Data/FoxBox.bin out of the Windows version and running on a flash cartridge - otherwise I would have hidden it in the executable. But if that data were frequently given a five finger discount, especially when we already made it available for (what I feel is) a reasonable price, then there's an issue.

It does do some light initialization and hardware tests, therefore leaving everything in a slightly different state than a cold boot. But you can also just duplicate this condition instead of writing your own BIOS / Boot ROM.

I only have one which could be described as working and in good condition, life is difficult for such an inadequate wolf. Eh... we really should have shot a promotional video of the development team swimming in a pool of Combat cartridges ala Scrooge McDuck, hyped up a bunch of revolutionary audio-visual-olfactory nonsense, then never shipped anything. That'd net some real xtreem retro gamer credz. Reselling something at a markup is what any distributor does, so I honestly have no issue with this. If someone pays for a copy of the game they can do whatever they like with it. It's not like the digital version is going to be taken away either, and that's the version which had to move in order to immediately kick off another project. 15 Copies left now.

Keep in mind that unless I have the hardware in front of me all of this is a guess based upon the symptoms, it could very well be something else. But good to hear you're keeping the console! 7800s also stack extremely well despite their funny shape - just rotate each one 180 degrees to impress your friends with a Yertle the Turtle scale of towering classic cred.

Designed for long term reliability, this wedge was not... Rikki & Vikki's cartridge has very careful (perhaps somewhat paranoid) decoupling compared to both Atari's boards and the 7800 itself, this could prevent it from acting wonky if the console's 5V rail isn't stable or some of the capacitors are failing. Another possibility is the 7800's internal SRAM is what's at fault - as Rikki & Vikki places all its Display List Lists in the cartridge's EXRAM. Fetching a Display List (List) has the tightest timing requirements of Maria's accesses, so if the SRAM is drifting out of spec it might not get the right data out in time. Based upon these new symptoms I don't think Maria is the culprit. I'd first go for the regulator (just to be safe) and big electrolytic caps, then try replacing the SRAM.

No, it's just bad. Since Brandon couldn't discourage you, let me give it a shot - the hardware is also made out of glass. Nintendo gave the GameBoy this really elegant voltage regulator to make sure all the chips 'n bits stay at a comfortable 5V. It's well designed enough to keep this steady even with very low or high input voltages. This also provides some protection for the console. The SuperVision, Gamate, and GameCom have no such protection. For a modern comparison, this is aliexpress bootleg engineering territory. Some SuperVisions aren't stable using NiMH rechargeable batteries, causing VRAM corruption and Commodore-style speckles on the display. You're technically overvolting the components by using four fresh alkalines. With the current cost of the hardware you're effectively paying a hundo (or more) for something which needs heavy rework just to... work. It's bad. No stars, do not buy.

As of writing BupSystem does not feature a scanline filter.

Maria's timing is fixed based upon the type of data being fetched, not where it's being fetched from.

If you haven't done so already - I recommend trying to get in touch with developers, publishers, and distributors outside of the AtariAge community (I know Cote Gamers was looking for 2600 / 7800 shells awhile back). There might be more interest there.

Yeah, that sort of setup has always been my preference. Adding in luxurious debugging features like nocash's work would be ideal, but no idea if that'll ever happen. This seems to have already been addressed here, and (generally) I cannot help you find ROMs - you're all on your own for that. However, I do want to point out that many "goodsets" for the 7800 aren't actually that good. Faulty headers, missing Pokey bits, etc. The PROPack by @Trebor is properly curated and checked - if that doesn't work then it's definitely my fault!

Gone!

Update - you can have this thing for the cost of shipping it to you.

To dive into this for a bit - as some of the issues seem to be recurring... When something "works on the hardware" this also includes what type of cartridge (or flash cartridge) you're using, and how that affects the game software. What's the exact partitioning and r/w setup of $4000 - $FFFF? Is the internal memory and any EXRAM initialized for you? Are there any "secret" registers you might be hitting by accident? Agreed, with the addition that you should also check for (unintentional) accesses in unallocated regions of memory by either Sally or Maria. The latter is particularly dangerous since fetching a garbage DLL could trigger an NMI when you're not expecting it. If I remember right, this is one of ProSystem's biggest faults since it treats any unallocated areas as zero instead of open bus - not sure if any of its forks change this.

Hah, well I dunno if five months ago counts as a 'recent' update but I'm glad you're enjoying it. I do want to be clear that BupSystem's development is still on hiatus, so I'm still keeping track of any issues noticed in v0.9.6.3 but they're not necessarily going to be addressed soon... possibly never. Regarding accuracy - some of Maria's timing stuff is definitely off and so is a bunch of POKEY's behavior. I'd definitely recommend sticking with A7800 if you're doing anything serious with POKEY or the XM's features. The only things BupSystem "leads" in are support for SOUPER, PMC1, and the BupChip.

Yes, this is also similar to how GTROM + GTMP3 was implemented for the NES. ...or how the CD-Player was implemented in my stereo cabinet.

THREAD_TOPIC EQU $2808 ; -/W ; Writing any value contributes noise to the thread and increments the subject counter by one. ; ; After 192 ($C0) writes the subject counter will automatically wrap back to $00. While the counter's value can't be ; read directly the loopback point can be detected by an uptick in complaining about the hardware's poor audio, lack ; of POKEY, and assumptions regarding GCC's intention to make their own way-better-than-anything-ever sound chip ; which could have saved the 7800, satiated world hunger, cured all diseases, cleaned up all pollution, ended all fighting, ; and funded the development of a truly sentient robot dog.

The Commodores have been sold.

Not just one, but two SIDs... Up for sale or trade are a whole bunch of Commodore [MEMSIZE] goodies. Below is a full inventory - and, as usual, you've got to take the whole lot or nothing at all. Commodore 64 (NTSC) PLAnkton in U17. Commodore 128 (NTSC) Turbo Illasm in U36. Socketed VRAM in case you'd like to upgrade the 8563 VDC from 16KB -> 64KB. Modified C128 Power Supply which works with either unit Cartridges EasyFlash 3 Omega Race Rootin' Tootin' Disks Math Manor Phonics Prime Time : Volume 1 Word Spinner As working isn't always a feature with Commodore anything, I'd like to go into exact detail about what's here. Let's start with the C128. This is the machine I was primarily using, and quite a lot. While the case is fairly yellow the electronics inside are in great shape, it's never failed to start up or acted wonky - super stable. The original heatsink plate for the VIC II and VDC was rusty so I removed it and made two new sinks. The VDC's VRAM has been socketed if you'd like to drop in a 64KB upgrade. Turbo Illasm has also been installed as the Option ROM (U36). Now the breadbin is in much rougher shape and I originally got it broken to see how miserable a restoration would be - the answer was very. If you look closely at the board photos you'll see there's acorn nuts instead of screws holding it in place - all the plastic standoffs aside from one had snapped so I drilled through the bottom of the case and fashioned new ones with some screws + washers. The PLA also died so there's a PLAnkton in there which replaced it. All the other chips have been socketed since I had removed all of them for testing at one point or another. It seems to run software fine, but the case is definitely rickety and the keyboard needs to be replaced. Many of the keys were already broken or glued back on, and the CTRL key decided to liberate itself after I got the thing out of storage. This is a good machine to have around if you're repairing lots of other Commodore hardware or need a board with everything socketed. Mostly I had this around to test for compatibility issues relative to the C128, of which there's (impressively) few. I found a bag with the original heatsink plate and screws which will also be included. The MooltiPower is just a C128 power supply with a C64 power connector in the middle, you disconnect this to use it with the C64 and put the C128 end back on for use with the C128. It's pretty convenient. Cartridges all work fine, EasyFlash is great, absolutely no idea if any of the disks work. I'm looking for $150.00 + Shipping for all of this, the items may need to be split into two boxes to ship safely - I'll let you know. My biggest concern is making sure the C128 doesn't get damaged. As with the Atari 800 that started this fantastic junk trek - cash is great, but I also like to trade! Here's some items I'm looking for which could possibly reduce or remove the price... TurboGrafx-16, PC-Engine, or PC-FX stuff Game Gears, if not recapped Watara SuperVision or TV-Link, especially these since I'm reverse engineering the hardware I'm happy to ship this anywhere in North America. If you're interested, send over a PM!

This isn't a balancing issue, this is an amplification issue - i.e. the currently available mods tap the chip outputs directly rather than using something like a 358 or 4558 in their output stage.

If whatever cartridge or expansion hardware you're using has a timer connected to /IRQ it'll be way easier to play the samples asynchronously compared to the stock hardware. No idea what the XM supports, but it was mentioned as a feature in Dragonfly.