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

[ANTIQ]

No, but you can PM yerzmyey.

 

To test linear against logarithmic we'd obviously need to eliminate other variables like sample frequency and noise.

 

POKEY's output isn't linear anyway; I don't even know if that was taken into account.

[carmel_andrews]

Perhaps i am missing something here, but why would you want to stick the lovely A8 CS in an ST for, it would'nt be either an A8 or an ST...just a bastardized atari computer

[kool kitty89]

Perhaps i am missing something here, but why would you want to stick the lovely A8 CS in an ST for, it would'nt be either an A8 or an ST...just a bastardized atari computer

Well, the context is to have the ST pretty much the same video/CPU/memory wise, but use existing Atari stock/licensed/custom support chips in place of the off the shelf chips used in the ST (or at least partially replace them) and hopefully have some added capabilities (especially sound wise) while maintaining similar cost or even dropping cost significantly in the long run. (through consolidation and cutting out the overhead as they had licenses/ownership over the alternate chips)

So, instead of the 68901, ACIAs, YM2149, and 1MHz 6301 have some combination of POKEYs, 2 MHz 6502C, RIOT, and perhaps CIA (not in used by atari, but a very attractive option that could possibly displace the 68901 entirely) and then cut the pin counts with revised custom chips soon after (depending how much you actually used, one or both POKEYs might be cut to 32/28/24 pins) followed by actual die shrinks, removal of vestigial silicon, and further consolidation into fewer LSI chips. (something Atari Corp did with most of the custom chips in the ST, but none of the off the shelf chips)

It seems that dual POKEYs, a RIOT, a 6502, and a CIA might be able to handle all the I/O duties of the existing chipset except the floppy drive (DMA was custom) and if the 6502 had a notable amount of resource left over and they added a bit more to allow the 6502 access to the main bus (to pull data from) and proabably a bit of work RAM beyond RIOT's 128 bytes (say 2-8 kB), POKEY could have been used to drive added audio effects for POKEY, especially PCM. (especially with 5/8-bit pairing modes)

And later on (like by the time of the STe), they could have upgraded to a 4 MHz 65C02 (like the Lynx), done a good bit more integration, and added DMA extentions for using POKEY's DACs, or at least a FIFO buffer mechanism to greatly reduce the number of interrupts needed. (rather than setting every sample, set every 32 samples -or whatever the buffer length used was)

 

Thinking on the floppy drive, maybe they could have even re-used one of the A8 floppy disk controllers... the 5.25" disks were probably unsuitable, but there were several canceled 3.5" prototypes that may have had fully functional drive controllers that Atari Inc owned or licensed.

 

 

 

 

But yes, building on the stock A8 chipset (especially video) is another topic entirely... and ST video (or other issues) were already mentioned recently in the ST forum. (lack of scrolling was the biggest oversight)

Edited December 13, 2010 by kool kitty89

[JamesD]

To address the original question...

 

Any existing chip would have had to work on the 68K buss. The 6502 and 6800 aren't drastically different and a lot of things designed to work with the 6800 work with the 68K with some minor glue logic. So... to some extent it is/was possible from a physical standpoint.

 

However, even if you just attach the old parts, the parts must be fast enough to function on the higher speed buss.

If you throw new capabilities into the picture (ST graphics modes) you have to combine the old and new logic. The design process was very different between those generations. You would have to implement the old designs in code rather than a tape layout before you could even begin to combine it with new functionality. Once you have implemented the old chip in the new design process, you have to modify it for the faster buss. Then you have to combine it with any new logic.

Since key engineers from the original design were no longer at Atari, that would have been very difficult.

 

Now, interfacing two microprocessors (68K & 6502) to the same buss is a very complex issue. You need a dual buss architecture at the very least and you increase the complexity of all the support chips again even if you solved the previously mentioned issues.

Not only do you need to meet new timing but old as well for backwards compatibility. That would be real fun.

 

How exactly do you replace the functionality of the 6301? I really don't know how the ST used the 6301 so I really can't say. Depending on the model though, the 6301 has internal RAM and other integrated functionality that would be more expensive to duplicate with another combination.

 

What it all boils down to is a time consuming and expensive process that would have resulted in a more expensive machine at a later release date. So, how do you think that would have worked out with the Amiga as a competitor?

 

Apple approached the backwards compatibility issue with a plug in board. That probably would have been the best option for Atari but then Apple had already implemented their old hardware in the new design process.

[Rybags]

Putting the 6502 in and sharing RAM would have been madness, not even worth considering.

 

Remember, a 2 MHz 6502 memory cycle is equal to 4 cycles of an 8 MHz 68000, so in effect it'd be hogging the bus all the time. Put HALT logic in and you're just slowing the 6502 down anyway. And on the cycles the 6502 is active, you're losing 4 bus cycles from the POV of the 68000.

 

Not really any benefit. I imagine the applications where both CPUs were in arcade machines, both probably had their own memory and the 68000 would have just queued requests to the 6502 using some sort of intermediary hardware.

[kool kitty89]

