Could the 8-bit chips have had a place in the ST?

[kool kitty89]

http://www.atariage.com/forums/topic/173474-could-the-8-bit-chips-have-had-a-place-in-the-st/

 

Posted this on the ST forum a while back and didn't get any takers. Perhaps someone on this forum might be interested.

I was thinking purely in respect to making use of some of the A8 (or even VCS) custom/support chips in the ST design (at practical cost with potential advantages in some areas) and not in the context of a backwards compatible successor to the A8. (in the latter case you'd probably want to push more for a double clocked A8 chipset with 3.58 MHz 6502, double res versions of GTIA modes if not more color indexing capabilities, etc)

 

Would it have made sense for Atari Corp to make use of the existing Atari Inc custom and off the shelf support chips being stocked/produced for the VCS and A8 for the ST arhitecture in place of some/all of the off the shelf support chips used?

 

Ie could one (or multiple) POKEY, RIOT, PIA, 6507, or 6502C chips have been useful and cost effective (taking licensing/IP ownerships/existing stock into account) in the roles of the ST's ACIA, MC68901, YM2149, HD6301, etc?

 

In those terms it seems like the 6502C+RIOT and dual POKEYs would cover most of the functionality of the 6301, ACIAs, and YM2149 do and other things they don't (with POKEY and RIOT you've got a lot of timers to use -more than the 68901 and 6301 offer, more audio capabilities and linear DACs, possible use of POKEY's Sertial I/O though I'm not sure if that could be used for MIDI and probably wouldn't be useful for RS232 -potential for an SIO based interface though, plus POKEY's ADC capabilities though they may not have been useful at all -not sure if the POT inputs would be fast enough to be useful for digitizing audio: if anything it would obviously be using the fast POT scan mode for up to 15.7 kHz 8-bit recording -though without an 8-bit DAC you'd have no way to play it back internally at full quality).

 

In addition to the initial cost factors, there's also the potential to consolidate any of the custom/licensed chips later on (which wouldn't be possible with off the shelf chips -without additional licensing), and short of that they could have used cut-down packages for any ICs that didn't need the full original functionality. (though without shrinking the dies, you probably couldn't go below a 24-pin wide DIP for any of the chips as anything below that drops to narrow DIPs -POKEY would be an obvious one to cut down if certain things weren't used, especially given you'd likely be using dual POKEYs -even if the analog ports had some use you'd likely only need one or 2 per chip among other things)

 

If you happened to have a 2 MHz 6502 and at least one POKEY onboard and the 6502 wasn't monopolized by I/O duties, that could have also made for a very useful route for PCM playback using POKEY's DACs and interval timers (or using software timed PCM, but 650x ints are fast in any case) and allow use of 4-bit multi-channel PCM independent of the 68000. (not Amiga quality, but a reasonable approximation and with independent channels you could control pitch purely via playback rate rather than scaling/resampling to a common output and probably competitive with if not superior to the software MOD players seen on the vanilla ST -resolution limited to 4 bits per DAC but potential for higher rates and lack of artifacts from mixing and conversion to YM audio) Of course, to make the 6502 useful for such, you'd need access to main RAM and not just the RIOT scratchpad or hardwired ROM as the 6301 had. (unless the 6301 already does have access to main memory)

 

 

 

If any of that was possible or attractive from an engineering standpoint for the ST, perhaps it would still have been impractical in the context of the ST/RBP's development state by the time TTL bought Atari's consumer properties in '84. (otherwise perhaps it was never seriously considered due to tunnel vision on completing the existing design as planned)

[sloopy]

the sio bus on the A8 is very similar to rs232 (19.2k bps) but uses different voltage levels (SIO- 5v/0v RS-232- +12v/-12v), and has a command line... this is why the sio2pc is such a simple circuit... and as for MIDI, its similar too running at 31.xk baud (iirc...)

 

the biggest issue with using Pokey in the ST, was system clock speed... fastest Pokey's max out at 2Mhz, where the ST is 4 times that...

 

one thing on the ST, it should have been a 68010 ran at 10Mhz minimum from the start... would have given it a significant speed advantage over other 68000 systems of the time... also a Unix like multi-tasking OS, and it would probably have been much more popular then it was...

 

sloopy.

Edited December 8, 2010 by sloopy

[Rybags]

Said it countless times, Pokey does better audio than the YM.

 

But, that would be about the only use for Pokey, aside from maybe the Pot inputs.

 

Pokey SIO possibly no good for RS-232, the voltage levels aren't right, although does ST use a seperate level convertor chip?

 

Keyscan all well and good, but multiple keys can't be done, and requests for scanning a single key can't be done.

 

Antic and GTIA are pretty much limited by the graphics architecture they provide and wouldn't have worked.

 

TIA or RIOT - why bother?

 

Pokey could have worked with a clock divider, so there's 2 MHz. Although not sure if interfacing to the 8 MHz 68K bus is that simple.

[Bryan]

Typically, you do need a level converter like the 1488 & 1489 even with stand-alone UARTS.

[kool kitty89]

the sio bus on the A8 is very similar to rs232 (19.2k bps) but uses different voltage levels (SIO- 5v/0v RS-232- +12v/-12v), and has a command line... this is why the sio2pc is such a simple circuit... and as for MIDI, its similar too running at 31.xk baud (iirc...)

 

the biggest issue with using Pokey in the ST, was system clock speed... fastest Pokey's max out at 2Mhz, where the ST is 4 times that...

Clock speed is easy, just a 4 or 5 divider for 2 or 1.67 MHz (depending on the speed you want for POKEY you might have the 2 clocked differently too -for sound purposes alone they had 1.25, 1.5, and 1.79 MHz used in the arcade, but speed of the I/O and possibly key scanning would also matter).

 

Even without the original chip designers, maybe Atari Corp's existing engineering staff could have tweaked POKEY enough (either on chip or at least with a bit of external circuitry) to make it completely usable for MIDI and RS232.

 

As it was, the ST is full of chips at varying speeds and a good chunk of glue logic (the GLU) sticking it altogether. The 6301 should be either 1 or 2 MHz and there's a variety of other support chips that I suspect would be much slower than the 68k.

 

one thing on the ST, it should have been a 68010 ran at 10Mhz minimum from the start... would have given it a significant speed advantage over other 68000 systems of the time... also a Unix like multi-tasking OS, and it would probably have been much more popular then it was...

Why the 68010? It's barely any more useful (other than the MMU interface and slight boost for prefetch looping) and was far less readily available from 2nd sources. A faster plain 68k would be a better option, but that would conflict with the simple interleaved DMA used with DRAM (single bus, single bank, no fast page mode) and to manage 8 MHz interleaved they were already using faster memory than the Amiga (250 ns random accesses rather than 280 ns) and 10 MHz would need 200 ns random access times (so something around 100 ns CAS). It might have been doable, but there's a lot of more practical things that could have been done first: packed pixels on the SHIFTER would have been nice though with some other trade-offs in flexibility (actually a lower res 4 MHz dot clock mode would have been nice too, just for less resource usage), but V/H scroll registers to the SHIFTER would be the first thing to change in that respect. But on that side of things, we've already got this ongoing discussion:

