What if things had gone differently?

[Thomas Richter]

Originally Posted by Samurai_Crow

SpritePorts that hold each sprite image would replace vsprites and simplesprites both by generating a Bitmap structure. Once there, if one wants to use the blitter on a SpritePort, it's just a matter of passing that Bitmap struct to create RastPort.

The common denomiator of blitter and sprite engine is called a vsprite within a Bob. The simple sprite is a sprite exclusively allocated, whereas a VSprite is a virtual object that uses one of the hardware sprites as underlying resource. Thus, in that sense, the thing exists.

Originally Posted by Samurai_Crow

SortCop() would replace MrgCop() using a position header in the CopperNode structure. That structure will contain fully-encoded copper moves generated by macros. Copper skips are pretty useless and should be reserved for manual bypass mode, as should copper based blitter waiting.

Not clear what you mean. MrgCop() exists to merge already existing copper lists into one hardware list, in particular the lists from the viewports, the vsprites and the user copper list. They are already sorted by nature, but the tricky part is that the blitter can only do a limited number of operations per position.

Originally Posted by Samurai_Crow

QBlit() and the corresponding dequeue interrupt should have been rewritten in Assembly so they can stack push only the registers actually used and retrieve them at the end. C compilers just push and pop all registers to the stack indescriminately. What a waste!

QBlit and the corresponding dequeue interrupt *are* written in assembler, actually. While I do not know which compiler you use, SAS/C only pushes the registers its compiled code uses on the stack.

[Gorf]

Originally Posted by Bruce Abbott

Commodore launched its first PC clone,

And payed for a license they never used ... afaik Commodore never produces any 8088.

I wonder how this came about ... did CSG run into problems making a 8088? Did management not ask CSG if this is something they could do beforehand?

[Bruce Abbott]

Originally Posted by Gorf

And payed for a license they never used ... afaik Commodore never produces any 8088.

I wonder how this came about ... did CSG run into problems making a 8088? Did management not ask CSG if this is something they could do beforehand?

The 8088 clone that wasn’t

In 1984, Commodore International licensed to the rights to manufacture 8088 CPUs. Commodore’s subsidiary, MOS Technology, had two chip fabrication plants at the time, and the speculation was they were going to enter the PC clone market and manufacture the chips themselves to allow them to meet a lower price point. While Commodore did go on to release a number of products using 8088 CPUs, as far as I know, they never used any self-made 8088 CPUs in any of their products. Every 8088-based Commodore product I have seen, whether it was a PC or a bridgeboard for an Amiga, used a Siemens 8088.

There were probably two reasons for this. Commodore did not have state of the art manufacturing capabilities, so they weren’t getting the number of chips per wafer that most other manufacturers were getting by 1984. This meant they couldn’t produce as many chips as other companies could, and it meant the chips they produced cost more... It’s also possible it cost them more to make an 8088 than it cost to just buy an 8088 from Siemens...

This makes sense. They probably got an excellent deal from Siemens, who were the largest second-source manufacturer of the 8088.

[CCCP alert]

I only knew of the Commodore 128D lookalike called the PC-1. That was the same price as the Atari PC1 (almost identical specs) and these 8088 PCs came a fair bit after the Amstrad PC1512, also cost £100 more than the 8086 based PC1512.

From wikipedia
Commodore PC 5 Introduced in 1984, at $1395, the Commodore PC 5 is the low-budget option with a monochrome video card. It has a Intel 8088 running at 4.77 MHz and 256 KB RAM on-board (expandable to 640 KB)

Commodore PC 10 The Commodore PC 10 is a PC 5 with a added color video card and two floppy drives (so still 256kb)

Then it gets confusing with the following...
Commodore PC 10-1 512 KB RAM and single floppy drive version. $519
Commodore PC 10-2 640 KB RAM and dual floppy Drives. $619

So looking at $100 for 128k and 5 1/4 disk drive I can only guess that $619 = extra 384kb of DRAM and a color (EGA? CGA?) video card over the cost of the PC 5, which is like $2000 in 1984.

These sound like Gould 1984 projects to me. "Gould replaced Tramiel with Marshall F. Smith, a steel executive without a computer or consumer marketing experience."

The time when the chicken head company became the headless chicken company.