To address the original question...

 

Any existing chip would have had to work on the 68K buss. The 6502 and 6800 aren't drastically different and a lot of things designed to work with the 6800 work with the 68K with some minor glue logic. So... to some extent it is/was possible from a physical standpoint.

 

However, even if you just attach the old parts, the parts must be fast enough to function on the higher speed buss.

If you throw new capabilities into the picture (ST graphics modes) you have to combine the old and new logic. The design process was very different between those generations. You would have to implement the old designs in code rather than a tape layout before you could even begin to combine it with new functionality. Once you have implemented the old chip in the new design process, you have to modify it for the faster buss. Then you have to combine it with any new logic.

Since key engineers from the original design were no longer at Atari, that would have been very difficult.

The 68k already uses a bunch of support chips like that (several are 6800 oriented chips and MUCH slower than the 68k bus -not sure about all the clock speeds, but the 6301 should be 1 MHz, so slower than the 6502 would be )

 

 

Now, interfacing two microprocessors (68K & 6502) to the same buss is a very complex issue. You need a dual buss architecture at the very least and you increase the complexity of all the support chips again even if you solved the previously mentioned issues.

Not only do you need to meet new timing but old as well for backwards compatibility. That would be real fun.

Yes, but the only reason I was suggesting main bus access was occasionally pulling data while the rest of the time the 6502 would be in its own work RAM. (that suggestion was mainly in the context of PCM playback, but could apply for general coprocessing as well, or managing the POKEYs in general -for I/O and sound including other CPU driven effects other than PCM) The RAM is already interleaved with video with 250 ns accesses, and video couldn't be interrupted in active display (much of vblank and hblank may be free -not sure) and at 2 MHz a 6502 should be able to interleave as well as a 68k (ie be slow enough so it would run at full speed when accessing main RAM in parallel with video), so you'd halt the 68k for the short bursts of 6502 accesses. They also could have either used a fixed area of RAM that the 6502 could access, or implement a bank simple switching scheme. (especially using multiple smaller banks at a time -like 4 8k banks)

 

On the sound issue, part of the idea comes from the set-up the MegaDrive uses with the Z80, though a 6502 with timers would actually be a good deal more useful, especially with the multiple DACs and timers POKEY offers. (on the MD the Z80 has its own little chunk of SRAM to work in and a buss steering chip/middle man that provides DMA to 68k mapped ROM space on the main bus, but is more of a hack for added audio duties due to the slow serial 32k bank switching, the same speed as the SMS, YM2612 timer interrupts left unconnected, etc)

 

 

How exactly do you replace the functionality of the 6301? I really don't know how the ST used the 6301 so I really can't say. Depending on the model though, the 6301 has internal RAM and other integrated functionality that would be more expensive to duplicate with another combination.

Yes, which is exactly why I was speaking of the overall picture: if you replaced only one chunk of the support chips, the advantages wouldn't be there, but with a full block of alternate chips the duties would be distributed differently. Also remember that part of this premise is that the existing stockpiles, licenses, and ownership of IP (for the custom chips) would cut out additional overhead from buying purely off the shelf parts, and even if somewhat less attractive initially (more board space used etc), it could pay dividends with further consolidation. (which Atari did with all the custom chips, but still have bulky discrete off the shelf support chips in the early 90s -for the most part, though at least some had switched to smaller surface mounted packages)

 

Knowing the overall functionality used of the existing support chips would be critical in actually getting a good idea of what was needed to replace them. (many may have had a lot of unnecessary or redundant functionality, so that would certainly impact this topic)

 

I'm not sure on any of this, but I was thinking that perhaps the 6502 would have enough left over resource (after normal I/O duties -if not allowing certain I/O functions to be halted/disabled to provide more 6502 time under some circumstances) to handle additional coprocessing, especially for audio. (having the dual POKEYs alone would be nice though)