http://www.atariage.com/forums/topic/171509-were-the-atari-sts-big-for-gaming-or-just-the-8-bit-line/ -the topic at hand is tangent to most of those points aside from the sound hardware. (for 1984, the YM2149/AY8910 was really the best off the shelf sound chip on the mass market -and Yamaha's FM chips didn't even appear until 1985 with the YM2151 and YM2203 -the latter fully compatible with the 2149 but adding 3 4-op FM synth channels; and of course the YM chip also added necessary I/O capabilities similar to that of PIA; but the context changes when you take Atari Inc into account and the RBP/ST design may have been moving fast but it was still being engineered for a good while after Atari Corp was formed)

 

 

 

Said it countless times, Pokey does better audio than the YM.

 

But, that would be about the only use for Pokey, aside from maybe the Pot inputs.

What about use of the interval timers?

 

Keyscan all well and good, but multiple keys can't be done, and requests for scanning a single key can't be done.

How were multiple key presses handles on the A8? (combined use of POKEY and GTIA select lines? -in that case you'd need some added parallel I/O lines used in conjunction with POKEY for all second function/combination keys)

 

Antic and GTIA are pretty much limited by the graphics architecture they provide and wouldn't have worked.

I only mentioned that briefly in the context of that being a separate discussion and the video chips in this case obviously not meshing with the ST architecture. (expanding the A8 line itself would be another matter, and having double dot clocked modes of modified GTIA+ANTIC would probably be one of the first things -perhaps with 16 color registers and full use of the GTIA palette, though added color indexing/CRAM usage would be even more useful -enhancing sprites would be another matter and that takes a lot of silicon relatively speaking) But again, that's a separate discussion from what I had intended.

 

TIA or RIOT - why bother?

Not TIA, PIA and RIOT, and for general parallel I/O and also for the scratchpad and timer in RIOT's case.

I listed the support chips with potential for displacement above in my quoted topic post from the other thread:

Ie could one (or multiple) POKEY, RIOT, PIA, 6507, or 6502C chips have been useful and cost effective (taking licensing/IP ownerships/existing stock into account) in the roles of the ST's ACIA, MC68901, YM2149, HD6301, etc?

 

Even if using the Atari chips meant using more board space initially, they had the advantages of existing stock, existing supply chains, and in several cases owning the IP or already owning a license for the chips, so it would cut out a lot of overhead compared to buying fully off the shelf chips. (still have chip vendor costs compared to CBM's in-house chip fabs though)

RIOT is more interesting than PIA because of the interval timer and scratchpad. (the 6507 would probably be too limited to be really useful with the small address rage and lack of interrupts) But in the long run, all the licensed and custom chips had the potential for further consolidation on top of the other advantages and unlike the off the shelf chips the ST was using. (initial modifications could have simply been to cut down 40 PIN DIPS to 28 or 24 -maybe 32- pins with dropping unnecessary features but otherwise leaving the silicon the same internally, actual re-engineering and consolidation of the chips would come later)

 

I think the 68901 may have been the only one among those to use glueless logic to interface with the 68k, but I'm not positive.

You've got a list of features with those chips that could largely be displaced by the existing Atari ones, or at least it seems that it could have been possible in a number of cases. (and in the case of the 6301 you've got a bus interface similar to the 6502 already, hence why I suggested using a 6502C as the I/O manager instead, and in either case, if there's enough CPU time left over after I/O duties -talking about a 2 MHz 6502- you could do some neat tricks with POKEY including 4-bit PCM playback and sample synth, though that would also mean some sort of DMA to main memory to read samples or dedicated work RAM beyond a tiny scratchpad such as RIOT offers -the 6301 might have been useful for some of that as it was, but wasn't configured in a manner to facilitate such including access to main RAM, plus the YM doesn't offer as much support for PCM playback as POKEY does with the linear DACs and interval timers)

For PCM support, maybe they could have even used a playback routine held in ROM (along with I/O routines) so main RAM access would only be needed for data.

There were MCU versions of the 6502 available, but that wouldn't tie into the premise of using in-stock and licensed Atari parts. (not positive Atari Inc had actually licensed the IP for the 6502C or non)

 

Pokey could have worked with a clock divider, so there's 2 MHz. Although not sure if interfacing to the 8 MHz 68K bus is that simple.

Again, you've already got a mess of chips in the ST that aren't that straightforward to interface, but most of that is taken care of with the GLU. (obviously a hypothetical ST using some different support chips would thus have differences in the GLU)

 

 

 

One possible issue was that all the old chips were NMOS and on relatively large dies (for 1985), so power consumption may have been notably higher than with the existing chipset. (then again, Atari chips were already generally running at lower voltages than some competition -fully 5V iirc vs stuff like the C64 with some 12V chips and multiple voltages used for different components) That would have been mitigated later on with die shrinks, consolidation, and reengineered CMOS components.

 

 

 

 

On another note, AMY probably wouldn't have been a cost effective solution in the state it was in in 1984/85 unless Atari Corp was willing to put it only in certain models and add a bit more to expansion capabilities on the ST to facilitate a plug-in add-on. (though the latter would be something the ST could have used in general... a decent multipurpose expansion port would have been a lot nicer than the cart slot)

 

 

 

 

EDIT:

I forgot about the 68000's 6800 interface protocol support... so the 6301 and MC6850P may also have been glueless. However, with the similar bus design of the 6502 and 6800 CPUs, perhaps that would have facilitated general use of the 6502 and compatible peripherals in a similar manner with minimal added logic. (the 6502 using little endian byte organization may have complicated things compared to the big endian 6800 and 68000, though that would only even come into play when working with 16 bit words rather than 8-bit)

Edited December 8, 2010 by kool kitty89

[Bryan]

If the A8 chips were not well suited for interfacing with a 68000 based machine then I suspect there would have been little incentive to rework them, especially when the engineers Jack brought over were probably not familiar with them anyway. Heck, when you consider that Atari hadn't improved their design in years, I doubt there was anyone left who could have reworked them more quickly than just starting over. I hate that YM chip with a passion, but I bet they only cost Atari pennies a piece.

[Rybags]

On the A8, there's just the one keyboard matrix. I believe the 5200 has multiples selected by GTIA CONSOL bit outputs.

Keyscan time running at 1.25 MHz or whatever wouldn't be an issue. Pokey scans one key every 114 cycles anyway (not sure, but it might take 2 passes over all keys to get a valid scan). Even if that's the case, it's scanning the entire keyboard at least twice a frame anyway.

 

The other problem that arises - Pokey can only scan 64 keys (8x8 matrix), so you'd need at to divide the keyboard into multiple matrixes anyway. On top of that, you also need the two multiplexor ICs.

 

PIA - it's just a parts bin special. For the same footprint you can use a CIA which gives Timers, self-generated Interrupts, clock and the like. PIA in some ways is a step down from a RIOT.

 

I think part of the logic in going with the YM was to differentiate the ST sufficiently from the A8. And of course, the I/O capability meant it was performing multiple roles.

Edited December 9, 2010 by Rybags

[UNIXcoffee928]

The MC68000 has the built-in ability to interface with both the 6502 & the 6800 8-bit CPUs. This is done via VPA, VMA, and E, on the CPU.

 

Incidentally, these signals are available to the outside world on an Amiga 1000, via the 86-pin connector, so chances are that if you run the A1000 as a TOSbox with KickTOS, it would be fairly easy to experiment. Though physically present, AmigaOS considers them illegal, with regard to Zorro interfacing, however it may be a different story under TOS, and worth a try, if you have a 1000 lying around. The later systems have Kickstart in ROM, so I don't know of anyway to run KickTOS on them, unless someone made an EPROM. Support was dropped totally on the 3000 & 4000 when they switched to the Zorro III standard.

 

Here's a few web references:

 

 

Synchronous Bus Control

This group of signals is provided to give the 68000 the capability to control older 6800 peripherals.

 

Three control signals are included in this group:

VPA* (Valid Peripheral Address)

VMA* (Valid Memory Address)

E (Enable clock)

 

VPA*:This input informs the 68k that it has addressed a 6800 peripheral andthat the data transfer should be synchronized with the E clock.

 

VMA*: The synchronization of the data transfer with the E clock isindicated by the VMA* output, which goes low in response to theassertion of VPA* by an addressed peripheral. (VMA* basically informsthe peripheral that there is a valid address on the address bus).

 

E : clock used to generate the proper timing signals for 6800 peripherals,

derived from the 68k's clock by dividing it by 10.

 

----

the68000 is asynchronous in operation; it will not terminate any bus cycleuntil it recognizes that data transfer is complete, which is normallydone by having the memory or peripheral device assert a data transferacknowledge (DTACK). Because not all devices run asynchronously, the68000 has a provision for synchronous devices, particularly thosedesigned for the old 6800 microprocessor. In this case, a line calledvalid peripheral address (VPA) is used instead of DTACK.

 

Whenthe 68000 detects this signal, it replies with a valid memory address(VMA) signal and synchronizes the bus operation to the Motorola 6800 Ecycle.

 

Further info:

http://www.coe.uncc....00/hardware.htm

 

http://www.bighole.n...rog_guide_1.htm

[+wood_jl]

Not sure that POKEY can do *everything* the crappy YM can do. "Music Studio" makes some nice sounds with **APPARENTLY** some programmable ADSR envelope that maybe sounds a little better, as far as sounding a little more like a real instrument. I can try to post some examples. Make no mistake - I think the ST sound chip sucks - but I'm not sure that - by ear - it's 100% entirely inferior. It's deficient - TO BE SURE.

[kool kitty89]

On the A8, there's just the one keyboard matrix. I believe the 5200 has multiples selected by GTIA CONSOL bit outputs.

Keyscan time running at 1.25 MHz or whatever wouldn't be an issue. Pokey scans one key every 114 cycles anyway (not sure, but it might take 2 passes over all keys to get a valid scan). Even if that's the case, it's scanning the entire keyboard at least twice a frame anyway.

 

The other problem that arises - Pokey can only scan 64 keys (8x8 matrix), so you'd need at to divide the keyboard into multiple matrixes anyway. On top of that, you also need the two multiplexor ICs.

I was speaking in the context of using dual POKEYs anyway, so you could have simultaneous use of 2 matrices rather than having to scan 2 banks of keys concurrently. Even if the key scanning capabilities were not useful you could then strip POKEY down to 24 pins (cut out the 8 key scanning lines and 8 POT lines) and still have the SIO UART and interval timer functionality.

 

PIA - it's just a parts bin special. For the same footprint you can use a CIA which gives Timers, self-generated Interrupts, clock and the like. PIA in some ways is a step down from a RIOT.

Yes, definitely go for CIA in that respect, but I was thinking that Atari may have gotten a license to produce either PIA or RIOT themselves... RIOT would be implied by the fact that Atari Inc had been developing the integrated TIA+RIOT+6507 IC (which would also imply they also had a license for the 6502 core), and RIOT is the more attractive choice of the Atari used I/O chips anyway. (CIA does seem like it integrated more features than some of the support ICs the ST actually used though)

 

 

I think part of the logic in going with the YM was to differentiate the ST sufficiently from the A8. And of course, the I/O capability meant it was performing multiple roles.

I think they may have selected the YM2149 or AY8910 prior to entering the deal with Warner in mid 1984 and again, as far as off the shelf sound chips, it was the best option (better sound than the SN76489 and added functionality). That's why I mused earlier that it may have been tunnel vision on completing the ST with the original plans that prevented use of the Atari chips and 6502 support chips in general.

 

I rather doubt it had anything to do with differentiating itself from the A8.

 

 

 

The MC68000 has the built-in ability to interface with both the 6502 & the 6800 8-bit CPUs. This is done via VPA, VMA, and E, on the CPU.

Interesting, thanks, that makes sense (I suspected as much given the 6800 bus support and similarity of the 6502), that probably simplified interfacing of the 6502 (and often POKEY) used on the 68k based Atari Games arcade boards. (POKEY was often used purely for timer capabilities and sometimes DACs iirc, with it being a cheap option due to existing stock from the Atari Inc split)

 

 

 

Not sure that POKEY can do *everything* the crappy YM can do. "Music Studio" makes some nice sounds with **APPARENTLY** some programmable ADSR envelope that maybe sounds a little better, as far as sounding a little more like a real instrument. I can try to post some examples. Make no mistake - I think the ST sound chip sucks - but I'm not sure that - by ear - it's 100% entirely inferior. It's deficient - TO BE SURE.

There's a lot of stuff you can do with software tricks on the AY (just like you have to do for some stuff on POKEY) and for tone generation it's more capable in some respects, but POKEY's noise generation capabilities are more useful. It's notably better than the simpler SN76489 (yes, the Intellivision has superior sound to the CV) and has a wider frequency range than POKEY (12-bit rather than 8-bit without pairing -SN is 10-bit I believe) and noise generation is better than the SN as well... and like the SN and POKEY it can mix/use noise generation along with 3 tone channels (rather than a dedicated channel it mixes to one or more of the 3 tone channels), something the SID was deficient of (you had to relegate one of the 3 channels to noise for that -though for the SN you also had to sacrifice a tone channel if you wanted pitch control over noise).

 

One other thing is the logarithmic volume, but that's double edged: it does allow approximation of an 8-bit (or a bit higher) linear DAC with some tricks, but in all cases needing 3 channels for decent quality (2 is pushing it, 1 is pretty coarse) while POKEY has 4 4-bit linear DACs, and thus 4 hardware channels for 4-bit PCM playback (3 of which have interval timers tied to the playback frequency -not great for the 68k, but great for 6502/6800 CPUs with very fast interrupts) so you could have multiple sample channels with pitch control by varying playback rate rather than resampling and software mixing on the AY. (and at lower rates, 4-bit doesn't sound too bad compared to 8-bit, let alone more aliased pseudo 8-bit of the AY/PSG, and it takes 1/2 the memory of plain 8-bit PCM of the same rate, so even once the difference gets more noticeable -which it does significantly by 8 kHz- you have the advantage of taking up 1/2 the memory so you'd compare that to 8-bit PCM of 1/2 the sample rate)

[Rybags]

Dual Pokeys might have been interesting, and the pin count reduction is a good idea.

 

You could even do the audio circuitry such that there's an option to double the amplitude coming from one of them - hey presto - instant 8-bit digitized sound output.

 

Actually, surprised nobody's tried that on the A8 yet.

[kool kitty89]

Dual Pokeys might have been interesting, and the pin count reduction is a good idea.

Yeah, part of that context was due to the dual ACIAs, but also to the fact that dual POKEYs would be more useful in general.

 

You could even do the audio circuitry such that there's an option to double the amplitude coming from one of them - hey presto - instant 8-bit digitized sound output.

 

Actually, surprised nobody's tried that on the A8 yet.

Hmm, good point, though such a circuit would need to be significantly faster than the playback rate of the PCM stream as you'd have to set each of the 4 channels per chip sequentially, so there's a small amount of error doing that (the same problem with the AY or SN PSG that was minimized by using optimized conversion tabled to get closest to linear steps with pricisly timed updates -so such an optimized table method should also be possible and preferable if the conversion circuit was improactical to make fast enough for desired playback rates). Doing simple pairing for 4+4=5-bit via writing to 1 channel on each chip simultaneously should be possible as such without the additional oversampling or conversion tables though. (just simple 5-bit in to dual 4-bit out)

Such a 4-channel 5-bit mode (or fewer channels with normal 4-bit DAC or chip sound channels used instead) would probably be preferable for in-game usage and general multi-channel MOD and such (where having pitch control via sample rate would be desirable) with the 6502 (if that replaced the 6301) driving playback (with 68k alone it would be much more limited in utility).

Remember that the PC Engine used only 5-bit DACs and software PCM playback (normally using a 3.58, 7.16, or 15.7 kHz interrupt -and the 7.16 MHz 65C02 used meant very efficient ints -7 kHz used only ~5% CPU time) and that at lower rates, dynamic range becomes far less important (at 6 kHz 5 and 8-bit are pretty much indistingushable, by 8 kHz it's noticeably coarser on 5-bit and 6-bit becomes preferable then 7-bit -8-bit doesn't become really preferable until ~16 kHz and then you also have to take memory use into account and comparing potentially higher sample rates at lower res to higher res at similar bitrate). Some PCE stuff even used 4-bit (sometimes with RLE compression) to save space as well.

 

For specific uses, a single 8-bit channel would be preferable of course though. (and in all cases, simple interleaved playback could be used for mixing multiple channels to a single DAC or DAC pair -but all would need to share common sample rates -or possibly other integer divisions of the common output rate, ie 2 samples of one then 1 sample of anothe- and couldn't have pitch controlled via playback rate like a dedicated channel but good for fixed rate streams for sfx, percussion, voice, or longer sampled loops in general) 7.16 kHz 5-bit PCM on the PCE version of Street Fighter II sounds better than the SNES's filtered/interpolated ADPCM (4 kHz?) or plain 4 kHz 8-bit PCM. (the Genesis version of SFII SCE is not representavie of the 4 kHz 8-bit samples being used as Capcom used a very poor playback/mixing routine on the Z80 for the 8-bit DAC... the beta of Sega's unreleased SFII Turbo port is much more representative of even, unfiltered 4 kHz 8-bit PCM)

 

A circuit to do 5-bit to dual 4-bit writes should be a good deal simpler than one doing oversampling and sequential writes to all 4 (dual) channels and given you'd probably only be using full 8-bit in specialized cases

 

If you ket at least one pot line, using the 15.7 kHz fast pot scan mode (if that's tied to the master clock, that would mean it would actually be ~17.5 kHz at 2 MHz- you could use POKEY to digitize analog audio at up to 15.7 -or 17.5- kHz as well), so you could have an 8-bit digital recording mechanism as well as 8-bit playback.

Hmm, did the Amiga have A/D conversion capabilities for such? (and is it at the same rates as PAULA?)

 

 

As to pin reduction, the more features you used, the less you could cut out. If you used all the key capabilites but cut all POTs and SIO from both, that may have allowed 28-pins, but if you used SIO you're definitely up to 32 pins, and unless there's other redundant lines, you couldn't include both SIO and 1 pot line within 32 pins. (maybe have a mini-POKEY A with 1 POT line and mini-POKEY B with SIO, both at 32-pins, or maybe 28 pins for the one lacking SIO depending how many pins are only needed for SIO)

Initially, they'd be using existing stock of 40 pin POKEYs in this context.

 

It's odd that Atari Corp didn't make a mini POKEY as such, even if not used for the ST, it would have made sense for the 7800 rather than only offering full 40-pin POKEYs for games. In that case, they could definitely drop to 24 pins and still have a lot left over since there's no connectivity on the cart slot to make use of the IRQ, analog lines, key lines, SIO, etc, but you couldn't go less than 24 pins without switching to a narrow DIP and I think the old POKEY die was too large for that. (a die shrink could have come later with the necessary investment and thus allow far less silicon to be used -or even less with cutting out the unnecessary IO circuitry- and only an 18-pin DIP by the looks of the POKEY pinout and assuming phi 2, and both A and B clock were needed otherwise you might manage 16 pins)

 

I know GCC had originally planned GUMBY/mini as the add-on chip (among other added products), but Atari Corp wasn't going to shell out more funds for R&D on their budget (especially after the protracted negotiation with Warner over the MARIA IP and development costs), but in that sense it's odd that GCC didn't requist Warner to supply them with the schematics for POKEY to speed up development (re-using the audio block of POKEY, or simply shrinking the entire die and using a lower pin count package -keeping 4 POT lines might be useful given the 2 port design), though they probably couldn't have fit it onto MARIA even with the die shrink. (not sure if the audio block of MARIA was dropped due to time or silicon space constraints though, if the former, POKEY might have addressed that) Hell, even with NO die shrink or modification of the chip they could have cut down to a 24 pin package with 4 pot lines (no SIO or keys) and that might have been enough to make it practical to add to the 7800 PCB itself, or at least fit onto a riser board more easily, or do an actual die shrink and cut the pot lines for a 20 pin narrow DIP -retaining IRQ. (there already was a riserboard used on the intial 7800s, so it would jsut need to be a tad bigger to allow the 24-pin DIP onboard, let alone a 20 pin narrow DIP -or considering other possibilities like using a single 8kx8-bit SRAM rather than the dual 4kx4-bit chips)

 

But now I've goen off topic again.

 

 

 

 

Edit:

Thinking on RIOT/PIA/CIA again, regardless of the advantage of owning the IP, CIA would be a very attractive inclusion and seems like it could have generally replaced the 68901 and done a bit more even (dual timers, dual 16 parallel I/O lines, serial I/O, and handshaking signal generation). And one consideration would be that MOS chips (other than the Commodore specific ones) tended to be very competitive for cost and flecibility of licensing and second sourcing. (so even lacking a license initially, it would have been relatively easy to license later on to facilitate consolidation into custom LSI chips)

A single CIA, a single RIOT, a 2 MHz 6502C, and dual POKEYs might have been enough to totally displace the ACIAs, 68901, and 6301 at a fairly similar footprint (a bit larger initially) but with the advantage of existing components that were being stocked and used for other products and (in several cases) already had the IPs owned or licensed by Atari, so there would have been a definitive cost advantage (probably slight in the short run, but very significant in the long run, especially with consolidation) as well as added functionality.

 

To really make the 6502 useful for driving audio and handling PCM (or even general coprocessing), they would need interfacing to allow access to main memory and it wpuld probably be better to have something more than just RIOT's 128k scratchpad. (4 or 8 k of RAM could displace any needed program ROM too)

Edited December 9, 2010 by kool kitty89

[Rybags]

The 2 chips could be mapped at adjacent even/odd addresses.

 

So, a 16 bit store could set the two AUDC values at once.

[atariksi]

Not sure that POKEY can do *everything* the crappy YM can do. "Music Studio" makes some nice sounds with **APPARENTLY** some programmable ADSR envelope that maybe sounds a little better, as far as sounding a little more like a real instrument. I can try to post some examples. Make no mistake - I think the ST sound chip sucks - but I'm not sure that - by ear - it's 100% entirely inferior. It's deficient - TO BE SURE.

 

In terms of DACs, I think they get more out of the 4-bit DACs on the YM chip because of the higher clock speed of the 68000. But if POKEY were interfaced to 68000 at higher clock rate, it would offer more flexibility as well especially with four DACs. And as UNIXCoffee stated, they do have an 8-bit hardware compatibility interface for 6800 built in so instruction like MOVEP would work with 8-bit chips.

[kool kitty89]

The 2 chips could be mapped at adjacent even/odd addresses.

 

So, a 16 bit store could set the two AUDC values at once.

Yes, you could set the 2 POKEYs simultaneously, but could you set all 4 channels on each simultaneously? (that couldn't be done on the YM and setting all 3 for PCM playback without correction cases added aliasing, oversampling would address that but it wasn't a feasible option for software playback -especially with the 68k's slow interrupts- so the table method using optimized values for sequential updating so that would have been an option too, but with a dedicated IC managing that, you could probably afford to use the oversampling method)

 

Oh, and I didn't notice before, but 8 4-bit channels would only combine to a 7-bit output max, not 8-bit.

 

 

Not sure that POKEY can do *everything* the crappy YM can do. "Music Studio" makes some nice sounds with **APPARENTLY** some programmable ADSR envelope that maybe sounds a little better, as far as sounding a little more like a real instrument. I can try to post some examples. Make no mistake - I think the ST sound chip sucks - but I'm not sure that - by ear - it's 100% entirely inferior. It's deficient - TO BE SURE.

 

In terms of DACs, I think they get more out of the 4-bit DACs on the YM chip because of the higher clock speed of the 68000. But if POKEY were interfaced to 68000 at higher clock rate, it would offer more flexibility as well especially with four DACs. And as UNIXCoffee stated, they do have an 8-bit hardware compatibility interface for 6800 built in so instruction like MOVEP would work with 8-bit chips.

Well, the DACs are totally different. POKEY uses proper 4-bit linear DACs (like the C64 and NES), but the AY8910/YM2149 (and weaker SN76489) use logarithmic steps (base 2 I assume, so each volume step 2x as loud as the one before it -so 0, 1, 2, 4, 8, 16, etc) with 16 steps (so still a 4 bit range).

Now, by themselves, that makes each channel very poor for PCM playback; it's not like signed logarithmic DACs (which are very useful for things like ulaw decoding), but unsigned logarithmic volume. However, when carefully using all 3 channels together with optimized conversion tables to approximate a linear curve, you can take advantage of the wider amplitude range offered by the wider steps and approximate 8-bit linear PCM (or even a bit higher, but the higher you go the more granular the steps get).

A single POKEY otoh only does 6-bit linear PCM using all 4 channels, but can use 4 independent 4-bit channels with linear PCM, or 2 5-bit linear channels as such. And that will be full quality 6-bit/5-bit/4-bit linear PCM, not approximated as the AY/SN do with added aliasing, and depending on the sample rate, you wouldn't even need more than a 4/5/6-bit linear range anyway. (4 kHz 4-bit only sounds slightly worse than 4 kHz 5-bit which sounds pretty much identical to 6/7/8-bit PCM, but the higher the sample rate, the more dynamic amplitude range is useful though using higher res samples always means higher bitrate too so you'd still have trade-offs with things like 8 kHz 4-bit vs 4 kHz 8-bit for 4 kB/s -or 6.4 kHz 5-bit for that matter)

 

 

As for CPU resource, the 68000 is not really good for being dedicated to software PCM playback even if using the stack to simulate DMA (pure interrupts are really bad), but the very fast interrupts of the 6502 (or 6800) makes it very well suited to PCM management via pure interrupts and POKEY is ideal for that with interval timers (with IRQ) tied to 3 of the 4 DACs. That's one thing that makes PCM playback so freindly on the PC Engine/TG-16: you've got a 7.16 MHz 65C02 and 3.58/7.16/15.7 kHz interrupts and the PCE only takes 5% CPU time to drive a 7.16 kHz PCM channel. (that's 50 cycles per sample)

That's why a 2 MHz 6502 would be so useful for managing PCM, or using the 6301 (6800 derivative) for that same purpose, though I'm not sure if it's 1 or 2 MHz. (let alone having it in parallel with the 68k) With a 2 MHz 6502/6800 you've got a lot of resource to work with. (easily enough to drive 4 8 kHz PCM channels via interrupts)

 

Even with the A8's effective 1.2 MHz (due to video DMA), that's a lot of resource, and it's surprising you don't see a lot of 4-bit POKEY MOD player demos around.

 

 

 

 

I'm not a programmer (or not much of one -not at all for the architectures in question), but it's my understanding that the 68k is a far more powerful architecture, but for certain applications the more powerful (and usually slower) instructions are at a significant disadvantage to the simple but fast architectures of the likes of the 650x or 680x families. (things like Z80 or x86 are also often at a disadvantage, though in the specific context of interrupt handling, I think the Z80 and maybe x86 are notable faster than 68k but well behind the likes of 6502) For dedicated game consoles especially, the 6502/6800 archs were rather well suited, though both (more so the 6502 -prior to the C02 or '816 at least) isn't as programmer friendly as other architectures. (more like it's tougher to learn and get good at, but once you're skilled at any of those contemporary ISAs, the difference should be much less significant)

Then you have cases like the 6809/6309 where you sort of have the best of both worlds with a relatively powerful architecture, fast instruction times, fast interrupts, etc. (in that sense, a 6309 probably would have been one of the best CPUs to use on a dedicated game console. (and also much more friendly to inexperienced programmers)

Edited December 10, 2010 by kool kitty89

[kool kitty89]

Oh, I keep forgetting that the AY8910/YM2149 supports stereo too, or rather 3 discrete sound channels (which is one reason why it's important that it can mix noise into any one or multiple tone channels), though you'd have to settle for hardwired stereo (like the Amiga -or what the Amstrad GX-4000 did with the AY8910 with 1 left one center and 1 right channel), or have an external mixing circuit to provide panning. (most applications simply shorted all 3 lines to mono though, including the ST -not sure about the STe, and it was such a little used feature that Yamaha made it's backwards compatible YM2203 mono only -it has all the sound and I/O of the older chip but adds 3 YM2151 or YM2612 style 4-op FM synthesis channels though also requires an external serial DAC -a tiny 8 pin DIP)

[Rybags]

A 32-bit write would only hit 2 pairs of AUDC/AUDF registers, e.g. Pokey 1 @ addresses 0,2,4 etc Pokey 2 @ 1,3,5,7 so you'd need a MOVEM.L to hit all the pairs.

 

The other idea I suggested was in the actual amp circuit - give the second Pokey double the amplitude of the first, so in theory that should mean AUDC1 of Pokey2 in forced output would effectively give you high bits and AUDC1 of Pokey1 would give low bits, so in effect, 4 8-bit digital channels.

 

Best option would be to have a means to turn that amplitude doubling on/off in software so you'd also have the option of 8 voices all at the same levels.

[atariksi]

Even with the A8's effective 1.2 MHz (due to video DMA), that's a lot of resource, and it's surprising you don't see a lot of 4-bit POKEY MOD player demos around.

It's not 1.2Mhz. It depends on the video mode. And if you're thinking about writing to multiple DACs, you also have the ability theoretically to use the fast pot scan as read value to write back to the DAC using INC, DEC, ROL, ROR, LSR, ASL. It has some restricted use. That gives you ability to write 2 different patterns to the DAC in 6 cycles on 6502. All this assuming no analog controller is connected so you can get a deterministic 228 or whatever value.

[+rdemming]

Another thing to consider is the mouse interface. None of the 8-bit chips can track mouse movement independently from the CPU. So on the 8-bit, using the mouse eats lots of CPU time because it needs to read the mouse movement many times per second.

 

On the ST a separate CPU is used in the keyboard that tracks the mouse movement. The 68000 only has to ask the "keyboard" for the current mouse position when needed instead of processing the movement many times per second.

You might say, that they could use a 6502 in the keyboard but that required some additional chips for RAM and (serial) IO that is build-in in the HD6301V1 they now used as keyboard processor. So a HD6301 was probably much cheaper to handle the mouse + keyboard than the chips needed from the 8-bit to do the same thing.

 

Another advantage of using a separate keyboard processor instead of using a Pokey for reading the keyboard, is the serial interface. To get a detached keyboard, you only need a 4 wire cable. When using a pokey, you need dozens of wires for a separate keyboard.

 

Robert

Edited December 10, 2010 by rdemming

[Bryan]

The 6301 wasn't fast enough (or maybe its the code wasn't fast enough) to track the mouse well. I remember the pointer going haywire for people like me who tended to make quick mouse movements.

[kool kitty89]

A 32-bit write would only hit 2 pairs of AUDC/AUDF registers, e.g. Pokey 1 @ addresses 0,2,4 etc Pokey 2 @ 1,3,5,7 so you'd need a MOVEM.L to hit all the pairs.

 

The other idea I suggested was in the actual amp circuit - give the second Pokey double the amplitude of the first, so in theory that should mean AUDC1 of Pokey2 in forced output would effectively give you high bits and AUDC1 of Pokey1 would give low bits, so in effect, 4 8-bit digital channels.

 

Best option would be to have a means to turn that amplitude doubling on/off in software so you'd also have the option of 8 voices all at the same levels.

Hmm, that would be interesting... but would it really be double the amplitude? Doubling that would have the "normal" POKEY at 0-15 in range adding with the doubled POKEY at 0-30 (in 16 steps), but that would only give a maximum range of 0-45 and a lot of redundant values. (so not even 6-bit linear PCM, but more than 5-bit)

If you wanted to use an amplitude offset as such, it would seem like you'd need to use a lot more than 2x, with 16x giving a maximum composite range of 0-255, so exactly 8-bit. (with 0-15 and 0-240 in 16 steps) And you should get a full 256 unique amplitudes as such. (ie each of the 16 0-240 steps of the high POKEY with added 16 0-15 steps of the low POKEY; so 0+0...15, 16+0...15, 32+0-15, etc)

 

However, doing that wouldn't allow practical concurrent use of normal POKEY sound channels or 4-bit DACs on the low POKEY simultaneously. (it would be too quiet to be useful as such, so you'd only have the high-POKEY's channels useful in that mode) In the normal mode with common amplitudes, you's have full use of all 8 channels for 4-bit DACs or chip sound (and with more channels comes more flexible use of the 16-bit frequency range) and you could have 5-bit linear paired support for that mode as well (have the added external circuit support both the high+low amplitude mode and plain common amplitude pairing).

For a lot of stuff, 4 or 5 bits would be fine anyway, so for games and such, that would probably be the mode of choice. (and it takes less memory too, especially 4-bit which is more convenient to pack and can be streamed as 2 words per byte rather than unpacked to sing word 5 bit/byte when streaming -so not only using less space in RAM, but 1/2 the bandwidth for a given sample rate as well)

 

Later on they'd probably integrate the POKEYs+DAC combining circuit (and amplitude divide/multiply circuit -probably makes more sense to divide the low POKEY and thus keep the final output at a common volume range in both modes) into a single IC and maybe even building a DMA circuit once it came to the next model (ie STe), or at least something like a FIFO buffer to reduce the number of interrupts needed. (though with a 650x driving it, that wouldn't be nearly as significant as for the 68k... so not bothering with that and bumping to a faster 650x -probably a 65C02- would make sense, especially with the 4 MHz rated 65C02s being stocked for the Lynx at the same time the STe was released )

 

 

 

 

 

 

Another thing to consider is the mouse interface. None of the 8-bit chips can track mouse movement independently from the CPU. So on the 8-bit, using the mouse eats lots of CPU time because it needs to read the mouse movement many times per second.

Yeah, unless they had made a mouse that used analog control rather than digital pulses. (you could simply use POKEY's pots as such and a mouse driven by 2 potentiometers with position tracking of the mouse, or better, an analog rotary mechanism that was speed sensitive -ie lower resistance at higher rotational speed or vice versa- using plain pots would mean having to use stops and have a somewhat more difficult time managing good speed-sensitive control... maybe some sort of spring loaded system that used rotation to actuate pots that would recenter via springs when rotation slowed or halted) That would give 15.7 kHz in fast POT scan mode (double the rate of the ST's keyboard scanning). However, such a mechanism may not have been as cheap or reliable as a mechanical/optical ball mice using pulses, though a very simple PWM DAC could be used to turn the pulses into analog signals if that was the case. However, with only 8-bit resolution, that would mean somewhat choppy movement for 320x200, or more so in 640x200 or 640x400, so the position tracking pot method would be undesirable, but the speed sensitive mechanism would be useful. (or PWM DAC once optical got cheaper) I believe the Tandy mice (using the Tandy analog joystick ports) were analog as such.

 

On the ST a separate CPU is used in the keyboard that tracks the mouse movement. The 68000 only has to ask the "keyboard" for the current mouse position when needed instead of processing the movement many times per second.

You might say, that they could use a 6502 in the keyboard but that required some additional chips for RAM and (serial) IO that is build-in in the HD6301V1 they now used as keyboard processor. So a HD6301 was probably much cheaper to handle the mouse + keyboard than the chips needed from the 8-bit to do the same thing.

Yes, but I already addressed that: for any one purpose the 8-bit chips (or some others like CIA) may not have looked as attractive, but in the overall picture, comparing all the support functionality and equivalent use with POKEY/6502/RIOT/CIA, it's a different matter. 6502C+RIOT would give all the general functionality of the 6301 except the 4k ROM and only 16 I/O ports to the 6301's 29 (or the 2 data strobes), but then you add the POKEYs, and CIA and displace most of the functionality of the 68901, ACIAs, 6301, and YM2149. (depending how much of the existing functionality was used of those chips, you might need a bit more to totally displace the ST's chips, though that would also depend on how much of the functionality the ST even used and how much was superfluous, but any stuff that wasn't useful on the Atari/MOS chips could have thus had cut pin counts and even more so with later consolidation)

CIA actually adds realtime clock support, something not added to the ST until the MEGA. (I think the Amiga had it from the beginning, not sure about the MAC)

 

The 6301 itself doesn't support serial I/O, that's handled by other chips (other than software polling via the parallel ports), and I believe the 29 parallel ports are multiplexed, so that may have added additional complexity as it was.

 

Another advantage of using a separate keyboard processor instead of using a Pokey for reading the keyboard, is the serial interface. To get a detached keyboard, you only need a 4 wire cable. When using a pokey, you need dozens of wires for a separate keyboard.

Yes, but that also means having an MCU inside the separate keyboard to drive the serial data, etc. Eventually that would become the cheaper option, but a simple keyboard with minimal logic and more wires in the cable may not have been a bad option. (Atari didn't offer models with separate keyboards until 1987 anyway -MEGA and XEGS)

However, if you DID go the pure serial data route, that means you could have more utility with SIO (and you'd have dual SIO with 2 POKEYs) as well as CIA's serial I/O capabilities.

 

Even if you did use the POKEY key scanning externally as well, you wouldn't need dozens of lines, but less than 2 dozen if totally unmultiplexed, but much fewer if some sort of multiplexing was used, let alone if they used a different driver for the external keyboards in general and switched to plain serial I/O for that. (especially given they didn't start offering that until 1987 anyway -but using 2 bank multiplexing it should have been fine with a 15 pin connector or even less, but probably at least 10 pins/wires used -15 pins would allow a common DE-15 port as used for VGA or the STe/Jaguar enhanced joyports)

 

And with many chip IPs being licensed or owned by Atari already, that would cut out overhead and facilitate integration into more compact custom ICs. (CIA wasn't in use by Atari, but even then it probably would have been favorable to license given how most MOS chips were -other than the CBM specific ones, of course) Atari already had RIOT and the 6502 core licensed given they were implementing them in the custom "JAN" single chip VCS (6507 is the same silicon, but fewer external pins).

 

Again I was generally thinking of using some combinations of POKEY(s)+RIOT(s)+6502 and maybe CIA (not already in use, but a very feature rich IC with the same footprint of RIOT or PIA).

If the 6502 was to be multipurpose and more useful than the 6301 (especially for possible audio duties), using a small SRAM chip in addition to the scratchpad in RIOT (or don't bother with RIOT at all, but the existing license makes it attractive). Or do stick with the simple ROM+scratchpad approach, but add audio specific code to the ROM (for PCM playback and some other things), and in either case allow some sort of DMA to main RAM to pull samples from. (a single 8kx8-bit SRAM to work in would probably be useful as such and drop the ROM entirely)

 

 

Not only that, but some consolidation would be even more useful: like a combined RIOT+6502C chip which could also be used in the 7800. (that would be another reason to consider RIOT, not only commonly use for the VCS, but also the 7800 -though late model Jrs were using single chip ASICs already) Technically speaking, they probably could have used JAN with a different pinout (adding the full 6502C functionality) and leaving the TIA block unused on the ST just to standardize manufacturing. (but cut to a lower pin count on the ST specific version and maybe a lower count on the VCS specific version too given the fewer lines than the full 6502 needed for the 7800 -but not as extreme as cutting all of TIAs pins for the ST version) Using TIA for the audio and 2 I/O lines on the ST might have been useful too, but unless the ASIC was ready by the launch of the ST, adding a full TIA onboard wouldn't be worth it.

 

 

 

The 6301 wasn't fast enough (or maybe its the code wasn't fast enough) to track the mouse well. I remember the pointer going haywire for people like me who tended to make quick mouse movements.

For keyboard scanning and MIDI, it was the ACIAs that hard coded the scan rates at 7.8 kHz for keyboard+mouse/joysticks (half of what POKEY does for keys -or fast pot scanning for that matter), and 31 kHz for MIDI, which is a bit more than the normal 19.2 kHz SIO rate. The 6301 probably has little to do with that. (it just reads the output from the ACIAs acting as a controller for the keyboard/mouse I/O subsystem)

 

In the context of the 6301 itself, depending how much CPU time was left after I/O duties, it might have been useful for general coprocessing if it had general access to the main bus and a bit of work RAM beyond 128 bytes. In that context though, with a 6502C, you'd have a 2 MHz CPU rather than 1 MHz and further more it should have been implemented to act as an audio coprocessor in conjunction with the POKEYs as we've been speculating. (for PCM playback and other added software effects for the chip sounds)

 

The general context of this is whether Atari Corp could have efficiently used existing resources to improve on the ST's 1985 capabilities at similar cost. (probably some notable trade-offs for initial production with full POKEYs used and a bit of added logic, but that would partially be countered by existing supplies and owning licenses/IP to many of said chips, but the big savings would come later down the road with consolidation of those already licensed/custom ICs and maybe one or 2 others -like CIA- that could be licensed later on or left intact) As it was, Atari Corp only consolidated the custom chips, none of the off the shelf stuff (which they had no licenses or ownership of) and thus you still have a lot of the same 1985 parts cluttering the motherboard on the late 80s and early 90s ST/compatibles. (some of those chips at least got smaller packages and die shrinks or CMOS versions, but not even that in all cases -many were still full sized DIPs to the end, including the YM2149)

 

 

 

I hadn't considered it before really, but now that I got thinking on it (above), an analog mouse mechanism might have been useful, be it direct analog or using a conventional optical mechanism and a simple PWM DAC onboard to convert it to 2 analog streams to be read by POKEY. (that could have meant using the exact same pinout as the A8/VCS with 2 pot lines)

 

 

And, again it seems an interesting possibility to use a POT input in fast scan mode to do 8-bit 15.7 kHz (or higher if POKEY's fast scan was done asynchronously to the video signal) for digital audio recording would be neat. (especially with 8-bit playback via paired POKEYs as above)

Edited December 10, 2010 by kool kitty89

[Rybags]

Not double... needs to be 16 times.

 

Maybe that's why it's not been done. Plus you don't necessarily get a linear ramp when going through the values.

[kool kitty89]

Not double... needs to be 16 times.

 

Maybe that's why it's not been done. Plus you don't necessarily get a linear ramp when going through the values.

And again, if you wanted to make mixing as simplified as possible, you wouldn't want to have a mode that multiplied the amplitude by 16x, but rather you'd want one that divided the "low POKEY" to 1/16 the normal output such that the master volume of the final output doesn't need to be changed.

 

You'd definitely need to make sure such a circuit was precise and consistent enough to work reliably for providing an 8-bit output. You'd need both the (rather simple) digital circuitry to take 8-bit in and output the appropriate dual 4-bit values to the POKEY pairs simultaneously or the same for 5-bit to dual 4-bit when in normal amplitude mode (you could probably do that reasonably in software, but the circuit should be pretty simple and far more effective than wasting 6502 time on that), but the analog side of things would be a determining factor.

The analog circuit wouldn't be complex, but it would have to be precise and very consistent/accurate to be acceptable as such... or not push so hard for that and have poorer quality playback when that mode was used. (sort of like the lower end homebrew resistor DACs/ladders used for DIY parallel port DAC audio)

 

Regardless, you wouldn't have to worry about the analog issue for the normal (common amplitude) mode pairing to 5 bit. (which again would be the more flexible mode in general with any use of the 8 channels as normal channels, 4-bit DACs, or simultaneous writes for paired channels allowing 5-bit -or normal pairing for 16-bit frequency range) And when pairing for 16-bit frequency range for chip sounds, you'd probably want to favor using the timerless channel as one of the 2 being paired so you don't lose a timer channel.

 

 

 

 

 

On POKEY/A8 in general: am I looking in the wrong places, or are A8 MOD player demos really uncommon? With all the stuff done in software on the ST, Spectrum, etc (even some cases doing primitive sample based stuff via PWM on the speccy!), you'd think that the A8 would have attracted a scene for that with the demoscene that exists for the A8. You have 4 hardware DACs, 3 of which have interval timers that can be used for IRQ output to a very interrupt efficient CPU (and with such a demo you could disable video DMA for closer to the full 1.79 MHz -closer to 1.6 MHz due to DRAM refresh, but better than the ~1.2 MHz with video DMA active).

So that's 3 channels that can have playback rate controlled by integral timers driving interrupts and one channel left over that you'd probably leave for general chip sounds. (you could have 2 channels tied to one common timer, but it would make more sense to double the rate of a single channel for interleaved playback if you were going to play at a common frequency rather than waste a channel as such)

So all the CPU does is handle interrupts and manage looping times to correct for variable playback rate (for pitch control like most Amiga MOD uses on the Amiga -using playback rate to control pitch rather than resampling).

And from the number I've seen, a 1.6 MHz 6502 should reasonably manage 3 channels sampled up to 8 kHz (ie 8 kHz would be for maximum pitch, and lower rates for lower pitched notes), so 3 sampled channels and 1 PSG channel, maybe using 1 channel for fixed rate interleaved 4 kHz playback for 2 percussion voices (or other fixed pitch playback) and the other 2 left for primary instruments.

It would be really tight managing that at 1.2 MHz though, perhaps knock it down to 7 kHz max and interleaved 3-3.5 kHz for the percussion channel.

 

If you were willing to sacrifice ~1/3 of CPU resource just for audio, it might have been feasible to do some of that to a lesser degree in-game. Not just fixed rate stuff, but a bit more like a full on sample synth channel being used (with pitch via playback rate) or maybe even a couple channels if you capped them at 3-4 kHz.

From what I understand, a lot of the Atari ST PCM/MOD player stuff was mixed to only 4 kHz (be it added or interleaved -either way you'd have to scale samples for notes/pitch), so in that context it wouldn't be too bad at all. Or if you limited resource to less than 20% CPU time (to still allow ~1 MHz for other stuff), you could still manage a single ~4 kHz channel. (and there's a LOT of stuff a single channel is useful for, musical or otherwise... some examples on the NES and Genesis show that -there are examples of software mixing on the MD too though, but I'm not considering those, and interestingly a lot of MD samples are only 4 kHz too)

Edited December 11, 2010 by kool kitty89

[ANTIQ]

Yerzmyey

Epi

[kool kitty89]

Yerzmyey

Epi

Neat, I've seen some of yerzmyey's Spectrum stuff on Youtube (and some related digital tracker stuff), but hadn't seen more of his stuff until now.

Like:

and I see there's an 8bitcollective profile too: http://8bc.org/members/yerzmyey/

 

And I see a bunch of spectrum MOD stuff further down the page you posted too.

 

Odd that the Neotracker stuff sounds more distorted than the Spectrum stuff (lower sample rate?), I'd have thought the A8's set-up would have been superior for that. Actually, I've been wondering if the ZX's sample tracker used for a lot of the demos on youtube are using the 3 AY square wave channels as separate DACs or mixing them like the ST for better quality. (given the simultaneous stereo effects, I think it may be 3 hardware channels and that would also be a good bit less CPU intensive -no resampling/scaling- but I'm surprised at how good it sounds if it's actually single channel unsigned logarithmic PCM)

So you know anything more specific on how the sampled music is managed on POKEY stuff or AY on the ST or spectrum? (some of the ST MOD doesn't sound any cleaner than the spectrum demos, so maybe some ST stuff was done more like that, but I assume the POKEY stuff is all done as separate 4-bit PCM channels using interrupts) There was a rather long-winded discussion on Sega-16 about the utility of the AY (or SN) sound chips for PCM (especially using single channels) that gave me the impression that 4-bit linear PCM was generally superior in sound quality to doing any sort of playback via a single unsigned logarithmic channel. (paired channels with optimization is another story)

 

Do you know if the POKEY stuff was pre-processed to optimize sound samples for 4-bit linear PCM?

Edited December 12, 2010 by kool kitty89