If Tramiel wanted your market segment you would know about it. This 256k $1400 mono 4.77mhz 8088 PC without monitor doesn't sound like a Tramiel product at all, it makes no sense and the person who came up with this damp fart of an idea would be Jack Attacked out the building more like Tramiel is the sort of person who would be at MOS first finding out if they could make a compatible CPU and pay nothing to anybody, just like with the 6800 vs 6501 (then 6502). Remember he took his eye off the low selling/high profit PET and focussed on the massive selling/massive profit root MOS engineers in his back pocket allowed. Clearly MOS told him they couldn't competively make LCD displays so he went out and acquired Eagle Pitcher to make the Commodore LCD feasible at prototype stage.

Getting a licence, finding out they can't produce the 8088 in house cheaper, giving up....this sequence of events is 100% arse over tit work of the losers Gould had replaced Tramiel with. Just like the Plus/4 costing more than the C64 idea LOL

[Samurai_Crow]

Originally Posted by Thomas Richter

The common denomiator of blitter and sprite engine is called a vsprite within a Bob. The simple sprite is a sprite exclusively allocated, whereas a VSprite is a virtual object that uses one of the hardware sprites as underlying resource. Thus, in that sense, the thing exists.

It exists but is too heavy to be useful. Just allocating a SpritePort doesn't use the blitter at all. Only the control words are written and the uninitialized chip RAM's width and depth are returned in an interleaved Bitmap structure from the sprite DMA buffer. If the application programmer wants a static image, they can blit it as a JAM2 image, fill it with a solid color or draw it as a vector image. Bobs can even be blitted to sprite buffers!

If you want to preserve backward compatibility, the SpritePort would fit between the VSprite structure and the raw sprite hardware buffer. SimpleSprites don't allow multiple SpritePorts to be allocated from the same channel making them just as inflexible as the VSprites are heavy. Both SimpleSprites and VSprites would be rendered obsolete.

Originally Posted by Thomas Richter

Not clear what you mean. MrgCop() exists to merge already existing copper lists into one hardware list, in particular the lists from the viewports, the vsprites and the user copper list. They are already sorted by nature, but the tricky part is that the blitter can only do a limited number of operations per position.

MrgCop() requires the copper instructions to be already written in the order that they are used. This is seldom the case when dual-playfield mode is used with sprites. If you need to sort the order of the positions of the copper node structures proposed, merging after sorting becomes an utter waste of time. Just use a natural merge-sort to do both!

The header of the copper node structure contains the approximate raster position for the CWAIT to be generated from. It is followed by 1 or more CMOVEs computed at compile time using preprocessor macro functions.

A typical use case for sorted copper nodes are palette changes that scroll at different speeds from each other vertically along with other changes that need to interleave with each other at various different intervals. The positions in the headers for the CWAITs to be generated from are almost always quazi-random ordered relative to one another prior to being sorted.

[Thomas Richter]

Originally Posted by Samurai_Crow

It exists but is too heavy to be useful.

Why? It also only runs the blitter, just through a different path. The only thing it does not do is interleaved. Frankly, I doubt that introducing another sprite engine after the last one was not used is not particularly helpful at all.

Originally Posted by Samurai_Crow

MrgCop() requires the copper instructions to be already written in the order that they are used.

MrgCop() requires copper instructions to be already present in three intermediate copper lists, so that is not *quite* equivalent. It only takes three copper lists (bitplane, vpsrite and user copper lists) and not four (two bitplanes instead of one), so that is probably the only limitation that comes to my mind. Why would you want to create intermediate copper lists out of order?

Originally Posted by Samurai_Crow

Just use a natural merge-sort to do both!

MrgCop() is a merge sort - of three sorted lists. It does, however, do a bit more than that.

Originally Posted by Samurai_Crow

A typical use case for sorted copper nodes are palette changes that scroll at different speeds from each other vertically along with other changes that need to interleave with each other at various different intervals.

I'm not sure what you mean. The sprite copper lists for example already set sprite colors "at arbitrary vertical positions", namely where the vsprites end up.

[Bruce Abbott]

Originally Posted by CCCP alert

I only knew of the Commodore 128D lookalike called the PC-1. That was the same price as the Atari PC1 (almost identical specs) and these 8088 PCs came a fair bit after the Amstrad PC1512, also cost £100 more than the 8086 based PC1512.

