Any chance of an Amiga subforum?

[HiroProX]

Lies.

Fact. At the time the Falcon came out, it was up against 486DX PC's, 68040 Macs, and the Amiga 3000 and 4000. In addition, just about every serious Amiga 2000 and 500 user had at least a 33MHz 030 accelerator in their machine. In fact, having a 40MHz 030 accelerator in my A500 is why I got a 50MHz 030 with FPU accelerator with my first A1200, and in total it cost less than a Falcon, and flat outperformed it.

Full 32-bit Atari? It's called the TT030. Yes, there was a 50MHz accelerators, graphics cards, ethernet, etc, etc, just like the Amigas and Macs. As Atarian63 said, the Falcon030 was intended to be the "low-end" machine. The engineers had to weight price/performance/price in the design. At $2500, it's not so "low-end" anymore. It's too bad Atari never got around to a Falcon040 which would have really kick ass...

If you could find expansion hardware for the TT. TT's have always been a bit rare, and add-on hardware for them being moreso. In fact, ST accelerators period were quite rare items outside of the ICD AdSpeed, which was just a 16MHz 68000 with 32K of SRAM cache.

 

I like my STs, but frankly, compared to my Amigas, they just weren't quite as good. Nothing made an ST look worse than one with a color monitor next to an A500 with a color monitor. And that's exactly why I bought an A500, because I had gone with my dad to Dallas back in 1989 to buy a 1040ST, and came home with an A500 with the A501 RAM upgrade for 1Mb.

I dunno, we had quite a few hobbists but sold very accelerators for either machine, on ST it was mostly for the original 520 and 1040 model, we sold very very few for Amiga, ended up sending most of what we had back.

 

On the monitor, I guess if you are doing games the amiga one might look better but for work and crisp clear display.. The customers always picked the ST.

I would say both were excellent monitors The Amiga one being great for Atari,nintendo etc, hard to beat.I have one here at the office hooked up to a Nintendo 64, one of the nicest displays I have ever seen. The color ST monitor was very sharp though, I do think that most of what I am saying had to do with the computers output. The interlace amiga display drove me batty and it looked very cartoon like. Soft and fuzzy.

 

Funny, because everyone I knew, myself included, who owned an Amiga had an accelerator. I remember the CSA Derringers being quite popular as they were the most common A500 accelerator that didn't have to reside in a "sidecar" off the side of the A500. And accelerators for ST's are exceedingly rare. Probably because the ST had a bigger problem with programmers using tricks that were 68000 specific. Thus an 030 accelerator would break nearly half the software library.

[MEtalGuy66]

Funny, because everyone I knew, myself included, who owned an Amiga had an accelerator. I remember the CSA Derringers being quite popular as they were the most common A500 accelerator that didn't have to reside in a "sidecar" off the side of the A500. And accelerators for ST's are exceedingly rare. Probably because the ST had a bigger problem with programmers using tricks that were 68000 specific. Thus an 030 accelerator would break nearly half the software library.

 

Oh hell..

 

Thats not true, Hiro.. Have you ever seen an 020,030, or 040 based machine that wouldnt run pure 68000 code? Optimized libraries for these later processors wouldnt run on the 68000, but Motorola was pretty good as far as backward compatability...

 

I might be wrong as hell, but I alwayse thought that the reason accelerators were less common on the ST was that they were tougher to design due to timing requirements of the ST architecture. Ive read many articles about accelerator design saying that machines with more "synchrounous" design are alot less forgiving as far as CPU acceleration goes.

 

But yeah, regardless of the reason, I never knew anyone with an accelerated ST.. Plenty of accelerated Macs & Amigas though..

[+remowilliams]

Oh hell..

Hello WHDload with a million fixes for later procs/configs...

[Ganky Ghost]

Thats not true, Hiro.. Have you ever seen an 020,030, or 040 based machine that wouldnt run pure 68000 code? Optimized libraries for these later processors wouldnt run on the 68000, but Motorola was pretty good as far as backward compatability...

 

I think the 68040 was the only processor that had any backward compatibility issues. At least, it did on the Mac. There were definitely compatibility issues when Apple released Macs with 68040 processors. Atari never did release anything with an 040 processor so whether there would have been compatibility issues on the Atari machines with an 040 processor remains to be seen.

 

I might be wrong as hell, but I alwayse thought that the reason accelerators were less common on the ST was that they were tougher to design due to timing requirements of the ST architecture. Ive read many articles about accelerator design saying that machines with more "synchrounous" design are alot less forgiving as far as CPU acceleration goes.

 

I never knew anyone with an accelerated ST either. I knew people who upgraded the single sided drives in their early 520s to double sided drives. I knew people who upgraded the memory in their ST machines. I knew people who upgraded the TOS ROMs in their STs. I never knew anyone to add an accelerator to their ST.

 

