Instead of using the POKEY/HOKEY, why not use the DPC/DPC+?

[Lynxpro]

A lot of us 7800 fans hold the POKEY up in high regard because it's the sound chip we feel should've been standard with the 7800 in the first place or Atari [inc/Corp] should've included it in more titles. There's mods to add it to our 7800s, the Concerto, or a big reason to support the XM. However, the number of available POKEYs for use are dwindling and we have to compete with Atari arcade collectors and A8/5200 owners for those supplies. And the HOKEY solution hasn't been perfected yet. So why not use the DPC/DPC+ instead? It has an authentic Atari - via Activision - pedigree and receives support from the 2600 homebrew scene. Looking back, I'm rather dumbfounded why as to Activision didn't use their own chip in their post-Pitfall II 2600 - and 7800 - releases other than them pinching pennies. Same goes for Atari Corp.

 

Thoughts?

[RevEng]

DPC/DPC+ don't actually have anything resembling an audio output line. Instead they rely on the console to very rapidly poll the chip and change the TIA audio volume based on values returned from the chip.

 

The problem with this scheme is it requires a lot of regular attention from the CPU. Its not a bad trade-off for the 2600, since most of the time it's running a display kernel anyway. It's a much bigger trade-off for the 7800.

[Lynxpro]

DPC/DPC+ don't actually have anything resembling an audio output line. Instead they rely on the console to very rapidly poll the chip and change the TIA audio volume based on values returned from the chip.

 

The problem with this scheme is it requires a lot of regular attention from the CPU. Its not a bad trade-off for the 2600, since most of the time it's running a display kernel anyway. It's a much bigger trade-off for the 7800.

 

How does that exactly work if the original Activision DPC is a 3 audio channel+1 dedicated drum channel chip?

Edited April 1, 2016 by Lynxpro

[phoenixdownita]

 

How does that exactly work if the original Activision DPC is a 3 audio channel+1 dedicated drum channel chip?

Kevtris has a few notes here;

http://blog.kevtris.org/blogfiles/Atari%202600%20Mappers.txt

[RevEng]

That TIA voice is used in a manner similar to sample playback, except the sample data is being generated on the fly. (aka soft-synth, or more accurately 1/2 soft-synth 1/2 hard-synth)

 

You can theoretically cram a whole orchestra into sample playback over a single channel, let alone 3 voices.

[Lynxpro]

So if it's CPU intense to drive the damn thing, then the only way to get it to work for a 7800 game without it taxing the hell out of SALLY and MARIA would be to have another coprocessor drive the damn thing, right?

 

From my understanding, the 7800 cartridge port lines allow for cartridge - or cartridge expansion schemes - based CPUs. But if one uses such a scheme, does that automatically override the SALLY or can it remain independent? Let's say hypothetically speaking, you use another 6502 - and RAM - inside the cart to drive the DPC… Possible?

 

If so, even if it isn't era-authentic, it would be easier for the DPC+ to drive itself since it's an ARM emulating the original DPC anyway.

[phoenixdownita]

We always end up down that rabbit hole, but if I may ask once you start adding extra CPUs, etc.... what's the point?

Literally, what is it that you would like to achieve? And also why?

 

There's zero SW using the DPC on 7800, assuming that once a board has it available would spur tons of homebrew is unrealistic, just trying it to say that it can be done also is a self-serving purpose (big pat on the back and verbal accolade excluded) .... what's left that I don't really see?

 

[my .02$ for example I do not see the point in the 7800 XM of the Yamaha audio chip support but in other 10Y or so I will be proved wrong when there will be 2 homebrew using it (I do understand the presence of Pokey instead), if instead of the Yamaha a full blown playback device a la SD2SNES-MSU1 would be devised then it is something I would understand .... it would allow to "easily" add at least CD quality background music hacks to the games (once a cart with SD support comes out that is), the easier the hacks the more likely they would happen, and an auto audio streaming player would be a nice way to go about it]

[rockman_x_2002]

There's zero SW using the DPC on 7800, assuming that once a board has it available would spur tons of homebrew is unrealistic, just trying it to say that it can be done also is a self-serving purpose (big pat on the back and verbal accolade excluded) .... what's left that I don't really see?

 

This is the largest issue I tend to think of when it comes to things like this, even though having a working DPC solution would be interesting from a developer's point of view (myself being a software developer, but not necessarily a 7800 programmer).

 