Amstrad designed their own chips for the PC1512, and built it in the same far East factory as the CPC range. Problem was that to get around IP issues and reduce the price they strayed from the IBM PC standard. Some of the peculiarities include a non-standard keyboard with incompatible communications protocol, power supply in the monitor (like the CPC), and a 640x200 16 color graphics mode that wasn't used by anything except GEM. You couldn't upgrade the video to EGA or VGA because the on-board controller couldn't be turned off, but you wouldn't want to do that anyway because you had to use the original monitor to power the computer.

The 8 MHz 8086 wasn't as fast as you might think either. One reason is that it has 8 bit instructions that tend to split memory accesses so it's only ~1.5 x faster than an 8088 at the same clock speed. The other reason is the peripherals and video controller are still all 8 bit running at ~5 Mhz.

I had a PC1512 with hard drive and 'paper-white' analog monochrome monitor. The screen display looked pretty nice but the long-persistence phosphor made action games awkward. My workmates and I had fun playing Leisure Suit Larry on it in 4 glorious shades of grey and PC speaker sound!

These sound like Gould 1984 projects to me. "Gould replaced Tramiel with Marshall F. Smith, a steel executive without a computer or consumer marketing experience."

Commodore PCs were designed and built in Germany. They did rather well over there, for a time being the biggest selling PC clone in Germany. They did quite well here in New Zealand too - in part because they were better built, more reliable and easier to set up than typical Taiwanese clones.

Very few PC-1's were made. It was designed to counter Atari's PC1, which was introduced in 1987 for $599. They needn't have bothered though because Atari's PC clones bombed.

Atari PC1: The Atari IBM-compatible

Atari made a line of PCs in the 1980s, which seems contradictory because it is... in hindsight, it’s easy to see why the Atari PC1 was a mistake and how it impacted the rest of the line...

The PC1, introduced in 1987, sported an 8088-2 CPU and a highly integrated motherboard for the time. Building in video, serial and parallel ports and a disk controller allowed Atari to make the system smaller and cheaper, and the system fit nicely in an Atari Mega ST case. Atari also included ports so you could plug in Atari ST-compatible external floppy and hard drives into the system.

But there were problems with this approach. First, the presence of only one floppy drive was a problem. A single-drive PC wasn’t very useful in 1987. Popular PC software frequently used two drives. So by the time you bought the PC1 and an external floppy drive, the system wasn’t any more compact than a more traditional PC and it lost most or all of its price advantage too.

Second, the PC1 didn’t have internal expansion slots. Atari built EGA graphics into the system, but in 1987, VGA graphics came out. If you had expansion slots, you could upgrade to VGA. But not with Atari. A year or two later when sound cards started appearing, the PC1 didn’t have anywhere to plug one in.

Originally Posted by CCCP alert

Tramiel is the sort of person who would be at MOS first finding out if they could make a compatible CPU and pay nothing to anybody, just like with the 6800 vs 6501 (then 6502).

Except Atari did make PC clones under Jack's direction, and they used Intel CPUs.



Commodore did a lot better with their PC clones than Atari did. This blows out of the water the theory that Jack would have managed it a lot better.

BTW Commodore wasn't the only one to get a license to make 8088's and not make use if it. MOSTEK did the same. They didn't receive any of the assets required (schematics, chip layout etc.) to clone it. The same may have applied to Commodore. The rights may have just been so they could get another manufacturer to make the chips for them without worrying about being sued.

[Gorf]

Originally Posted by Bruce Abbott

BTW Commodore wasn't the only one to get a license to make 8088's and not make use if it. MOSTEK did the same. They didn't receive any of the assets required (schematics, chip layout etc.) to clone it. The same may have applied to Commodore. The rights may have just been so they could get another manufacturer to make the chips for them without worrying about being sued.

