BupChip better than POKEY? Finally a new audio solution for the 7800?

[TailChao]

So what are the costs with this chip? How much would it add to the price of a game assuming something like AtariAge doing the manufacturing of the boards so that the chips could be bought for a scale of more than 1 game, though obviously they won't be ordering them by the 10s of thousands.

This will vary among distributors, but Mouser is a good example.

 

Quantities in the hundreds will fall between $4 - $5 per chip, you also have to factor in support components so it's a little higher. But if this were to be used for more than one game I think it should be coupled with a more generic mapper design than SOUPER - which was just spec'd for Rikki & Vikki's needs.

[turboxray]

On 5/2/2019 at 9:23 AM, Lynxpro said:

 

 GCC thus cut their own throats and doomed this industry to Japanese domination ever since...

For the better in my opinion. Japanese softs were just vastly superior.

[turboxray]

What are the specs of the bluechip? Number of channels? Waveform size? etc

[TailChao]

44 minutes ago, turboxray said:

What are the specs of the bluechip? Number of channels? Waveform size? etc

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.

Edited March 16, 2020 by TailChao
MORE NUMBERS IS MORE BETTER!

[Curt Vendel]

On 5/2/2019 at 6:10 PM, SoundGammon said:

Then there's that story about the manager of the 7800 project back in 1984 took Jack to the warehouse where all the 7800s were ready to go and Jack said: "Get your junk out of here, we do computers now!"

That was Brad Seville and the story was unfounded and given many other verified and hard copy evidences that contradict that statement from him, most likely it never happened and was more of less an event that never took place recounted by a bitter employee who was fired when Atari was sold.

[RevEng]

Commenting on the conversation from the other thread...

12 hours ago, Jinks said:

What would the bupchip and supporting cart hardware cost to make per board? 

Has anyone even considered this chip? 

25 minutes ago, TailChao said:

I think cost was already covered in this BupChip topic, but it's around $4 - $5 per unit in quantity. You also have to program the microcontroller, but this doesn't add too much time if your rig is designed for it (ours was). The only inquiries we've gotten about any of the hardware developed for Rikki & Vikki or theoretical future stuff have been from a handful of developers from outside this community.

There's a bit of adoption-friction that has stopped this from progressing in the AA 7800 dev community... First, I'm not that clear on the hardware production side, being mostly a software guy. I know you published some info - is the design open and all there? To produce the boards, would someone who is used to producing boards with eproms and basic bankswitch plds need to invest in new tools? (obviously the MC would also need to be programmed, but is there anything else?) Are there surface mount components required on the boards?

 

Second, are there any programming docs with some sample code?

 

It may seem to you like the answers for the first and second points obvious and stated, or otherwise implicit, but consider I have skimmed your docs when you released bupchip info, but I still have these questions.

 

Third point. I'm not even sure where I'd start with the bupchip spec in emulation, especially since the microcontroller programming might be fluid. There's bupsystem, but even there the micro emulation is limited to the R&V design. If we cement the micro programming in place for a general standard, and let anybody who wants to go off the rails deal with the fallout, it would be better.

 

Fourth point is semi-related to the third. I implement a game using this system, then I will only have testers who run bupsystem, rather than folks who can run on real hardware. If I need to test it on real hardware, and I personally will for anything in 7800basic, then I will need to purchase the boards and programming gear myself. The flash carts in development will never target this spec, even if was possible, because no legally-free rom is available. (catch 22)

 

My 2 cent analysis. None of this is meant to be critical in the slightest. I think you've done something amazing here, but I think community adoption will take even more work, or at least reaching out to others that will do that extra work. If you don't have an interest in the extra work-for-free, that's cool too.

[TailChao]

Welp, this has been quite a BupChip bump day.

Lemme see what I can do here...

 

8 minutes ago, RevEng said:

There's a bit of adoption-friction that has stopped this from progressing in the AA 7800 dev community... First, I'm not that clear on the hardware production side, being mostly a software guy. I know you published some info - is the design open and all there? To produce the boards, would someone who is used to producing boards with eproms and basic bankswitch plds need to invest in new tools? (obviously the MC would also need to be programmed, but is there anything else?) Are there surface mount components required on the boards?

The software synthesizer is available under zlib along with the mapper verilog.

 

Regarding the boards, there's some good photos available here - aside from the volume knob and one capacitor everything is surface mount. I'm not going to lie, both Tiido and I are very very very hardware oriented. But he made 600 boards, pick 'n placed by hand, and soldered on a hot plate (which is also why all the components are on one side). Should you have to do all this? No, absolutely not - I was hoping if there was any adoption it would allow Tiido to manufacture boards to satisfy that. We didn't distribute the board gerbers, but the published information was really enough to duplicate everything and my inbox is / was open.

 

Out of all the components, the only one which wasn't programmable in circuit was the CPLD holding SOUPER. Both the 512KB Flash and BupChip were programmable from the card edges on the bottom and right, respectively. Again - designed for scale.

 

What isn't available is the branch of BupBoop for the Fujitsu FM-3, which is because...

1. I wanted to first update the software with improvements based upon our holdups while developing Rikki & Vikki.
2. We were using IAR rather than something like GCC-ARM, and there's a big licensing cost here.
3. Aside from rendering in 10-Bit Mono, the BupBoop / CoreTone implementation is identical to the Windows version.
4. I ran out of charity development time / energy / money / don't care anymore.

 