I know that accelerators existed for the ST. I also know that there were graphics boards/accelerators for the ST that gave more colors at higher resolutions on VGA and multisync monitors, but I never knew anyone to actually buy one of these either. So I don't believe the reason for lack of accelerators on the user end of the spectrum to be technical issues, as clearly accelerating the ST was possible and several companies did offer such products. I think the reason why they didn't find their way to most ST users' machines has more to do with the reason most people bought an ST in the first place: cost.

 

If you look back through old Atari magazines from the late eighties and early nineties... I'm going to take a little timeout right now to look through some of mine... Marvin AG offered the Chili graphics expansion board at a cost of 2,998 Marks (1000 pounds) and Maxon offered the MGE graphics expansion card which provided graphics acceleration at a maximum resolution of 1280x1024 with 16 colors. And the cost of the Maxon board? ST World magazine writes, "At 1,798 Marks (600 pounds), this is probably the cheapest of the colour graphics expansions for the ST." Just for the hell of it, I took a look at some of the prices in the mail order ads in this issue of ST World for an ST computer. A 1040ST in 1989 sold for a grand total of between 350 and 380 pounds. Add a monitor and you're looking at a total system purchase of between 570 and 590 pounds with a color monitor and 100 pounds cheaper with a monochrome monitor. So the cost of a graphics accelerator for the ST was 2 to three times more expensive than the computer itself. Which detracts considerably to whole Atari notion of "Power Without the Price." Indeed, by the time you added all of this stuff to your ST you may as well have just dropped your wad on a Mac.

 

Yeah, I know that graphics boards aren't system accelerators, at least in as much as they don't replace the 68000 processor or increase the speed of the processor or system bus, but the point here is that accelerating the ST wasn't cheap. Hell, it was the exact opposite. It was outrageously expensive. And this, I submit, is the primary reason why most ST owners used essentially bog standard (factory stock) ST computers. i.e., ST owners chose the ST because it was cheaper than the competition and the upgrades for the ST put the ST on par, costwise, with the competition. So if you're going to spend the extra cash anyway, why on Earth would you choose an ST over something that already included what you would have to add to your cheaper ST?

 

And I think, in retrospect, it was this focus on cost that ultimately lead to Atari's downfall. They put too much effort into being cheap that they destroyed their own reputation and credibility in the marketplace. You can't market something as cheap and not expect consumers to equate 'cheap' with 'junk'.

 

But yeah, regardless of the reason, I never knew anyone with an accelerated ST.. Plenty of accelerated Macs & Amigas though..

[Rybags]

The quicker 68Ks had the issue thanks to badly written programs that used the high byte of 32 bit address pointers to pack other info in.

 

In fact, didn't some of the earlier ST OS releases do it too?

[MEtalGuy66]

Yeah there were hundreds of accelerators released for the AMIGA..

 

My cotention was that possibly the design of the ST made it less cost effective (more technically indepth) to build an accelerator. I dont know this to be true, but there is definitely a huge difference in the number of CPU accelerators that were offered for the mac/amiga and those offered for the ST.

 

Back to the MIDI issue. heh. Ive done some reading on this on all three platforms.. ST, MAC, AMIGA.. And Im comparing the hardware/programming references and schematics of all three systems..

 

First of all.. Lets talk about what EXACTLY the "ST MIDI INTERACE" is... This is a 6850 ACIA chip.. Originally designed for the old 6800 series machines.. It has an 8-bit data bus, synchronously interfaced to the 68000 and selected by 3 bits of "chip selects".. It has separate internal 8-bit shift registers for send & recieve and can be operated at baud rates of either 1/16th or 1/64th the speed of an external clock. In the case of the ST, this external clock is NOT the same as the CPU... Its generated by the GLUE chip which incidently does share the 8mhz CPU clock. The actual clock speed is 500khz (which divides by 64 to get 31.25khz). Obviously, none of the handshaking features of the ACIA are hooked up, because the MIDI standard doesnt use them. The TX line is hooked through a combination of TTL NAND gates and inverters directly to the MIDI out connector, and the incomming MIDI IN data goes through an opto-isolator and is hooked directly to RX on the ACIA. This chip uses interrupt driven loading/unloading of it's data, one byte at a time, and uses the 68000's "E" signal to facilitate synchronous bus communication. So the premise that the "MIDI INTERFACE" shares a common clock with the CPU is completely irrelevant to the accuracy of "MIDI TIMING", in addition to being untrue. Also, the theory of dependancy on "cycle exact code" goes out the window..

 

