4 ms·

Gary had himself to blame for failing to see the future of PC market. He build his company on selling tens to hundreds (per week) copies of the $700 CP/M OS use

by rasz_pl 11y ago

Gary had himself to blame for failing to see the future of PC market. He build his company on selling tens to hundreds (per week) copies of the $700 CP/M OS used to run $700 dBase II on $10K S100 systems. When IBM entered the market with PC/XT he insisted on pricing himself out of it at six times premium over DOS, as if he didnt believe industry would move in just few years from hundreds to almost hundred thousand boxes per week(1986). As for him being impartial I wouldnt go so far. I also remember that episode and how they showed bouncing ball on Atari with a stupid "see, we can do it too" comment, totally ignoring the fact Atari 520ST was burning >80% CPU just to blit that ball across the screen while Amiga did it all in hardware while CPU was free to run other programs in full preemptive multitasking OS :)

cmrdporcupine 11y ago
Who cares that the ST was burning CPU to do it, in the grand scheme of things at that point in time all the fancy custom circuitry of the Amiga got them... what... 3-4 years ahead of the curve at the cost of massive investment of R&D and a price premium... ? By 1990 stock commodity PC graphics cards on a stock x86 machine could outcompete the Amiga, and Commodore was totally unable to pull another Jay Miner with its next chip set. And multitasking on an 8mhz 68000 -- and with no memory protection in the slightest -- was not much of a win. We had multitasking extensions for the ST, too, and after fiddling with them for a while, the use cases were... unclear. Without an MMU it was dubious. In reality the ST was cheap competition for the Macintosh, not the Amiga. And paired with a hi-res monitor and Atari's cheap laser printer and a copy of Calamus it was a cuthroat priced, quality DTP workstation. Or in a studio as a sequencer hooked up to a bank of synthesizers. The Amiga found its niche in video applications... and games. Anyways, this is all off topic to Gary Kildall :-)
- scholia 11y ago
  > Commodore was totally unable to pull another Jay Miner with its next chip set. Indeed, bearing in mind that Jay Miner had designed his previous chips for Atari 8-bit computers, when he worked there. And that Commodore actually bought the Amiga from Amiga Corp ;-)
  - cmrdporcupine 11y ago
    Just imagine the alternate history where Atari hadn't disappeared up its own ass in the early 80s and all the amazing tech they were sitting on could have shipped. Terrible internal management, amazing engineering. They had dual CPU BSD workstation systems in development, the dual x86/6502 1450XL, the 128 oscillator AMY sound chip, Jay Miner/Amiga on contract for something new... Then they went tits up, Commodore had internal fighting with Tramiel, Tramiel and sons (and some ex-Commodore engineers) took the Atari name and some of its assets, and Commodore mismanaged the Amiga (and the remaining 8-bit stuff) for the next 5 years. If all that engineering talent could have just gotten their shit together instead of fighting over the table scraps... the PC industry would have been far more interesting.
- digi_owl 11y ago
  I find myself reminded of how the PC has hosted a number of hardware battles. The "custom vs commodity" thing reminds me of when 3DFX (remember them) started shipping. In a sense special chips, except without a specific computer wrapped around it. Makes one wonder where the Amiga had been had those chips been sitting at the end of a zorro bus rather than on the mainboard.
to3m 11y ago
This comment got me wondering! 80% seems like something of an overestimate. But is my memory rusty? The ball looks like it's about 128 pixels wide and 100 pixels high, so 8 words x 100 rows. Note how the screen appears to be laid out in a bitplane-minded fashion: you have a 1 plane backdrop, a 1 plane shadow, and a 2-plane bouncing ball. So, you don't have to mask in your background when writing. Load source, write dest. You'd pre-shift your ball lots of times to make this go quickly. (The shifted copies would have the ball's rotation applied, so you'd get a two-for-one with this.) One ball = 8 words * 2 bitplanes * 100 rows = 3,200 bytes. Plenty of room, even with 512K. So your loop for one row will go something like this, I guess. Assume A0 points to your 2-plane sprite data, arranged bitplane 0, bitplane 1, bitplane 0, bitplane 1, and so on, for 8 words, then your 1-plane shadow data, again 8 words. Assume A1 points to bitplane 0. First draw the ball: MOVEM.L (A0)+,D0-D7 ; 76 MOVE.L D0,(A1)+ ; 12 MOVE.L D1,1*8-4(A1) ; 16 MOVE.L D2,2*8-4(A1) ; 16 MOVE.L D3,3*8-4(A1) ; 16 MOVE.L D4,4*8-4(A1) ; 16 MOVE.L D5,5*8-4(A1) ; 16 MOVE.L D6,6*8-4(A1) ; 16 MOVE.L D7,7*8-4(A1) ; 16 So, 200 cycles per line. Then draw the shadow in the same sort of way into bitplane 2 (this is the reason for the (A1)+ and the -4s everywhere above - it lets you start off with (A1) here, rather than 4(A1), saving you 4 cycles). MOVEM.W (A0)+,D0-D7 ; 44 MOVE.W D0,(A1) ; 8 MOVE.W D1,1*8(A1) ; 12 MOVE.W D2,2*8(A1) ; 12 (and so on, as above) So, for that, 136 cycles per line. Cycles per frame = 8,000,000/50 = 160,000; cycles per ball = (200+136)*100 = 33,600. Taking into account that you'd have to erase the old ball and its shadow, and you'd have to advance your pointer from row to row, and whatnot - maybe 25% in total?
- rasz_pl 11y ago
  I have no clue about planar graphic modes, but wouldnt you need to modify all of the bitplanes when moving a sprite (backgrount is a grid, not a solid color)? Right, forgot ST cant do 640×512 4bit, so it would have to fake it at 4x smaller picture, that shrinks requirements considerably. What is ST memory bandwidth? something like almost 40KB per frame? Sure, you can use pre rendered screens, at that point you could argue C64 could do raytracing because this: https://www.youtube.com/watch?v=yxZ7Idi2Bi4 https://www.youtube.com/watch?v=yxZ7Idi2Bi4 displayed on real C64 with 16MB ram expansion, every frame of animation is 2 frame buffers in 320x200 ~16color NUFLI mode.