8 minutes ago, RevEng said:

Second, are there any programming docs with some sample code?

 

It may seem to you like the answers for the first and second points obvious and stated, or otherwise implicit, but consider I have skimmed your docs when you released bupchip info, but I still have these questions.

So the protocol between Sally and the BupChip is covered in BupSystem's HTML Help in the Cartridges -> SOUPER section, and the BupBoop 1.2.2cz kit includes a few demonstrations of writing in the SASS language. There's also a MID2SASS converter available which can yank the notes out of a Standard MIDI, and @RushJet1 wrote a toolchain around converting Famitracker to SASS - which isn't publicly available but should give an idea of where we were eventually going with this stuff.

 

I'm not going to deny the steep learning curve, but everything required to start writing music is available.

 

 

8 minutes ago, RevEng said:

Third point. I'm not even sure where I'd start with the bupchip spec in emulation, especially since the microcontroller programming might be fluid. There's bupsystem, but even there the micro emulation is limited to the R&V design. If we cement the micro programming in place for a general standard, and let anybody who wants to go off the rails deal with the fallout, it would be better.

That was already the intent with how the software was implemented - nothing is tied to a particular microcontroller or hardware implementation other than using SOUPER as an intermediary to send commands to the BupChip. If you look at what data are actually consumed - it's just the samples, instruments, and music tracks. Everything else is "whatever" in case we wanted to switch chip manufacturers.

 

 

8 minutes ago, RevEng said:

Fourth point is semi-related to the third. I implement a game using this system, then I will only have testers who run bupsystem, rather than folks who can run on real hardware. If I need to test it on real hardware, and I personally will for anything in 7800basic, then I will need to purchase the boards and programming gear myself. The flash carts in development will never target this spec, even if was possible, because no legally-free rom is available. (catch 22)

Sure, and the few who were interested had to get development boards from us. Which are basically the same as our production boards except the NOR Flash is DIP + Socketed and the BupChip is coupled with an FTDI Serial <-> USB thingy so you can use the diagnostic shell.

 

 

8 minutes ago, RevEng said:

My 2 cent analysis. None of this is meant to be critical in the slightest. I think you've done something amazing here, but I think community adoption will take even more work, or at least reaching out to others that will do that extra work. If you don't have an interest in the extra work-for-free, that's cool too.

Oh, no no no - nothing was expected, at all.

 

My hope was moreso that there'd be interest in the mapper tech and that'd start some sort of dialogue, then we'd use feedback to develop a better version and improve the audio toolchain for easier use. That's what PMC1 was supposed to be.

 

But yes, at this point I cannot work for free and what we've given away is enough for someone else to run with the idea if they'd like to.

[RevEng]

I completely get all that, especially the "work for free" comment. I think in the end your mailbox was empty and there was little dialog because most of us don't have both feet in hardware and software. If someone is software, they're either committing a hardware person to invest time and money in a new process, or else risk orphaning their software time investment. If someone is hardware, they have no desire to put investment in without existing software, or else risk losing that money+time investment. There are few folks who *can* make both commitments, and probably nearly-zero folks in the 7800 scene who also have the desire to make both commitments.

 

This bums me out more than a little, but it is what it is. From what you've written above (and previously) I know you understand the geometry of the situation well enough too. I'm mostly spelling it out for people  who ask "why no bupchip games?!?"

[TailChao]

Right, and from continued observation you'll never get any adoption of a NewThing^TM unless it fits into the following workflow exactly...

1. Build in 7800basic.
2. Push to AtariAge Store.

...which is completely fine, but I'm not taking on that responsibility.

[+batari]

Frankly, I am kind of shocked at how much these POKEY replacements go for. HOKEY has always targeted a much lower price point than any other POKEY replacement. I suppose I should actually finish the damn thing, as clearly there is demand.

 

Good news about HOKEY (if I ever DO finish it!) is that it is microcontroller-based like BupChip, not CPLD/FGPA-based like other POKEY replacement devices, which could potentially mean that BupChip code could be ported and licensed on the hardware. It's just a thought I had, and I have no clue if it would even be possible!

[TailChao]

10 hours ago, batari said:

Frankly, I am kind of shocked at how much these POKEY replacements go for. HOKEY has always targeted a much lower price point than any other POKEY replacement. I suppose I should actually finish the damn thing, as clearly there is demand.

For what they're targeting (high accuracy replacement of the original component), the prices are very reasonable. But yeah, it's absolutely bonkers to use these as a sound generator in hundreds of cartridges - especially considering what else is available for far less (YM2413, YX5200, SoftSynth, etc).

 

 

10 hours ago, batari said:

Good news about HOKEY (if I ever DO finish it!) is that it is microcontroller-based like BupChip, not CPLD/FGPA-based like other POKEY replacement devices, which could potentially mean that BupChip code could be ported and licensed on the hardware. It's just a thought I had, and I have no clue if it would even be possible!

Sure, and you could adapt any number of other SoftSynths or write an entirely new one - and if that's portable then it's easy to add support for it to emulators. In my opinion that's the real perk of using a microcontroller. There's nothing inherently wrong with using a CPLD or FPGA for audio generation, but unless you're cramming a lot of other functionality into it (i.e. highly complex EverDrive style features) then it will be far too expensive for what you get back.

 

With regards to licensing, BupBoop is all zlib so there's basically zero requirements .