Secondly, the 6850 ACIA is a fairly common chip used in serial interfaces on early 8-bit machines, even some that predated the ST by 8-10 years. This doesnt mean that it wasnt particularly well suited to the menial requirements of MIDI communications. In fact THE EXACT SAME HARDWARE (arbitrarily clocked 6850, output line driver, and input opto-isolator- About $6.00 worth of parts)that makes up the ENTIRE ST MIDI INTERFACE was used in a TON of midi interfaces for the Commodore 64 Cartridge port, the Apple II expansion bus, and god knows what else.. Its a pretty simple & straightforward way of making a MIDI interface.. In fact, any similarly implemented UART chip of equal or greater capability to the 6850 could (and does) perform equally well in this role. This includes the UART used in the early macs, and the 8520 "complex interface adaptor" used in the AMIGA.

 

Where the early mac is concerned, there is a major issue in generating the (31.25kbps) required by MIDI.. The frequency of the clock signal used to drive the send/recieve baud rate of this chip does not correlate to possible divisor modes used by the chips internal baud-rate generator in the respect of generating the corrrect 31.25kbps baud rate.. The chip does however act in the exact same manner as far as data exchange with the CPU as the 6850 does on the ST. All this means is that on a MAC, the serial port is not well suited to midi. My guess is that any decent MIDI interface for the early mac would be built on an expansion card (in which case it would be every bit as "well timed" as the ST), rather than an external box hooked to the serial port.

 

Where the AMIGA is concerned, the 8520 CIA is actually clocked by the "eclock" which is directly generated by the 68000 CPU.. This chip has internal sub-micorosecond interval timers based on this clock, enabling it to operate at ANY baud rate programmable via a 16-bit divisor register in increments of 1BPS.. (in fact, this chip is so flexible that it can be manipulated in realtime and produce variable width pulses, variable rate bit streams and complex variable frequency waveforms.. This gains us nothing where midi is concerned, but gives some idea of how programmable this chip is by comparisson to "standard" UART devices.) Instead of 8-bit input & output registers, the 8520's are 16-bit wide. This chip is also directly on the 68000 data bus (just like the ST UARTS), and communicates via cpu interrupt driven loading/unloading of it's registers (Just like the ST does it).

 

So basically....

 

The AMIGA serial port hardware is more than capable of performing the exact same function as the serial port hardware used for the ST midi ports, exactly the same way, with the exact same considerations from a software coding/timing standpoint. And this goes for the cheapest possible "home-brew MIDI interface" because all it needs is a transmit line driver and a recieve opto-isolator hooked to the TX & RX lines..

 

Any machine can have an "ST MIDI PORT" with a $4.00 6850 chip, a 500mhz oscillator circuit (we'll say $5.00,) a $1.50 opto isolator, a suitable transmit line driver circuit (we'll say $2.00,) a handful of resistors (pennies each), and optionally, some adress decoding logic (another dollar or so) hung on it's CPU/expansion bus.. And MANY devices like this have been made for just about any platform (8 or 16bit) that anyones ever had the notion of hooking MIDI up to.

 

And this is the DAMN truth of the matter...

 

The ST MIDI hardware is IN NO WAY "superior" to the rest of the industry in terms of timing, functionality, or otherwise...

 

What the coders DID WITH IT is a totally different argument, and I have no idea and don't care because I've never used a MIDI sequencer program..

[Ganky Ghost]

Yeah there were hundreds of accelerators released for the AMIGA..

 

My cotention was that possibly the design of the ST made it less cost effective (more technically indepth) to build an accelerator. I dont know this to be true, but there is definitely a huge difference in the number of CPU accelerators that were offered for the mac/amiga and those offered for the ST.

 

I think the problem was that people couldn't justify spending two to three times the cost of the computer itself for an upgrade that likely wouldn't be supported by most of the software written for the machine. So people who were looking for serious performance in any particular field, be it publishing, video production/editing, sound sampling/editing, or what have you, opted to buy the machines that had some of that capability builtin as standard, so that they could be reasonably assured that any software they would be buying would support the hardware. With the Amiga and the Mac there wasn't a lot of "feature adding" hardware made available for the machines. Those machines were pretty much capable of doing what you needed them to do but just needed, in most cases, a little more oomph, which could be added quite easily without a whole lot of compatibility issues.

 

This is, what I think, killed Atari as a computer vendor. They sold underpowered machines at low cost. To meet their cost objectives they cut far more corners than they really ought to have. The result was that they created a reputation for themselves as manufacturing cheap and, consequently, inferior systems. The upgrades that were required to bring the machines up to par with the more expensive alternative architectures pretty much raised the ST class machines to a cost level that was comparable to the other machines, only lacking the full capability of the other machines due to the fact that the capability wasn't inherently standard and thus lacked any considerable level of support.

 