by rasz_pl 11y ago

cmrdporcupine 11y ago

Who cares that the ST was burning CPU to do it, in the grand scheme of things at that point in time all the fancy custom circuitry of the Amiga got them... what... 3-4 years ahead of the curve at the cost of massive investment of R&D and a price premium... ? By 1990 stock commodity PC graphics cards on a stock x86 machine could outcompete the Amiga, and Commodore was totally unable to pull another Jay Miner with its next chip set. And multitasking on an 8mhz 68000 -- and with no memory protection in the slightest -- was not much of a win. We had multitasking extensions for the ST, too, and after fiddling with them for a while, the use cases were... unclear. Without an MMU it was dubious. In reality the ST was cheap competition for the Macintosh, not the Amiga. And paired with a hi-res monitor and Atari's cheap laser printer and a copy of Calamus it was a cuthroat priced, quality DTP workstation. Or in a studio as a sequencer hooked up to a bank of synthesizers. The Amiga found its niche in video applications... and games. Anyways, this is all off topic to Gary Kildall :-)

scholia 11y ago
> Commodore was totally unable to pull another Jay Miner with its next chip set. Indeed, bearing in mind that Jay Miner had designed his previous chips for Atari 8-bit computers, when he worked there. And that Commodore actually bought the Amiga from Amiga Corp ;-)
- cmrdporcupine 11y ago
  Just imagine the alternate history where Atari hadn't disappeared up its own ass in the early 80s and all the amazing tech they were sitting on could have shipped. Terrible internal management, amazing engineering. They had dual CPU BSD workstation systems in development, the dual x86/6502 1450XL, the 128 oscillator AMY sound chip, Jay Miner/Amiga on contract for something new... Then they went tits up, Commodore had internal fighting with Tramiel, Tramiel and sons (and some ex-Commodore engineers) took the Atari name and some of its assets, and Commodore mismanaged the Amiga (and the remaining 8-bit stuff) for the next 5 years. If all that engineering talent could have just gotten their shit together instead of fighting over the table scraps... the PC industry would have been far more interesting.
digi_owl 11y ago
I find myself reminded of how the PC has hosted a number of hardware battles. The "custom vs commodity" thing reminds me of when 3DFX (remember them) started shipping. In a sense special chips, except without a specific computer wrapped around it. Makes one wonder where the Amiga had been had those chips been sitting at the end of a zorro bus rather than on the mainboard.

to3m 11y ago

This comment got me wondering! 80% seems like something of an overestimate. But is my memory rusty? The ball looks like it's about 128 pixels wide and 100 pixels high, so 8 words x 100 rows. Note how the screen appears to be laid out in a bitplane-minded fashion: you have a 1 plane backdrop, a 1 plane shadow, and a 2-plane bouncing ball. So, you don't have to mask in your background when writing. Load source, write dest. You'd pre-shift your ball lots of times to make this go quickly. (The shifted copies would have the ball's rotation applied, so you'd get a two-for-one with this.) One ball = 8 words * 2 bitplanes * 100 rows = 3,200 bytes. Plenty of room, even with 512K. So your loop for one row will go something like this, I guess. Assume A0 points to your 2-plane sprite data, arranged bitplane 0, bitplane 1, bitplane 0, bitplane 1, and so on, for 8 words, then your 1-plane shadow data, again 8 words. Assume A1 points to bitplane 0. First draw the ball: MOVEM.L (A0)+,D0-D7 ; 76 MOVE.L D0,(A1)+ ; 12 MOVE.L D1,1*8-4(A1) ; 16 MOVE.L D2,2*8-4(A1) ; 16 MOVE.L D3,3*8-4(A1) ; 16 MOVE.L D4,4*8-4(A1) ; 16 MOVE.L D5,5*8-4(A1) ; 16 MOVE.L D6,6*8-4(A1) ; 16 MOVE.L D7,7*8-4(A1) ; 16 So, 200 cycles per line. Then draw the shadow in the same sort of way into bitplane 2 (this is the reason for the (A1)+ and the -4s everywhere above - it lets you start off with (A1) here, rather than 4(A1), saving you 4 cycles). MOVEM.W (A0)+,D0-D7 ; 44 MOVE.W D0,(A1) ; 8 MOVE.W D1,1*8(A1) ; 12 MOVE.W D2,2*8(A1) ; 12 (and so on, as above) So, for that, 136 cycles per line. Cycles per frame = 8,000,000/50 = 160,000; cycles per ball = (200+136)*100 = 33,600. Taking into account that you'd have to erase the old ball and its shadow, and you'd have to advance your pointer from row to row, and whatnot - maybe 25% in total?

rasz_pl 11y ago
I have no clue about planar graphic modes, but wouldnt you need to modify all of the bitplanes when moving a sprite (backgrount is a grid, not a solid color)? Right, forgot ST cant do 640×512 4bit, so it would have to fake it at 4x smaller picture, that shrinks requirements considerably. What is ST memory bandwidth? something like almost 40KB per frame? Sure, you can use pre rendered screens, at that point you could argue C64 could do raytracing because this: https://www.youtube.com/watch?v=yxZ7Idi2Bi4 https://www.youtube.com/watch?v=yxZ7Idi2Bi4 displayed on real C64 with 16MB ram expansion, every frame of animation is 2 frame buffers in 320x200 ~16color NUFLI mode.