The approach of building hardware in anticipation that homebrew developers will want to use it is a sort of "If we build it, they will come" type mentality. It's fine, except the problem is you're building a piece of hardware that developers now have to figure out how to use. The problem is, you may be missing features that developers would be knowledgeable about and would be handy to use, but because they are not present, it causes developers to have to somewhat shoehorn a less-than-ideal solution into the mix that may or may not work (I run into this often when using third-party API libraries that kinda-somewhat do what I want, but not just exactly quite, and I always end up having to develop some sort of shim to make up the difference, and that shim is often more difficult to come up with than if I'd just done the darn thing myself).

 

To that end, a much more reasonable approach would be for a develop to come up with the idea for a game, with features that may or may not be available on a stock 7800. Then, the developer needs to sit down and make a list of the missing features that are necessary to make the project complete. From that list, contact someone familiar with hardware development, and create a project that can collaborate on that one particular game. In doing so, you'll be able to fail fast, come up with gotcha scenarios that might be missed if either the software or hardware is developed independently from one another, and there's a far better chance that you end up developing a hardware solution that other developers would find easy to use, because not only do you have the hardware available with excellent documentation, but you also have an example game that shows how to utilize it. Hardware developed like this, where the actual software development is the impetus behind the hardware's design, seems to be far more successful.

[phoenixdownita]

... a much more reasonable approach would be for a develop to come up with the idea for a game, with features that may or may not be available on a stock 7800. Then, the developer needs to sit down and make a list of the missing features that are necessary to make the project complete. From that list, contact someone familiar with hardware development, and create a project that can collaborate on that one particular game. ....

Albeit a reasonable approach, given the game itself is then the focus why not at that point make it for a console that already supports those extra features?

I mean one would not develop a new game for the 7800 with the intent of needing HiDef support, right?

Audio being such a sore spot I guess I'm more open to "cheap" improvements in that area (hence the MSU-1 kind of suggestion, or any automatic mod-player, WAV-player or what have you).

[rockman_x_2002]

Albeit a reasonable approach, given the game itself is then the focus why not at that point make it for a console that already supports those extra features?

I mean one would not develop a new game for the 7800 with the intent of needing HiDef support, right?

Audio being such a sore spot I guess I'm more open to "cheap" improvements in that area (hence the MSU-1 kind of suggestion, or any automatic mod-player, WAV-player or what have you).

 

I can totally understand, and I 100% agree that the 7800 does need some boost in the audio department, whether that's through POKEY, HOKEY, or some other solution entirely.

 

As for the reason why you might develop a game for the 7800, given the 7800 doesn't have the features you might desire? The reasons are actually myriad. Chief among them, as a hobbyist developer, might simply to be to see if it can be done. Recall that in the early days of computing, that "can-do" spirit led to a number of innovations that furthered the computing industry, namely by producing hardware that supplemented the computers that were already present. In that case, the base computer was a good start, but perhaps what was needed was a simple enhancement or two. It would be silly to scrap the entire system and simply design a whole new system from the ground up that offered little more than a few simple improvements.

 

Of course, if you were talking about developing a game from the usual publisher's standpoint of today, developing for the Atari 7800, and indeed developing for any console older than the current generation of consoles, would be ludicrously silly. But for those of us that are in this hobby, that's not the case. It's impressive to see a game come out on a platform with features that would have made our jaws slam thunderously to the floor back in the late 80s. I think for developers working on systems like the 7800 and other retro platforms, it's just the thrill of working with that hardware, trying to see what can possibly be squeezed out of the hardware, and then how improvements could be made that further extended the hardware capabilities of the system.

 

A prime example of this practice in action is the NES. Consider that the base system was actually quite limited, and it was the introduction of memory management controllers in the system's cartridges that really made the system capable of doing so very much more than it would've done straight out of the box. However, it was often the case that a game's design was laid out first, then a search for existing MMCs was done to see if the game could be matched up to spec with something already in existence. If an appropriate MMC couldn't be found, then that prompted the development of a brand new MMC with all the necessary enhancements, with an eye toward future-proofing by adding features that other developers might find a good use for. At least, that seems to be the usual development cycle for a large majority of the titles that came out for the NES.

[Lynxpro]

We always end up down that rabbit hole, but if I may ask once you start adding extra CPUs, etc.... what's the point?

Literally, what is it that you would like to achieve? And also why?

 

There's zero SW using the DPC on 7800, assuming that once a board has it available would spur tons of homebrew is unrealistic, just trying it to say that it can be done also is a self-serving purpose (big pat on the back and verbal accolade excluded) .... what's left that I don't really see?

 

 

 

1. If possible, an extra CPU that could drive a DPC would remove a potential processing bottleneck for SALLY and opening up the possibility of using the DPC/DPC+ for 7800 games.

 

2. 6502s are readily available. They aren't going anywhere since they're still being produced, unlike POKEYs.

 

3. There's a finite supply of POKEYs left and 7800 fans have to compete with Atari 8-bit computer fans, 5200 fans, and Atari arcade game fans for the leftovers. Just one "Quad POKEY Eliminator Board" used for a few different Atari coin-ops removes 4 POKEYs from that available supply.

 

3. The HOKEY isn't finished. The DPC+ is.

 

4. DPC+ development is happening on the 2600 side of our homebrew hobby.

 

5. It's possible since the DPC+ is ARM-based, it can handle it's own management of the "DPC" aspects w/o the need of a separate CPU. That isn't exactly time period authentic but it's a practicality.

 

 

Can I make that any clearer?

[Jinks]

 

Can I make that any clearer?

What were ya sayin again?

[RevEng]

The reason DPC/DPC+ require so much work is they are designed to work around the 2600's lack of sound input in the cart slot. The 7800 doesn't have this limitation, so it's just a poor match. Even if we throw in an extra CPU, then we have to include some kind of communication interface between the main 6502 and the ancillary one, and an additional EPROM for the ancillary CPU code.

 

It would be far easier to just use an existing sound chip design that doesn't need babysitting. There's no reason why the 7800 can't use a SID, General Instruments AY soundchip, custom microcontroller, or a bunch of other off-the-shelf solutions. The reason programmers haven't done this is due to nostalgia and convenience (the latter being the availability of carts designed to work with POKEY, and the ability to test code in emulation).

 

It's also worth mentioning that DPC generally sounds fuzzy, due to the low sample rate and resolution. I personally prefer a more natural TIA sound, where the composer has pulled a trick or two to make the song sound in-tune.

[Trebor]

It would be far easier to just use an existing sound chip design that doesn't need babysitting. There's no reason why the 7800 can't use a SID, General Instruments AY soundchip, custom microcontroller, or a bunch of other off-the-shelf solutions. The reason programmers haven't done this is due to nostalgia and convenience (the latter being the availability of carts designed to work with POKEY, and the ability to test code in emulation).

 

It's also worth mentioning that DPC generally sounds fuzzy, due to the low sample rate and resolution. I personally prefer a more natural TIA sound, where the composer has pulled a trick or two to make the song sound in-tune.

 

Concerning adding sound chips, the 7800 having audio out on the cart line makes it designed more like the Famicom and less like NES respecting sound expansion. While Nintendo capitalized on expanding the Famicom sound (Including the YM2413 derivative - Konami VRC7), Atari did next to nothing with the 7800, unfortunately. Indeed, it does mean programmers can do it now though.

 

Perhaps in making and getting the most out of TIA, we need tools and clear explanations - with examples - on how to better utilize TIA sound.

 

*EDIT: Can't forget the tricks...

 

https://www.youtube.com/watch?v=0zCm1_5nYIU

 

Something up this sleeve [*Edit 2 - Electric Boogaloo: Nope, that's POKEY; try the other sleeve instead].

[RevEng]

Thanks for the mentions, Trebor. I think that first sleeve has a POKEY up it, but that second sleeve is all TIA goodness.

[Trebor]

Thanks for the mentions, Trebor. I think that first sleeve has a POKEY up it, but that second sleeve is all TIA goodness.

 

Right you are...That sleeve was actually labeled EVIL sleeve. Due to it being so tricky...

Going to re-edit the post to avoid confusion.

[phoenixdownita]

If I may, wrt running out of Pokey(s) and having Hokey not ready:

 

Kevtris seems to have the music part of Pokey ready (to say the least).

I'm pretty sure he could whip up a Pokey on a small FPGA and solve the apparent supply issue if he so chose.

I can't say but I would be surprised if the Pokey chip alone takes more that 5K-8K LEs (and there are quite a few cheap FPGA in that ballpark) , foft also has a fully functional Atari 800 FPGA core hence he has a Pokey subsystem in there too, heck assuming it's less than half the LEs I am guestimating it can be a dual pokey configuration in the same FPGA.

 

So I believe that will solve itself magically, $$$ goes in, Pokey comes out as simple as that.

[Lynxpro]

The reason DPC/DPC+ require so much work is they are designed to work around the 2600's lack of sound input in the cart slot. The 7800 doesn't have this limitation, so it's just a poor match. Even if we throw in an extra CPU, then we have to include some kind of communication interface between the main 6502 and the ancillary one, and an additional EPROM for the ancillary CPU code.

 

It would be far easier to just use an existing sound chip design that doesn't need babysitting. There's no reason why the 7800 can't use a SID, General Instruments AY soundchip, custom microcontroller, or a bunch of other off-the-shelf solutions. The reason programmers haven't done this is due to nostalgia and convenience (the latter being the availability of carts designed to work with POKEY, and the ability to test code in emulation).

 

It's also worth mentioning that DPC generally sounds fuzzy, due to the low sample rate and resolution. I personally prefer a more natural TIA sound, where the composer has pulled a trick or two to make the song sound in-tune.

 

Well, that explanation really brings it home on why not to use DPC/DPC+ for 7800 titles. What a shame.

 

Problem with the SID is, it's even more finite than the POKEY because of so many enthusiasts already scavenging for them for SID Station-esque hardware for music production, not to mention C64 fans using them for replacements or Dual SID stereo mods. There might even be some Plus/4 SID mods out there too. Not to mention, you'd be soiling Atari gear by using a Commodore sound chip in it. I kid, I kid. I'd respect such an endeavor though just for the hell of it.

 

As for the AY solution, I don't understand why some people like it so much. Slap a Yamaha name on it and you've got the hated YM2149. You'd be cramming in Apple II Mockingboard/Spectrum/Atari ST audio into a 7800 game. But, it would be better than TIA alone. Come to think of it, the AY was used in non-Atari arcade games, and if I recall, the Intellivision and Colecovision [or some variant of the chip]. And I guess if you took the Mockingboard audio from Apple II Karateka and added it to 7800 Kareteka - and fixed the controls - you'd have a much better port. But you'd probably need 2 AYs/YMs to get it to sound the same. I've seen a Dual AY/YM mod board for the Spectrum but so far, nobody's produced one for the ST that I'm aware of.

 

Since you brought up AY/YM - and not the YM2151 - what about using the Atari STE's DMA sound chip? I think that was a GI product and never actually meant to be used for those purposes. Still, for those that know how to use it, I think the sound quality itself is better than the Amiga's PAULA. But is a DMA sound chip a good idea for an 8-bit platform? And would you still need an AY/YM to be used in conjunction with it?

[phoenixdownita]

What now?

Given that the 7800 has an audio line in the cart slot you can cram in there anything you want and have it mixed.

 

Also regarding SIDs, by some estimates they sold 18M C64, that is enough supply for the homebrew we are talking about here and for potentially the complete 3M 7800 sold.

 

EDIT: also according to

https://en.wikipedia.org/wiki/General_Instrument_AY-3-8910

 

"The chips are no longer made, but a declining stock is still obtainable for servicing vintage machines. A VHDL equivalent description has been written, for use in FPGA recreations of arcade machines and others like those mentioned above. The VHDL source code is available on the Internet, and compiles to fill about 10% of a Xilinx XC2S300 FPGA."

 

Via http://www.xilinx.com/support/documentation/data_sheets/ds077.pdf page 3

the XC2S300 at 300K gates is equivalent to 7K LEs/LCs (modern unit of FPGA size).

If we are to believe Wikipedia the AY-3-8910 description uses ~10% of that -> less than 1K gates -> plenty cheap FPGA that can host that.

 

(given this data I believe the Pokey [music portion at least] to be around the same complexity, maybe 2x)

[Lynxpro]

If I may, wrt running out of Pokey(s) and having Hokey not ready:

 

Kevtris seems to have the music part of Pokey ready (to say the least).

I'm pretty sure he could whip up a Pokey on a small FPGA and solve the apparent supply issue if he so chose.

I can't say but I would be surprised if the Pokey chip alone takes more that 5K-8K LEs (and there are quite a few cheap FPGA in that ballpark) , foft also has a fully functional Atari 800 FPGA core hence he has a Pokey subsystem in there too, heck assuming it's less than half the LEs I am guestimating it can be a dual pokey configuration in the same FPGA.

 

So I believe that will solve itself magically, $$$ goes in, Pokey comes out as simple as that.

 

Nice. Interesting how Sculptured Software was able to get POKEY-esque sound out of the TIA for the title screen for Fatal Run. Sounds very similar to their 7800 Commando work. Just imagine how it would sound if they could've done POKEY+TIA with it like they did with Commando. Although Fatal Run seems to be in a halfway-house between Road Blasters and Battlewheels. But I digress.

 

Now if we're going to talk about using FPGA, then what about using a PIC? I can't remember the specific Youtube video but there's one out there that can already do Quad POKEY and Dual SID. Use one of 'em and we can have Atari-arcade quality audio on a 7800 as Atari Inc/Corp should've done in the first place.

[phoenixdownita]

Alright then, we're back at using Pokey for 7800.

 

EDIT:

that emulation via PIC is here:

http://atariage.com/forums/topic/199245-atari-pokey-8-bit-computer-sound-on-pic32/

 

EDIT2:

my remarks on the FPGA being small is because yuo can find 1K LE FPGA for around 5US$ .... so indeed a very cheap solution.

Likely a SW EMU on a PIC32 is more expnesive as the PIC32MX795F512H used there is 10US$ .... pretty sure it can be simplified a lot (no need to emu a 6502) and a cheaper replacement can be used.

 

EDIT3:

the issue stays the same as I am not making one of those thing (not sure if you are), someone is working on the Hokey, Pokey is on the XM and if kevtris ever makes his Z3000 he can enable quad Pokey or whatever he wants. I think I'm covered.

[i have to admit that I am a little sarcastic because once I "felt" the difference between a stock US SMS and the Jap SMS with FM support I was very underwhelmed .... so I'm fine either way if only the existing games were not so much out of tune]

[Lynxpro]

What now?

Given that the 7800 has an audio line in the cart slot you can cram in there anything you want and have it mixed.

 

Also regarding SIDs, by some estimates they sold 18M C64, that is enough supply for the homebrew we are talking about here and for potentially the complete 3M 7800 sold.

 

EDIT: also according to

https://en.wikipedia.org/wiki/General_Instrument_AY-3-8910

 

"The chips are no longer made, but a declining stock is still obtainable for servicing vintage machines. A VHDL equivalent description has been written, for use in FPGA recreations of arcade machines and others like those mentioned above. The VHDL source code is available on the Internet, and compiles to fill about 10% of a Xilinx XC2S300 FPGA."

 

Via http://www.xilinx.com/support/documentation/data_sheets/ds077.pdf page 3

the XC2S300 at 300K gates is equivalent to 7K LEs/LCs (modern unit of FPGA size).

If we are to believe Wikipedia the AY-3-8910 description uses ~10% of that -> less than 1K gates -> plenty cheap FPGA that can host that.

 

(given this data I believe the Pokey [music portion at least] to be around the same complexity, maybe 2x)

 

Although there's probably more casual Atari enthusiasts out there still - thanks to the nostalgia around the 2600 - there's probably a lot more rabid Commodore fans out there. If they catch word Atarians are cannibalizing C64s for SIDs for use in Atariland, they might start competing against us for 7800 Ballblazer carts on eBay. I don't want to see that happening. Seriously. Sure, it makes no sense monetarily-speaking, but neither did their fandom back in the day either.

 

We Atarians are the Cheers gang and they're still the Gary's Old Towne Tavern folks.

[Lynxpro]

Alright then, we're back at using Pokey for 7800.

 

EDIT:

that emulation via PIC is here:

http://atariage.com/forums/topic/199245-atari-pokey-8-bit-computer-sound-on-pic32/

 

That's right…a PIC32. I swear I've seen it do Atari arcade Quad POKEY Star Wars. But then again, can it be done on-the-fly while playing an actual game?

 

Hey, if someone can get DPC/DPC+ running on the 7800, by all means. It appears it would be quite a hack to accomplish that would deserve plenty of praise. It would open up usage to yet another sound chip - a time period authentic one at that - and I don't hear a lot of difference between the DPC sound of 2600 Pitfall 2 and POKEY Pitfall 2 via Atari 8-bit/5200. Maybe I should play them back again just to be sure.

[CPUWIZ]

You guys understand that both the HOKEY and DPC+ is implemented via an ARM CPU, right? Fred just needs to finish the limited implementation and have them made, just like he did with the DPC+ implementation.

[+DrVenkman]

You guys understand that both the HOKEY and DPC+ is implemented via an ARM CPU, right? Fred just needs to finish the limited implementation and have them made, just like he did with the DPC+ implementation.

 

 

That's interesting. For some reason, I thought HOKEY was based on an FPGA core and the fact that it's not "done" was due to cost of the FPGA more than anything. I'm glad I was under a misapprehension - ARMs are cheap! Unfortunately, Fred's time is limited and he's got multiple things going on (*cough* Concerto *cough*).