When you couple these shortcomings with the reality of who the typical ST buyer generally was, you soon realize that there wasn't much of a market for such upgrades in the ST marketplace. This would have ultimately lead to declining development from third party developers. So Jack cooked himself up a recipe for disaster. He created a platform whose primary selling point was its low cost. This meant that vendors producing peripherals and software for the machine pretty much had to follow suit if they were to have any appeal to the cost conscious consumer. Third party vendors found that they couldn't do so at a comfortable level, and the return on investment just wasn't there for the ST platform.

 

The Jaguar game console is a good example of an Atari product that was killed almost exclusively by the reputation of the company marketing it. The Jaguar was a pretty damn good machine. The company, though, had built itself a reputation for building and selling low cost, second rate junk. So no one was really willing to give the Jaguar a chance.

[Rybags]

The ST was upgrade unfriendly by nature due to the closed nature of the system.

 

Even the cartridge interface was read only - rediculous.

[Ganky Ghost]

The ST was upgrade unfriendly by nature due to the closed nature of the system.

 

Even the cartridge interface was read only - rediculous.

 

The ST was really popular in Germany for some reason. I could never figure that out. In Germany, STs were sold at Apple-like boutique style stores and for some reason the ST even managed to catch on as a "business class" machine in Germany. I could never reconcile the appeal of the ST to Germans with the idea of "Germans making good stuff". You would tend to think that "making good stuff" would be indicative of a people who appreciate quality. Yet, they adopted the ST line of computers like no other country on the planet, a line of computers that were in no way known for being quality machines.

 

Even now, if you search the Internet for interesting ST stuff, the really cool ST screenshots will almost exlusively feature a desktop in the German language.

 

 

NOTE:

 

The United States was the largest market for the Atari 16 and thirty-two bit computers. Germany was the second largest. With a population differential ratio of approximately ten to one in favour of the United States, it is quite probable that Germany was the largest Atari market per capita. Go figure!

[Rybags]

Not quite 10:1 I'd think.

 

U.S. back in the 1980s - about 260 million (?)

West Germany, just before reunification - about 63 million.

 

Tramiel did have one master stroke with the ST - at least he made it regional, ie didn't force the same keyboard, OS and GUI onto all users of all countries and languages.

 

Did the Amiga have other keyboard layouts? I guess, like many machines it probably had the UK version with Pound sign instead of "$" ?

[drac030]

I could never reconcile the appeal of the ST to Germans with the idea of "Germans making good stuff". You would tend to think that "making good stuff" would be indicative of a people who appreciate quality.

 

Apparently Amiga isn't as good, and ST as bad, as you think. Personally (although I am far from being a German), when I first met both machines, ST had an appeal of nice and easy-to-use machine. Whereas Amiga was just odd.

 

I wonder why an ST/Amiga controversies have to be discussed on this (Atari 8-bit) forum?

Edited December 17, 2008 by drac030

[atarian63]

Thats not true, Hiro.. Have you ever seen an 020,030, or 040 based machine that wouldnt run pure 68000 code? Optimized libraries for these later processors wouldnt run on the 68000, but Motorola was pretty good as far as backward compatability...

 

I think the 68040 was the only processor that had any backward compatibility issues. At least, it did on the Mac. There were definitely compatibility issues when Apple released Macs with 68040 processors. Atari never did release anything with an 040 processor so whether there would have been compatibility issues on the Atari machines with an 040 processor remains to be seen.

 

I might be wrong as hell, but I alwayse thought that the reason accelerators were less common on the ST was that they were tougher to design due to timing requirements of the ST architecture. Ive read many articles about accelerator design saying that machines with more "synchrounous" design are alot less forgiving as far as CPU acceleration goes.

 

I never knew anyone with an accelerated ST either. I knew people who upgraded the single sided drives in their early 520s to double sided drives. I knew people who upgraded the memory in their ST machines. I knew people who upgraded the TOS ROMs in their STs. I never knew anyone to add an accelerator to their ST.

 

I know that accelerators existed for the ST. I also know that there were graphics boards/accelerators for the ST that gave more colors at higher resolutions on VGA and multisync monitors, but I never knew anyone to actually buy one of these either. So I don't believe the reason for lack of accelerators on the user end of the spectrum to be technical issues, as clearly accelerating the ST was possible and several companies did offer such products. I think the reason why they didn't find their way to most ST users' machines has more to do with the reason most people bought an ST in the first place: cost.

 