Well MOSTEK is a very interesting but different story:
They went from Nr. 1 DRAM producer with >60% market share to almost bankruptcy in 1985, because a Japanese cartel was dumping RAM chips, forcing eventually all US RAM manufacturers out of that business...
(Courts ruled the dumping was illegal and from 86 on the US put tariffs on DRAM from Japan - but it was too late by then. Jack Tramiel's Atari got involved in some illegal importing of DRAM the following years...)

MOSTEK not only got a 8088 license but a general x86 license, that would have allowed them to eventually produce 286, 386, 486 - and in fact they did, but only after they were acquired by French STMicroelectronics.
Cyrix CPUs up to the 386 were produced by STM, since Cyrix did not have a fab nor the rights ...

MOSTEC's licenses and patents made eventually hundreds of millions for STM, which only payed $70 million for MOSTEK in 1985.

MOSTEK also had a second source license for the 68000 and the Z80 by the way.

If I were a time traveling billionaire I would acquire Amiga Inc. in 84, MOSTEK in 85 and Sinclair in 86 - that would be an unstoppable combination.

[grond]

Originally Posted by Gorf

If I were a time traveling billionaire I would acquire Amiga Inc. in 84, MOSTEK in 85 and Sinclair in 86 - that would be an unstoppable combination.

Why Sinclair?

[Gorf]

Originally Posted by grond

Why Sinclair?

because Clive was desperate in 86 - it was sold to Amstrad for only £5 million (+ £10 million for outstanding contracts ...)
It was a steal - the inventory of Spectrums was worth about the same..

The Spectrum kept on selling quite well under Amstrad for a couple of years.

The QL was stopped already under Clive, but an Amiga could have provided a nice upgrade path and even provide full compatibility: QDOS4Amiga

Sinclair also had partnered up with Samsung in Korea for cheap production.

And it had all the necessary distribution channels all over Europe.

And even if the brand did not stand for high quality, at least Sinclair was known all over Europe and that would have made it much easier compared to a total newcomer in the business.

[Cris1997XX]

All these "what-if" threads might be useless wishful thinking, but I'm still learning a lot about the old days of the personal computer market

[TEG]

Originally Posted by Bruce Abbott

Commodore did a lot better with their PC clones than Atari did. This blows out of the water the theory that Jack would have managed it a lot better.

This is comparing apples with oranges. Tramiel would have different conditions if he stayed at Commodore. We can't draw conclusions so easily.

[Gorf]

Originally Posted by Bruce Abbott

The 8088 clone that wasn’t

This makes sense. They probably got an excellent deal from Siemens, who were the largest second-source manufacturer of the 8088.

Only one of these two things make sense:
Either is was cheaper anyway to buy the 8088 (and the V20 in other Commodore products) elsewhere, or acquiring a expensive license to produce it in your own fab.

Acquiring a incense without being able to produce it (in quantities) and therefore buy it elsewhere, that is just wasting money.

[Gorf]

Originally Posted by Bruce Abbott

Very few PC-1's were made. It was designed to counter Atari's PC1, which was introduced in 1987 for $599. They needn't have bothered though because Atari's PC clones bombed.
...
Commodore did a lot better with their PC clones than Atari did. This blows out of the water the theory that Jack would have managed it a lot better.

Well - only the PC-1 was of course not the only Atari PC:

The PC-1 was followed by PC-2 and by 1990 they had a whole series of PCs...
PC-3, PC-4, PC-5 going up to 80386 processors ...

The last model was the ABC386DXII

[Bren McGuire]

did we really need another thread of this kind to see the same 3 men have their spergfight?

Originally Posted by TCD

And there we go.

[Bruce Abbott]

Originally Posted by Gorf

Well - only the PC-1 was of course not the only Atari PC:

The PC-1 was followed by PC-2 and by 1990 they had a whole series of PCs...
PC-3, PC-4, PC-5 going up to 80386 processors ...

The last model was the ABC386DXII

Thanks for that. It's hard to find English sites with good info on Atari's PC clones. I'm wondering if the reason for that might be that they only sold well in Germany?

Originally Posted by TEG

This is comparing apples with oranges. Tramiel would have different conditions if he stayed at Commodore. We can't draw conclusions so easily.

I think we can actually. I think he just continued doing what he would have done at Commodore - assuming Gould let him. That's why he left!

[Samurai_Crow]

Originally Posted by Thomas Richter

Why? It also only runs the blitter, just through a different path. The only thing it does not do is interleaved. Frankly, I doubt that introducing another sprite engine after the last one was not used is not particularly helpful at all.

Fine. Back to hardware banging it is. Throw out Graphics.library altogether. Problem solved.

Originally Posted by Thomas Richter

MrgCop() requires copper instructions to be already present in three intermediate copper lists, so that is not *quite* equivalent. It only takes three copper lists (bitplane, vpsrite and user copper lists) and not four (two bitplanes instead of one), so that is probably the only limitation that comes to my mind. Why would you want to create intermediate copper lists out of order?

It needs arbitrary numbers of copper lists to be able to implement a proper natural mergesort. Adaptive sort routines like a natural mergesort already take advantage of any ordered sections of list as it is.

One of the most common scrolling effects of the copper is a "tube" scroller where the bottom of the screen buffer has a negative modulo assigned by the copper to wrap the bitplane around to the beginning of the buffer and another copper instruction to restore the modulo to its previous value a pixel row lower. There will likely be additional copper instructions in between those 2 CWAIT CMOVE sequences for color changes (most likely NOT limited to vsprite color changes). This allows infinite vertical scrolling with little blitter involvement.

[Thomas Richter]

Originally Posted by Samurai_Crow

Fine. Back to hardware banging it is. Throw out Graphics.library altogether. Problem solved.

The problem was solved already upfront. You have a working BOB/Sprite engine, and I do not see any major deficiencies with it given the limitations of the hardware. The major issue is a design problem, namely lack of abstraction. However, VSprites are already so much bound to Amiga hardware and the copper that it is quite unclear how to abstract that - RTG hardware does not have an arbitrary number of sprites or sprite splitting.

Originally Posted by Samurai_Crow

It needs arbitrary numbers of copper lists to be able to implement a proper natural mergesort. Adaptive sort routines like a natural mergesort already take advantage of any ordered sections of list as it is.

Now you start arguing backwards from a solution, but once again, why do you need that solution? Graphics has 3 sources of copper lists: Those for creating the playfield, those for the sprites, and everything else the user wants to bang. Now say again why you need more.

Originally Posted by Samurai_Crow

One of the most common scrolling effects of the copper is a "tube" scroller where the bottom of the screen buffer has a negative modulo assigned by the copper to wrap the bitplane around to the beginning of the buffer and another copper instruction to restore the modulo to its previous value a pixel row lower. There will likely be additional copper instructions in between those 2 CWAIT CMOVE sequences for color changes (most likely NOT limited to vsprite color changes). This allows infinite vertical scrolling with little blitter involvement.

First, why does that require additional intermediate copper lists then? If you want vsprites on top, you can do so as they have their own copper list. However, the copper only has limited bandwidth, so this does not necessarily go well.


Actually, the copper is probably too limited as concept anyhow - it was a rather simple solution for creating richer displays, a problem that is solved today by the render pipeline of the graphics card. That's a much more flexible approach.

[Samurai_Crow]

Originally Posted by Thomas Richter

The problem was solved already upfront. You have a working BOB/Sprite engine, and I do not see any major deficiencies with it given the limitations of the hardware. The major issue is a design problem, namely lack of abstraction. However, VSprites are already so much bound to Amiga hardware and the copper that it is quite unclear how to abstract that - RTG hardware does not have an arbitrary number of sprites or sprite splitting.

Most of those got a cache controller instead of the Budgie chip too. RTG is not a good solution to Graphics.library either. You need a fresh start for that. Maybe even a different entire OS.

Originally Posted by Thomas Richter

Now you start arguing backwards from a solution, but once again, why do you need that solution? Graphics has 3 sources of copper lists: Those for creating the playfield, those for the sprites, and everything else the user wants to bang. Now say again why you need more.


First, why does that require additional intermediate copper lists then? If you want vsprites on top, you can do so as they have their own copper list. However, the copper only has limited bandwidth, so this does not necessarily go well.

How many playfields do the Amiga chipset support? I count 2. Now you have to keep color changes in sync between them and bitplane modulos and pointers ×2. Added to that, the tube scrollers in each playfield usually scroll independently of one another so they can't just share a copper channel.

Originally Posted by Thomas Richter

Actually, the copper is probably too limited as concept anyhow - it was a rather simple solution for creating richer displays, a problem that is solved today by the render pipeline of the graphics card. That's a much more flexible approach.

New technology is off-topic for this thread.

[grond]

Originally Posted by Gorf

Acquiring a incense without being able to produce it (in quantities) and therefore buy it elsewhere, that is just wasting money.

Not necessarily. Being able to produce a product you then buy from a supplier has strategic advantages. You could set up your own "second source" for the part (if you can't get them any more) and you could put pressure on the supplier to provide the part cheap enough to not make you build it yourself.