Hopefully, they could have afforded to tweak the bus enough to allow 6502 access as such practically (sparingly for occasionally pulling data -should be less than 1% of the 68k bus time for practical PCM use). And in the contex of plain MCU functionality, the scratchpad from RIOT would be equivalent to what the 6801 has (though you'd need external ROM -assuming a normal 6502C in use by Atari and not a MCU derivative), but to really be useful for more than I/O with fixed code in ROM and a tiny scratchpad, a bit of work RAM would be needed (like a single 2 or 8 kB SRAM chip -probably the former due to both cost and 24 pin vs 28 pin packaging) which would also displace the need for dedicated program ROM. If RIOT was still used, the Scratchpad could still be useful as well (but far less necessary) and given the general functionality offered, it's a good bit more attractive than PIA, but CIA is really nice. (except Atari was neither stocking that nor licensing it as they had with RIOT -Atari Inc was already implementing a custom IC merging RIOT+TIA+ a 6502 core for a single chip VCS which Atari Corp introduced for later Jr models) Given the functionality for the footprint and the fact that most MOS LSI chips (aside from CBM specific ones) tended to be favorable to license, that would be an attractive possibility as well in the long term -again with consolidation into custom chips kept in mind. (Motorola didn't tend to be anywhere near as favorable for licensing -or Hitachi stuff for that matter, though most of that was licensed from Motorola in the first place)

 

 

What it all boils down to is a time consuming and expensive process that would have resulted in a more expensive machine at a later release date. So, how do you think that would have worked out with the Amiga as a competitor?

Again, I'm thinking of some very short term advantages (existing stockpiles/supply streams), some modest costs to pin packages a bit later, and a huge advantage of consolidation and low-cost custom chips later on. (along with addressing some of the ST's weaknesses with truncated development time -ie not enough time to implement a proper DMA circuit for audio, even a Mac type one, and no better off the shelf audio hardware on the market, let alone inexpensive -the YM2203 wasn't released until 1985, but some other things like hardware scrolling especially were separate issues in general -and scrolling definitely seems to have been the easiest thign to add to the ST to dramatically impact long-term market life with almost no impact on production cost or release date -packed pixels would have been nice too though and not necessarily a huge engineering time difference, but a different initial design concept -less flexibility in some areas though, from the engineering side at least -especially for variable color depths)

 

There's a lot more you could consider purely in hindsight (and to some extent, I've been trying to think in a perspective fitting for 1984), but given that, the release date wasn't THAT critical for overall success. They were niche in the US the entire life of the ST and it got worse as it aged. In Europe, it didn't get big on the mass market until ~1987/88 (the same time it started declining in the US) while it was a major higher-end product for 1986, but the Amiga didn't become a big factor until the prices drastically ~1989/1990 dropped and RAM costs prohibited Atari from staying below those costs and there started to be a shift towards Amiga-specific games much more than ST ports and C64 games.

 

Most of that was covered in this thread: http://www.atariage.com/forums/topic/171509-were-the-atari-sts-big-for-gaming-or-just-the-8-bit-line/

 

And the 8-bit chips issues is just and idea that I started thinking about during that discussion (especially after I mentioned the infeasibility of dedicating a CPU/MCU to audio processing unless it had other useful functionality in the system), and that split into 2 schools of thought on the issue:

1. could using exiting/custom/MOS 8-bit chips have been cheaper to use in any context (even only in the long run -via consolidation, but possibly in some respects in the short run) and

2. could they have actually facilitated enhanced functionality over the existing 1985 ST chipset (even if you dumped the 6502 with DMA and work RAM idea, you'd have the better audio of dual POKEYs and more potential for consolidation, let alone future extensions of the functionality with successive hardware)

 

 

 

Apple approached the backwards compatibility issue with a plug in board. That probably would have been the best option for Atari but then Apple had already implemented their old hardware in the new design process.

Heh, Apple is a whole other story though... there's plenty you could argue over how the Apple 2 might have done better in the long term or even displaced the MAC entirely. (not just the GS, but what could/should have happened much earlier) But that's way off topic.

[kool kitty89]

Putting the 6502 in and sharing RAM would have been madness, not even worth considering.

 

Remember, a 2 MHz 6502 memory cycle is equal to 4 cycles of an 8 MHz 68000, so in effect it'd be hogging the bus all the time. Put HALT logic in and you're just slowing the 6502 down anyway. And on the cycles the 6502 is active, you're losing 4 bus cycles from the POV of the 68000.

 

Not really any benefit. I imagine the applications where both CPUs were in arcade machines, both probably had their own memory and the 68000 would have just queued requests to the 6502 using some sort of intermediary hardware.

As I mentioned above, the context would be with dedicated memory for the 6502, if stripped to 6301 like functionality alone, ROM+RIOT scratchpad would apply, but a nice chunk of work RAM (like a 2kx8-bit SRAM -8k would be nice but more costly and with a few more pins and traces) would allow far more utility for general coprocessing (namely for audio as well as I/O -managing POKEY, doing tricks with POKEY for more flexible sound, software envelopes, PWM effects, or PCM playback, though with the fast interrupts, perhaps it would also be useful for some video related duties as well -especially hblank interrupt related stuff like reloading palettes mid-screen with the only 68k overhead being a rather negligible amount of bus time taken during those interrupts -especially compared to the cycles wasted with 68k interrupts -a lot of interrupt handling that the 6502 could be useful for)

 

The DMA to main memory would be very sparingly use for short accesses to pull data (for PCM), or perhaps to do some SHIFTER updates/raster interrupts. The 68k would get halted for those sparse instances, but not otherwise. (Video DMA would continue to interleave as RAM is still 2x as fast as the CPU memory accesses) Code would run in 6502 memory, data would be in main memory. (hmm, maybe even the 128 byte scratchpad would be enough to do some useful stuff in along with main bus access -and only ROM for I/O duties rather than RAM... but that's about the same amount of board space used as with a small SRAM so it wouldn't be a board space/cost issue, just a component cost one)

[Innovative Leisure]

I love the idea of having a 6502 in an ST, especially as a co-processor.

[JamesD]

I'm going to have to repeat myself.

Atari needed to re-implement the 8 bit chipset in synthesized logic. Period. What I was saying about Apple is that they had already done that with the IIe which made the II on a card trivial. Atari 8 bit hardware was much more complex, the original engineers that did key work were gone, so you are stuck using the old chips. What you have is two complete computers in one. That's ok but when it involves two boards and a lot of glue logic and video switching to hold things together you end up with an expensive computer that won't compete well with the Amiga.

 

As for sharing the buss... with a dual buss architecture you could get away with sharing a section of memory. The 68K would have priority access and the 6502 would be halted whenever the 68K needed to access the memory. You could also use dual port RAM which was available at the time but you would want a small communications region rather than 64K because it was pretty expensive at the time.

 

If I follow this right, the 6301 was used to drive the sound hardware.

The 6301 it had it's own memory and I/O built in. Interfacing it to the 68K would be rather trivial through I/O ports. Doing the same thing with the 6502 would be much more complex. You have to remember that the Tandy MC-10 was based on the Motorola 6803 and a hand full of off the shelf chips for the entire computer. The built in functionality of the 6803 made such a small design possible. The Atari 8 bit required a lot of board real estate for all it's chips. When combined with the 68K hardware you would be looking at a daughter board unless you use synthesized logic versions of the original chipset combined with the custom ST chips.

BTW, 2MHz 6301 parts were available if I remember right.

 

It's late and I'm starting to ramble so I'll leave it at that.

[+rdemming]

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)

 

If you mean with real-time clock, a clock that keeps track of time while there is power, but looses the time when the power is disconnected, that is handle too by the 6301 on the Atari ST. The 6301 has a build-in 16-bit timer that is used in the ST as clock.

You could add a battery to the ST's keyboard (powering the 6301) that keeps the clock running while the ST is powered down.

 

 

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.

 

Hmmm, on the 6301 datasheet, it clearly states it has build-in serial communication on p23 (pin 11) and p24 (pin 12). On the ST schematics, these pins are directly connected to the TxD and RxD pins of the ST's ACIA.

In fact, the only chips in the keyboard is a 6301V1 and a 74LS244 line-driver. No other chips needed since the 6301 handles all serial IO and keyboard scanning.

 

Further, you can upload a small program from the ST to the 6301 and run it. So in theory you can use the 6301 as a simple co-processor that communicates with the system using the serial interface. I don't know if anyone did use this feature though.

 

Robert

[Rybags]

Amiga 500 didn't have a battery-backed RTC.

 

But most of the trapdoor RAM expansions also provided one, so in effect you could say most machines would have had one.

[Divya16]

Amiga 500 didn't have a battery-backed RTC.

 

But most of the trapdoor RAM expansions also provided one, so in effect you could say most machines would have had one.

 

I remember Amiga 1000 had a RTC that hooked up to the keyboard port. It had that silver battery instead of the one that leaks and looks like a Donkey Kong barrel.

[kool kitty89]

I'm going to have to repeat myself.

Atari needed to re-implement the 8 bit chipset in synthesized logic. Period. What I was saying about Apple is that they had already done that with the IIe which made the II on a card trivial. Atari 8 bit hardware was much more complex, the original engineers that did key work were gone, so you are stuck using the old chips. What you have is two complete computers in one. That's ok but when it involves two boards and a lot of glue logic and video switching to hold things together you end up with an expensive computer that won't compete well with the Amiga.

Huh? What are you talking about?

I said I wasn't talking about a compatible machine at all, but only re-using a few existing components (only some custom -the rest licensed/off the shelf) and any such synthsized logic/consolidation/die shrinks would need to be done later on using the official netlists/blueprints/schematics and new/outsourced engineering staff (assuming they'd lost the key engineers -Atari Corp kept a lot of the computer related staff, at least early on, but I'm not sure of the details on that -Marty mentioned it briefly in a recent discussion), and that's what Atari Inc would have had to work with when resynthesizing the 6502 core and 6532(RIOT) chip into their own in-house LSI chip (the merged TIA+RIOT+6507 "JAN" for the 2600 Jr), it was all licensed, so dealing with official documents and not reverse engineering in that context. (you'd need more engineering if transitioning to CMOS, of course)

 

A backwards compatible computer would be a totally different matter and it would have been more efficient to build on the existing architecture (ie enhanced GTIA modes with double the dot clock, or even further beyond that with additional color registers and possibly more advanced indexing for the character modes -there's the sprites too, but sprite logic tends to eat up a lot of chip space). In that respect, Atari Inc (and possibly Corp) may have still had some of the key staff onboard to do that, like George McLeod (not sure when he left, but he engineered CTIA and GTIA) and a few others. Before Atari Inc was liquidated, they'd already prototyped CGIA in LSI silicon at least on a small scale (apparently a 68-bit LCC was used) and a number of other things were planned. But again, none of that was the context for this thread. (I specifically made an asside to that issue on my topic post)

 

 

As for sharing the buss... with a dual buss architecture you could get away with sharing a section of memory. The 68K would have priority access and the 6502 would be halted whenever the 68K needed to access the memory. You could also use dual port RAM which was available at the time but you would want a small communications region rather than 64K because it was pretty expensive at the time.

What about using a dedicated chunk of SRAM for the 6502? (for starters the RIOT RAM -bacially what the 6301 had internally, but better would be a 2 or 8 kB SRAM chip -2k would be cheaper and take up less board space while still having a decent amouint of space for some small programs -128 bytes would be extremely limiting though)

 

If I follow this right, the 6301 was used to drive the sound hardware.

The 6301 it had it's own memory and I/O built in. Interfacing it to the 68K would be rather trivial through I/O ports. Doing the same thing with the 6502 would be much more complex. You have to remember that the Tandy MC-10 was based on the Motorola 6803 and a hand full of off the shelf chips for the entire computer. The built in functionality of the 6803 made such a small design possible. The Atari 8 bit required a lot of board real estate for all it's chips. When combined with the 68K hardware you would be looking at a daughter board unless you use synthesized logic versions of the original chipset combined with the custom ST chips.

BTW, 2MHz 6301 parts were available if I remember right.

Yes, that would be an interesting possibility too, using the 6301 to drive audio and offload that from the 68k. (but you'd be limited to a tiny 128 bytes of program memory and halting the 68k when accessing main RAM -and of course running code hardwired in ROM)

 

The context of practical (long term) use of the MOS/Atari Inc chips would be dependent, again, both on sharing features differently among LSI support chips, but also the presumed ability to consolidate those chips into custom chips later on: facilitated by the ownership/licensing of said chips (CIA would not be among those though) that would allow a huge reduction in board space used and maintain the lack of overhead from bying 3rd party components (granted they had to 2nd source manufacturing as they lacked an in-house fab -of course, that advantage would become less important as largescale overseas chip vendors got more and more competitive -especially compared to something on the scale of MOS).

 

One neat thing would be cases like merging RIOT and a 6502C and not only having that useful in the "ST", but also in the 7800.

 

But if it turned out that much of the A8/VCS chips in use were not suitably efficient for use in the ST's design, then the point would be moot. (it seems like that isn't so much the case though, and the question would be whether some combination of RIOT+POKEY(S)+6502C(preferably with 2k SRAM)+(maybe)CIA could displace the duties of the 6301+2xACIAs+YM2149+(maybe)68901 and if consolidation of the alternate chips would be a realistic goal in a relatively short time period -ie to a significant extent by 1987/88 -given the 7800, RIOT+6502C would be an attractive starting point)

[kool kitty89]

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.

 

Hmmm, on the 6301 datasheet, it clearly states it has build-in serial communication on p23 (pin 11) and p24 (pin 12). On the ST schematics, these pins are directly connected to the TxD and RxD pins of the ST's ACIA.

In fact, the only chips in the keyboard is a 6301V1 and a 74LS244 line-driver. No other chips needed since the 6301 handles all serial IO and keyboard scanning.

Thanks, good point, but the question would still be if the alternate chips could provide reasonable functionality in a similar role. (a moderately larger -overall- footprint would be acceptable initially: partially due to the advantages of existing stock/supply/production, but also due to possible changes in the long term: firstly simple cut pin packages -ie 40 to 32/28/24 depending on what's used/needed- and then actual engineering invested into consolidation into fewer chips, and also whether any added cost would be worth added features facilitated by the hardware changes)

 

Further, you can upload a small program from the ST to the 6301 and run it. So in theory you can use the 6301 as a simple co-processor that communicates with the system using the serial interface. I don't know if anyone did use this feature though.

Yeah, but 128 bytes is really limited... and even if you could fit a simple PCM playback routine into that, without DMA to main memory, you'd have no way to access (relatively) large amounts of data needed for samples. (so it might be useful for some simple PWM or software envelope effects, but not streaming PCM playback)

 

So in a context where the other chips would not ever be options, it might have been a good option to tweak the 6301's use a bit to allow more flexibiltiy. (namely you'd need DMA to main memory, a dedicated 8-bit DAC would be really helpful, and preferably a bit more RAM to work in off the 68k bus -or perhaps cram some sound specific functions into ROM) That's assumign a bare bones DMA circuit+DAC wouldn't be cheaper. (something as primitive as the Mac would be OK)

Edited December 15, 2010 by kool kitty89

[JamesD]

Ok, this is clearly one of those threads where someone posts a "could this have happened" question and then continually adjusts their argument to make it happen.

 

Simple answer... yes. If you spend enough money, don't care what your product costs, don't care how long it would take to bring to market, and don't care if your competitor kicks your butt it is possible. Happy now?

Face it. If the ST comes out as expensive, more expensive, or later than the Amiga 1000... it's a flop. Some die hard 8 bitters would buy it but that's about it.

 

Just replacing the 6301 with a 6502 requires:

I/O chip, RAM, 6502, and glue logic. What do you think that would cost at that time even without the old Atari chips?

The RAM alone is probably $25 or more, the I/O chip is a few dollars and so is the glue logic. Added board space is $5+ and added design time is in the thousands. The last item is a one time fee but has to be recouped somehow. You have to be adding around $50 COST to the board just to replace the 6301. At retail that is probably $100. That alone blows your price point vs the Amiga.

For the full Atari 8 bit you need to integrate video, create some sort of disk interface (care of the 68K), we need a larger power supply...

[snicklin]

I'm not sure I'd want to have forked out all that extra cash for a 16 bit machine to get a ... 8 bit machine, well, sort of, you know what I mean.

[atariksi]

I'm not sure I'd want to have forked out all that extra cash for a 16 bit machine to get a ... 8 bit machine, well, sort of, you know what I mean.

 

I think he's implying that those 8-bit chips would outperform some of the chips in the ST especially with a 68000.

[kool kitty89]

I'm not sure I'd want to have forked out all that extra cash for a 16 bit machine to get a ... 8 bit machine, well, sort of, you know what I mean.

 

I think he's implying that those 8-bit chips would outperform some of the chips in the ST especially with a 68000.

Or Atari Inc's own 16-bit chipsets that were fully prototyped in 1983 and (by all accounts) would have more than likely kicked the crap out of the Amiga (and with a Unix based OS and custom GUI to boot -the same OS+GUI that was planned to carry over to the Atari "MICKY" console/computer using the Loraine chipset before Amiga lied to back out of the contract in 1984), of course it's unclear whether any of those chipsets would have been practical in a low-cost oriented machine, but it seems quite possible. (one of the main issues with the 1983 conficuration wasn't the chips themselves, but the planned super high-end workstation form factor with megabytes of RAM and multiple 68ks in some cases -up to 3 68ks and 2MB of RAM, which is crazy for 1983, though there was a different context behind the long-term Advanced Technologies projects as such)

 

Let alone other things like using MARIA.

 

Once again, a totally different topic though.

[kool kitty89]

Ok, this is clearly one of those threads where someone posts a "could this have happened" question and then continually adjusts their argument to make it happen.

 

Simple answer... yes. If you spend enough money, don't care what your product costs, don't care how long it would take to bring to market, and don't care if your competitor kicks your butt it is possible. Happy now?

Face it. If the ST comes out as expensive, more expensive, or later than the Amiga 1000... it's a flop. Some die hard 8 bitters would buy it but that's about it.

No, read my original premise, I've only expanded on that: the initial premise was intentionally open-ended in several areas depending just how it might have been practical to fit the components into the system. (albeit there's still not enough info on just what the ST needed all the chips for and how much of the functionality was totally used)

 

And there's multiple facets: replacing only some support chips, just a bare bones functionality set-up vs actually pushing to enhance things (beyond the natural result of POKEY audio), etc, etc, but always considering cost as a major deciding factor and not jsut short term cost, but long term. (utility of such chips would certainly depend heavily on later consolidation of the chips -something not possible with most of the off the shelf components used and facilitated by existing licenses of most alternate chips I listed)

 

Just replacing the 6301 with a 6502 requires:

I/O chip, RAM, 6502, and glue logic. What do you think that would cost at that time even without the old Atari chips?

The RAM alone is probably $25 or more, the I/O chip is a few dollars and so is the glue logic. Added board space is $5+ and added design time is in the thousands. The last item is a one time fee but has to be recouped somehow. You have to be adding around $50 COST to the board just to replace the 6301. At retail that is probably $100. That alone blows your price point vs the Amiga.

For the full Atari 8 bit you need to integrate video, create some sort of disk interface (care of the 68K), we need a larger power supply...

It's assumed that the RGB project was still early enough in design when they merged with Atari Inc that the custom chips could be worked around the Atari/MOS chips rather than the off the shelf chips historically used in the ST: thus the DMA chip would be oriented as such, the GLU would be as well, etc, etc. If you had to do that after the fact (with GLUE+DMA, etc pretty much fixed already, then yes, it would be impractical with a LOT or wasted R&D costs -is the custom RGB/ST chips hand't yet left paper it may have still been practical, but once you've got extensive work on wirewrap prototypes and simulators/emulators, let alone actual LSI design, then you're stuck).

 

In the context of RIOT+6502C, that's no added cost for memory yet, but as to a 2 kB 8-bit SRAM, it probably would have been ~$5 in 1984 (stocking parts) and about the same as the 4kx4-bit chips in the 7800 (same 24-pin footprint though 3 more traces needed -4 more data lines, one less address), and then there's the overall picture of the cost of the 68901, ACIAs, 6301, and YM2149 combined vs RIOT+6502+RAM+CIA+POKEYs, etc and various configurations. AND you'd have to not onyl take initial cost into account, but cost after cutting pin counts (simplest change and 24/28/32 pin DIPS would all be potential options without changing silicon), and more importantly taking consolidation into account later down the road. There's also the potential to even replace the floppy disk controller with an in-house Atari design if there was a suitable one available. (further extending potential for consolidation)

 

All the GLUE and DMA logic would be in custom LSI catering to the support chips and 68k+SHIFTER, so shouldn't contribute to board space.

 

 

 

 

Then again, there's also all the missed potential of Atari Inc's far more advanced (and fully prototyped in TTL -not sure how much made it to LSI -there were several different chipsets too) custom chips from the Advanced Technology division and Atari Corp did initially keep almost the entire AT staff from what I understand. (not sure whether the development timeline would have been significantly longer than the ST though: the hardware was prototyped, but that doesn't mean it was super close to production ready let alone in the right configuration for a low-cost machine) Regardless, Atari Corp had tunnel vision on the existing ST, so that became a non-factor. (but unlike that, the 8-bit chips were all there, tangible in full custom/licensed/off the shelf silicon like the off the shelf chips they used historically -again, if the RBP design was so far along that the DMA+GLUE were already well on their way to LSI test runs, the point would be moot anyway -and regardless of the context of Atari Inc's hardware, there's potential tweaks to the ST's existing architecture that could have paid off divedends in the long run even if it meant a moderately higher initial price and/or slightly later launch date -or in other cases, simply a different design concept, like using chunky vs planar pixels in the SHIFTER)

[atariksi]

I'm not sure I'd want to have forked out all that extra cash for a 16 bit machine to get a ... 8 bit machine, well, sort of, you know what I mean.

 

I think he's implying that those 8-bit chips would outperform some of the chips in the ST especially with a 68000.

Or Atari Inc's own 16-bit chipsets that were fully prototyped in 1983 and (by all accounts) would have more than likely kicked the crap out of the Amiga (and with a Unix based OS and custom GUI to boot -the same OS+GUI that was planned to carry over to the Atari "MICKY" console/computer using the Loraine chipset before Amiga lied to back out of the contract in 1984), of course it's unclear whether any of those chipsets would have been practical in a low-cost oriented machine, but it seems quite possible. (one of the main issues with the 1983 conficuration wasn't the chips themselves, but the planned super high-end workstation form factor with megabytes of RAM and multiple 68ks in some cases -up to 3 68ks and 2MB of RAM, which is crazy for 1983, though there was a different context behind the long-term Advanced Technologies projects as such)

 

Let alone other things like using MARIA.

 

Once again, a totally different topic though.

 

They did interface 8-bit chips to 68000 processors in the Amiga. The Amiga CIA chips are 8-bit chips and there's two of them in the Amiga. One is accessed at odd addresses like $BFE101 and the other is accessed at even addresses like $BFD100. I suppose they could have had a dual GTIA/ANTIC and dual POKEY in an ST and some sort of simple audio and video merge circuit. That would given it 8 channels of audio and 16 shades/16 colors where palette entries could be changed two at a time with one Move.w like Move.w #$F080,GTIAPalBase

[kool kitty89]

I'm not sure I'd want to have forked out all that extra cash for a 16 bit machine to get a ... 8 bit machine, well, sort of, you know what I mean.

 

I think he's implying that those 8-bit chips would outperform some of the chips in the ST especially with a 68000.

Or Atari Inc's own 16-bit chipsets that were fully prototyped in 1983 and (by all accounts) would have more than likely kicked the crap out of the Amiga (and with a Unix based OS and custom GUI to boot -the same OS+GUI that was planned to carry over to the Atari "MICKY" console/computer using the Loraine chipset before Amiga lied to back out of the contract in 1984), of course it's unclear whether any of those chipsets would have been practical in a low-cost oriented machine, but it seems quite possible. (one of the main issues with the 1983 conficuration wasn't the chips themselves, but the planned super high-end workstation form factor with megabytes of RAM and multiple 68ks in some cases -up to 3 68ks and 2MB of RAM, which is crazy for 1983, though there was a different context behind the long-term Advanced Technologies projects as such)

 

Let alone other things like using MARIA.

 

Once again, a totally different topic though.

 

They did interface 8-bit chips to 68000 processors in the Amiga. The Amiga CIA chips are 8-bit chips and there's two of them in the Amiga. One is accessed at odd addresses like $BFE101 and the other is accessed at even addresses like $BFD100. I suppose they could have had a dual GTIA/ANTIC and dual POKEY in an ST and some sort of simple audio and video merge circuit. That would given it 8 channels of audio and 16 shades/16 colors where palette entries could be changed two at a time with one Move.w like Move.w #$F080,GTIAPalBase

I wasn't arguing against that possibility in general... but that it's a different topic in general... and if they couldn't efficiently build onto ANTIC+GTIA (higher dot clock versions of existing graphics/character modes would be nice, and maybe a full 16 8-bit color registers to allow 16 colors from the full GTIA palette at 160x192 -or higher with overscan extended), that would get rather inefficient fast. (a backwards compatible A8 successor is a separate topic)

 

But in terms of using the 8-bit chips in general, yes: as established earlier the 68000 supported 6800 interfacing and (more or less) 6502 bus interfacing likewise. As it is, the ST already used predominantly 8-bit (mainly 6800 compatible) I/O+sound support chips (including the 6800 based 6301 MCU), so it would be a matter of using a different set of 8-bit I/O+sound chips.

 

And indeed, CIA came up earlier as an attractive possibility (especially if licensing was favorable -important for long-term consolidation, otherwise the off the shelf price is all that mattered). Not among the chips Atari Inc was already stocking/licensing of course. (unlike the 6532 and 6502 cores which they were merging into the custom single chip VCS... and RIOT is certainly much better than PIA for the same footprint -actually a bit of a shame they didn't use RIOT in the A8 given the potential to run small programs in the scratchpad at the full 1.79 MHz rather than slowing due to DMA and DRAM refresh... and the timer of course, independent from POKEY -one interesting thing would be to use the timer to drive a 1-bit square wave on the GTIA click/beeper channel -like the PC speaker used for tone generation, so you get a 5th sound channel without careful CPU timing -fixed volume of course)

Edited December 16, 2010 by kool kitty89

[kool kitty89]

Hmm, it seems that the floppy controller used in the ST was fairly a highly integrated of the Western Digital FD17XX line, so unless something Atari Inc had already been using at least approximated that (ie not too far behind), it probably wouldn't have been attractive to switch from that.

Unrelated to the controller itself, I wonder how using 5.25" disks might have impacted the ST in general... from cost of drives and disks to user acceptance, etc. (DSDD 5.25 would be 360 kB like SSDD 3.5" and would have added potential cross-compatibility with IBM compatible machines -with 5.25" being the defacto standard for the PC through the late 80s and even rather common in the early 90s; later upgrading to 1200 kB HD format, of course... which was available in the early 80s, but probably not cheap enough by '85, and there was also the intermediate 720 kB DSQD format, but that seems to have been pretty uncommon on PCs -or in general- so woudln't have been good for a cross-compatible standard -PCs and several other platforms including NEC's 8-bit PC8800 series seem to have pretty much skipped straight from DSDD 360 kB disks to DSHD 1200 kB disks) It also seems like the 720 kB DSDD 3.5" disks were never super common on the PC either. (perhaps due to HD 5.25" disks becoming popular proper to that so the HD 3.5" disks were the next real step in that sense)

... Or if they did support QD 5.25" from the start, they could have used single sided drives for 360 kB, but unlike SSDD 3.5", you could still use a double sided disk by flipping (with proper notching and labeling of each side) for 720 kB disks from the start (and DS drives introduced later), and you'd still have backwards compatibility with the common DD 180 kB/side 5.25" disks. (you'd still need compatible file formats on top of that to actually use disks between the PC)

Edited December 18, 2010 by kool kitty89

[JamesD]

The problem isn't interfacing 8 bit chips in general, it's specific 8 bit chips. Attaching peripheral chips isn't a huge deal since the timing and interface isn't complex.

 

But things are different for things like graphics chips which usually share the system buss. The old graphics chip timing isn't compatible. Without converting the old graphics chips to synthesized logic and integrating directly with the new logic, you end up having to do something more complex or downright ugly. You have to create a frame buffer or switch between video sources.

 

Some of the Apple II clones on a card for the PC took the output from the PC graphics card, passed it into the Apple II card and then you connected the Apple II card video out to the monitor. Then the Apple II card switched the video between the two. It wasn't pretty but it worked. The drawback was the two couldn't share the screen at the same time. You couldn't put the Apple output in a IBM window.

 

You might be able to design a frame buffer that could be superimposed on the screen, so the machines could share the screen but that requires some high speed logic, more RAM (probably dual port) and who knows what else.

 

If you just want to interface a POKEY, I don't think it will present the interfacing problem that the ANTIC would. However, it was produced in smaller quantities that the Yamaha chip. A LOT of arcade machines and other computers still used the AY chips. That may have meant they were cheaper. I realize Atari had arcade machines, but their arcade business was kinda struggling by that point. I think it was an odd decision to drop the POKEY and a financial reason is the only explanation I can think of to do so.

 

If you only give the 6502 2K of RAM it may be cheap but you won't be able to have full compatibility with the 8 bit. You also don't really gain anything over using the 6301. And from the code I've ported between the 6803 and 6502, code should be smaller on the 6301. In a small RAM environment that may be important.

If Atari had the production facilities Commodore did, a 6502 with built in I/O ports and RAM would have probably been an obvious choice. But that wasn't an option.

[Rybags]

I imagine Pokey would have been the cheapest of the 3 A/V custom chips.

 

Aside from computer use, you could probably bet there were >200,000 produced for arcade (remembering many machines had 2 of them). And 7800 cartridges of which quite a few were surplus stock at the end, so quite possibly similar but probably lesser numbers there.

 

Then factor in spares and the fact that Atari generally went overboard when producing stocks of anything like that, often stockpiling sufficient amounts for years worth of production+spares.

[Crazyace]

It's not just the stockpiling - but the manufacturing cost - It wouldn't surprise me if the AY was actually cheaper to buy than a POKEY.

 

Atari should have had DMA sound / Scrolling ( STe style ) from day one - and used a 6522 ( or CIA ) instead of one 6850+AY chip to handle keyboard comms and the parr. port.