If you look back through old Atari magazines from the late eighties and early nineties... I'm going to take a little timeout right now to look through some of mine... Marvin AG offered the Chili graphics expansion board at a cost of 2,998 Marks (1000 pounds) and Maxon offered the MGE graphics expansion card which provided graphics acceleration at a maximum resolution of 1280x1024 with 16 colors. And the cost of the Maxon board? ST World magazine writes, "At 1,798 Marks (600 pounds), this is probably the cheapest of the colour graphics expansions for the ST." Just for the hell of it, I took a look at some of the prices in the mail order ads in this issue of ST World for an ST computer. A 1040ST in 1989 sold for a grand total of between 350 and 380 pounds. Add a monitor and you're looking at a total system purchase of between 570 and 590 pounds with a color monitor and 100 pounds cheaper with a monochrome monitor. So the cost of a graphics accelerator for the ST was 2 to three times more expensive than the computer itself. Which detracts considerably to whole Atari notion of "Power Without the Price." Indeed, by the time you added all of this stuff to your ST you may as well have just dropped your wad on a Mac.

 

Yeah, I know that graphics boards aren't system accelerators, at least in as much as they don't replace the 68000 processor or increase the speed of the processor or system bus, but the point here is that accelerating the ST wasn't cheap. Hell, it was the exact opposite. It was outrageously expensive. And this, I submit, is the primary reason why most ST owners used essentially bog standard (factory stock) ST computers. i.e., ST owners chose the ST because it was cheaper than the competition and the upgrades for the ST put the ST on par, costwise, with the competition. So if you're going to spend the extra cash anyway, why on Earth would you choose an ST over something that already included what you would have to add to your cheaper ST?

 

And I think, in retrospect, it was this focus on cost that ultimately lead to Atari's downfall. They put too much effort into being cheap that they destroyed their own reputation and credibility in the marketplace. You can't market something as cheap and not expect consumers to equate 'cheap' with 'junk'.

 

But yeah, regardless of the reason, I never knew anyone with an accelerated ST.. Plenty of accelerated Macs & Amigas though..

I installed lots of the 16mhz accels for St's, seldom sold anything for Amiga.

on you other point about the ST, the main issue was that the did not innovate quickly enough. What amazes me is that Mac succeeded being as stupidly overpriced as it was.

[atarian63]

The ST was upgrade unfriendly by nature due to the closed nature of the system.

 

Even the cartridge interface was read only - rediculous.

There is a guy in Poland selling cart port based Hard drives, ssen them on ebay and on ebay uk. wonder how he worked around that?

[atarian63]

The ST was upgrade unfriendly by nature due to the closed nature of the system.

 

Even the cartridge interface was read only - rediculous.

 

The ST was really popular in Germany for some reason. I could never figure that out. In Germany, STs were sold at Apple-like boutique style stores and for some reason the ST even managed to catch on as a "business class" machine in Germany. I could never reconcile the appeal of the ST to Germans with the idea of "Germans making good stuff". You would tend to think that "making good stuff" would be indicative of a people who appreciate quality. Yet, they adopted the ST line of computers like no other country on the planet, a line of computers that were in no way known for being quality machines.

 

Even now, if you search the Internet for interesting ST stuff, the really cool ST screenshots will almost exlusively feature a desktop in the German language.

 

 

NOTE:

 

The United States was the largest market for the Atari 16 and thirty-two bit computers. Germany was the second largest. With a population differential ratio of approximately ten to one in favour of the United States, it is quite probable that Germany was the largest Atari market per capita. Go figure!

Makes perfect sense to me, maybe they are smarter than we are

I could never figure out how Apple in general caught on here. Overpriced crap.

Edited December 17, 2008 by atarian63

[Rybags]

Easy - better marketing strategies.

 

Education. And it had the Desktop Publishing market to itself, probably until around the late Windows 95 era.

[ijor]

First of all.. Lets talk about what EXACTLY the "ST MIDI INTERACE" is... This is a 6850 ACIA chip.. Originally designed for the old 6800 series machines.. It has an 8-bit data bus, synchronously interfaced to the 68000 and selected by 3 bits of "chip selects".. It has separate internal 8-bit shift registers for send & recieve and can be operated at baud rates of either 1/16th or 1/64th the speed of an external clock. In the case of the ST, this external clock is NOT the same as the CPU... Its generated by the GLUE chip which incidently does share the 8mhz CPU clock. The actual clock speed is 500khz (which divides by 64 to get 31.25khz).

 

And how do you think that GLUE generates the 500 KHz clock? Do you think that GLUE has an internal oscillator?

Of course not, the 500 KHz clock is just the incoming 8 MHz clock ("incidentaly" the same as the CPU clock) divided by 16.

 

In other words, the serial MIDI bit clock is exactly the CPU clock divided by 256 (16*16), and both clocks are synchronous because they are derived from the same crystal. The direct consequence of this is that there is a simple, power of two relation between CPU cycles and MIDI cycles.

 

Now, is this such a fabulous feature? Of course not. Is this something so unique that changed the history of computing? of course not.

 

Also, the theory of dependancy on "cycle exact code" goes out the window..

 

As you see, it doesn't.

 

Anyway, the synchronous relation between the MIDI and CPU clocks, has only a minor relation with "cycle accurate code". Cycle accurate code depends also on CPU features, on system wait states, interrupt jitter, and other issues.

 

The AMIGA serial port hardware is more than capable of performing the exact same function ...

Any machine can have an "ST MIDI PORT" with a ...

The ST MIDI hardware is IN NO WAY "superior"

 

Please stop thinking with that "superior" or "inferior" mentality. Did I use the word "superior" (or "better", or anything similar) at all?

 

I said it already several times, I am not claiming (neither care) if the ST has a "superior" MIDI interface or not. I was only explaining what was all about that rock solid timing.

 

What the coders DID WITH IT is a totally different argument...

 

I said since the start that it was much more about software than hardware issue.

 

I also think that ultimately, it is much more about market than anything else. For the pros (or semi-pros) it doesn't matter if an external MIDI interface costs U$5 or $500. They could afford both. Furthermore, they spent thousands of US dollars in software, extra hardware (again, no serious ST musician could afford not adding MIDI pass-through hardware).

[atariksi]

I could never reconcile the appeal of the ST to Germans with the idea of "Germans making good stuff". You would tend to think that "making good stuff" would be indicative of a people who appreciate quality.

 

Apparently Amiga isn't as good, and ST as bad, as you think. Personally (although I am far from being a German), when I first met both machines, ST had an appeal of nice and easy-to-use machine. Whereas Amiga was just odd.

 

I wonder why an ST/Amiga controversies have to be discussed on this (Atari 8-bit) forum?

 

The fact the ST came out before the Amiga and thus established some sort of software base and wasn't b&w like the Mac must have given it a boost in sales initially. One lack of foresight on Commodore's part was putting that battery on the motherboards of many Amigas. Even the A500 had a battery on its memory expansion card and I killed one of those memory expansion boards just prying out the leaking battery.

 

What did ST use for real-time clock?

 

This is in 8-bit forum as many people think Amiga is related to 8-bit technology and ST could have been an Amiga in some inconceivable parallel universe.

[ijor]

And accelerators for ST's are exceedingly rare. Probably because the ST had a bigger problem with programmers using tricks that were 68000 specific. Thus an 030 accelerator would break nearly half the software library.

 

Yes, ST accelerators were rare and expensive. And yes, the ST was extremely sensitive in this regard, anything else than a bog 8 MHz 68000 would create compatibility issues. Even just replacing a 68000 with a 68010 (as some people did), or doubling the clock as in the Mega STe would create problems.

 

The reasons are several. For one thing, some software used cycle exact coding (e.g: Specturm 512, or overscan needed that). Many copy protections depend not only on exact cycles, but also on the prefetch behavior on self-modify code. Lastly, even the OS itself used the higher bits of the PC.

 

Additionally, the video RAM architecture was relevant. In the ST, all the system RAM is available as video RAM. A fast accelator can't use the internal RAM, it would be too slow. It could use it, but it would spoil most of the acceleration. So for faster performance you would need external (so called "fast") RAM. And this RAM couldn't be used for video RAM.

 

Believe it or not. The "rock solid timing" of the ST we talked about before is very related to all of this. In this regard, the ST was similar to 8-bit computers or to a microcontroller architecture. It was fully predictable in terms of cycle accuracy. This lead to coders to use precisely this feature. Sometimes they didn't use it intentionally, but because of software bugs (I have seen load of bugs that depend on cycle accuracy). This whole "cycle accuracy" thing has some plus points, but it certainly has its minus side.

[Crazyace]

The ST was upgrade unfriendly by nature due to the closed nature of the system.

 

Even the cartridge interface was read only - rediculous.

There is a guy in Poland selling cart port based Hard drives, ssen them on ebay and on ebay uk. wonder how he worked around that?

 

There was a 128k address range - so it was pretty simple to get 16 write lines by using the address lines - It's how we did ST Replay

[MEtalGuy66]

First of all.. Lets talk about what EXACTLY the "ST MIDI INTERACE" is... This is a 6850 ACIA chip.. Originally designed for the old 6800 series machines.. It has an 8-bit data bus, synchronously interfaced to the 68000 and selected by 3 bits of "chip selects".. It has separate internal 8-bit shift registers for send & recieve and can be operated at baud rates of either 1/16th or 1/64th the speed of an external clock. In the case of the ST, this external clock is NOT the same as the CPU... Its generated by the GLUE chip which incidently does share the 8mhz CPU clock. The actual clock speed is 500khz (which divides by 64 to get 31.25khz).

 

And how do you think that GLUE generates the 500 KHz clock? Do you think that GLUE has an internal oscillator?

I never said it did..

Of course not, the 500 KHz clock is just the incoming 8 MHz clock ("incidentaly" the same as the CPU clock) divided by 16.

And in that respect, every damn clock in the AMIGA and MAC is divided from the same original oscillator frequency, by one division factor or another. I have some real nice timing diagrams illustrating the exact relationship between all of them. Would you like to see?

In other words, the serial MIDI bit clock is exactly the CPU clock divided by 256 (16*16), and both clocks are synchronous because they are derived from the same crystal. The direct consequence of this is that there is a simple, power of two relation between CPU cycles and MIDI cycles.

Once again, I dont need your trivial explanations of the blatently obvious. Consider what Im actually saying and the relevant points Im making.

Now, is this such a fabulous feature? Of course not. Is this something so unique that changed the history of computing? of course not.

 

Also, the theory of dependancy on "cycle exact code" goes out the window..

 

As you see, it doesn't.

The code that loads & unloads the data to the 6850 runs in an interrupt.. Thus, the application program does not have to keep track of machine cycles where this is concerned.

Anyway, the synchronous relation between the MIDI and CPU clocks, has only a minor relation with "cycle accurate code". Cycle accurate code depends also on CPU features, on system wait states, interrupt jitter, and other issues.

Yeah, Im assuming that standard 68000 interrupts are handled in some semblence of an efficent/normal manner. Many aspects of this can be changed in programmable registers on both systems.

The AMIGA serial port hardware is more than capable of performing the exact same function ...

Any machine can have an "ST MIDI PORT" with a ...

The ST MIDI hardware is IN NO WAY "superior"

 

Please stop thinking with that "superior" or "inferior" mentality. Did I use the word "superior" (or "better", or anything similar) at all?

 

I said it already several times, I am not claiming (neither care) if the ST has a "superior" MIDI interface or not. I was only explaining what was all about that rock solid timing.

YEah you really should reread the entire thread.. ANd youd realize that I niether asked for your input, nor have I been rebuting anything you said. I am merely responding to what was said by the "ST Guys" which was that the Atari ST midi hardware is superior to that of other platforms because of hardware characteristics of the system which give it the ability to maintain more accurate timing.

What the coders DID WITH IT is a totally different argument...

 

I said since the start that it was much more about software than hardware issue.

So did I

I also think that ultimately, it is much more about market than anything else. For the pros (or semi-pros) it doesn't matter if an external MIDI interface costs U$5 or $500. They could afford both. Furthermore, they spent thousands of US dollars in software, extra hardware (again, no serious ST musician could afford not adding MIDI pass-through hardware).

 

Good point.

Edited December 17, 2008 by MEtalGuy66

[atarian63]

Easy - better marketing strategies.

 

Education. And it had the Desktop Publishing market to itself, probably until around the late Windows 95 era.

I think you are correct, right place,right time.

[Fröhn]

Did the Amiga have other keyboard layouts? I guess, like many machines it probably had the UK version with Pound sign instead of "$" ?

Yes, there were german layouts, french layouts, portugisian layouts etc etc.

[ijor]

In the case of the ST, this external clock is NOT the same as the CPU... Its generated by the GLUE chip which incidently does share the 8mhz CPU clock.

 

And how do you think that GLUE generates the 500 KHz clock? Do you think that GLUE has an internal oscillator?

I never said it did..

 

You didn't. But then what was your point when saying, and in uppercase, that the clock is not the same as the CPU?

The only possible way I could understand this, is that you were claiming both clocks were not synchronous to each other. If that wasn't your point, I apologize.

 

And in that respect, every damn clock in the AMIGA and MAC is divided from the same original oscillator frequency, by one division factor or another.

 

Might be, I don't know but I'll trust you on that. This doesn't mean, however, than an external MIDI interface would clock the UART with the same oscillator. May be they do, I have no idea. But it would be very natural for an external interface to use its own UART with its own crystal.

 

For sure the PC has multiple crystals and oscillators, driving different clock domains that are not synchronous one with each other. Furthermore, the typical MIDI interface for the PC uses it own (yet another one) oscillator.

 

The code that loads & unloads the data to the 6850 runs in an interrupt.. Thus, the application program does not have to keep track of machine cycles where this is concerned...

Yeah, Im assuming that standard 68000 interrupts are handled in some semblence of an efficent/normal manner.

 

I never said that the MIDI serial clock being synchronous to the system is critical. I only mentioned it as an additional issue that helps syncing the whole timing. The code that access the UART doesn't have to be cycle accurate. I said that already when replying to Bryan above. Interrupt latency was an important issue though on a PC. At the time, it wasn't easy at all for a PC to keep the interrupt rate of the MIDI interface.

 

It is the overall syncing that is affected. The ST has a very predictable cycle accurate behaviour. To give you an idea, the ST can track the video electronic beam, and modify the video ram data or the color palette on the fly with cycle accuracy. This is actually how Spectrum 512 works. In a PC, e.g., you cannot even dream about doing something similar, not then at the time, even less nowadays in a modern PC.

 

Of course that a MIDI application doesn't need any Spectrum 512 effects. But that gives you an idea of what was the concept of "rock solid timing" about. What this "rock solid timing" significant for MIDI application at all? I don't know, I said that in my first post here.

 

I would suspect that it made coding for simple software MIDI easier, but it shouldn't matter at the pro-level. For a game with MIDI sound, it makes things easier for such purposes as syncing the video animation with the MIDI output. Again, you had an easy-simple-direct translation between video frames->cpu cycles->MIDI cycles. A high-end MIDI application can workaround synchronization issues both with high-quality coding and sophisticated hardware (as is done in a modern PC, I guess).

 

And btw, I don't consider this "cycle accurate", or "cycle predictable" to be a superior feature. It is a distinguished feature, certainly different than a PC. It is good for some purposes, it is bad for others. It certainly wasn't good for the purpose of backward compatibility with later ST models (as I explained in a previous post).

 

YEah you really should reread the entire thread.. ANd youd realize that I niether asked for your input, nor have I been rebuting anything you said. I am merely responding to what was said by the "ST Guys" which was that the Atari ST midi hardware is superior to that of other platforms because of hardware characteristics of the system which give it the ability to maintain more accurate timing.

 

You are right, sorry about that.

 

You were certainly replying to me before, because you quoted my posts. And in this one you weren't, but you were replying to issues (such as clock syncrhonization) that I was the one that raised them. But you are absolutely right that there were other people in this thread with an ST fan attitude, which I consider as silly and childish as an anti-ST attitude.

 

I actually was going to say something like this to them, and not to you, or at least not only to you. But then I put altogether mixing the technical with the non-technicals, and I really shouldn't have. Again, I apologize.

Edited December 17, 2008 by ijor

[MEtalGuy66]

IJOR:

 

 

Im sorry dude.. but a midi interface consisting of a 6850 with its own discrete 500khz oscilator to clock the midi-side bitrate, and hooked on the CPU/expansion bus of ANY machine with the same interrupt driven access sceme would have absolutely zero "timing" innacuracies when compared to the ST implementation.. Yes its a valid claim that the 500mhz clock is a divisor of the CPU clock frequency.. But it doesnt matter.. And I think you know this, after pointing out the nature of various bus communication methods..

 

 

ANd also, obviously, this topic would not even apply to the amiga serial port, as it is clocked directly by the CPU's eclock.

 

 

Also, nothing Ive said regarding this entire midi interface "timing" issue has been from an "anti-ST" point of view.. Its been from a "Lets be realistic" point of view..

 

 

As far as the ST being able to cycle-corolate color clocks, yes that is neat, considering that the hardware doesnt do that automatically.. And I have no doubt that the ST, being a closed architecture is a great deal more accurately timed in many respects than a generic shit-box PC of the era which would have depended on god knows what brand of thrid party hardware for everything from its display to its disk interface...

 

I have a DAMN hard time believeing however that it's internal timing characteristics are any more accurate than a MAC or AMIGA where their native chipsets & CPUs are concerned.. Considering the hardware features of the amiga, in particular, i'd venture to say that timing is pretty damn critical on a great many things.

[Fröhn]

I have a DAMN hard time believeing however that it's internal timing characteristics are any more accurate than a MAC or AMIGA where their native chipsets & CPUs are concerned.. Considering the hardware features of the amiga, in particular, i'd venture to say that timing is pretty damn critical on a great many things.

That's not true actually. Most timing critical things are done with the Copper which is the same for every Amiga no matter what CPU. Usually compability problems had other reasons, for example: Using OS routines but don't allocate memory with OS functions etc. Or expecting memory expansions at certain addresses. Only seldom it's timing which makes stuff incompatible, and in cases where it is, it's usually easy to fix (just add a blit-wait or similar).

 

That OS vs memory addresses is infact the most common part where programs break. I have an Amiga book here which explains how to code for amiga OS and it explains how to call graphics.library, intuition.library etc etc. But then there's stuff like "Ok now we call OpenLibrary(graphics.library) and put the bitmap at $50000". Horror stuff like that in a book which told you how to code.