what if the cpc+ had 32 hardware sprites and they had 256 colours..

[arnoldemu]

I remember in amstrad action it mentioned that the cpc+ would have 32 hardware sprites.
It may have said 64... but I don't remember exactly.

maybe it really did have 32, but they had to cut back because of too many gates in the asic.

But lets imagine

Sprite data would go from &4000-&6000.
sprite x,y,mag would go from &6000-&6100.

it would fit quite nicely


ok what if the sprite pixels were not nibbles but bytes. We could use 256 colours?

that would fit too. the sprite palette would go from &6422 to &6622.
(palette for screen would not be touched)

but the problem, lots more gates for this, much bigger asic.... more money.


but it would all fit....

so who is up for making a Plus+ with more?

[steve]

Perhaps a blitter would be  better use for those extra gates.

[TotO]

Sure, a blitter is definitively more usefull for speed-up the cpc display for all uses and not only games with sprites... Programmer can do what they want with, not limited like a C64 is. 
Amstrad made the wrong choice for the CPC+... A DMA blitter have made this computer ever better.

[TFM]

...
maybe it really did have 32, but they had to cut back because of too many gates in the asic.

It's not about Gates. Sprites need ASIC RAM. And RAM is the by far MOST expensive part of the ASIC. But if you use the bigger version of the ASIC, then - as you have already discovered - you will have everything you need. Even the logic is there :-) Yes, it is!

... A DMA blitter have made this computer ever better.

Amstrads philosophy was in one word "DO IT CHEAP". A blitter and the 297 great ideas of MacDeath would have been all too expensive. Keeping production costs down was their main target - luckily usually NOT on the cost of quality (which can be seen f.e. by using the data seperator for the FDC).

[arnoldemu]

Sure, a blitter is definitively more usefull for speed-up the cpc display for all uses and not only games with sprites... Programmer can do what they want with, not limited like a C64 is. 
Amstrad made the wrong choice for the CPC+... A DMA blitter have made this computer ever better.

A blitter may have been possible if you hog the bus and stop the z80.

On Amiga the design was done so that all parts can exist together and can run in parallel, and there was specific timing within each line to allow these things to happen, but on cpc+ they have used all the cycles. They used the "spare" cycles in hsync for sound dma.

The other cycles are taken for display and memory refresh.

If you stop the z80 then the dma blitter can transfer 1 or more bytes per microsecond (perhaps more), depending on how it would work with the video.

This doesn't sound good? Well the dma could read/write faster than the z80 would do it, and it could perform masking operations at the same time. So it would be better.


In the original post, it just seemed like the designers of the cpc+ had setup the registers in a way that allowed 32 sprites, but because of ram costs they cut it back.

[TotO]

In the original post, it just seemed like the designers of the cpc+ had setup the registers in a way that allowed 32 sprites, but because of ram costs they cut it back.

A shame when you know that sprites waste half of the memory by using only 4bit per byte. It may be why we don't get 32 at end...

[arnoldemu]

A shame when you know that sprites waste half of the memory by using only 4bit per byte. It may be why we don't get 32 at end...

I don't think they waste half the internal memory of the asic. I think it is how the map into into z80 ram.
But sure, it is mapped badly, when we could have 2 pixels per byte.

[TFM]

In the original post, it just seemed like the designers of the cpc+ had setup the registers in a way that allowed 32 sprites, but because of ram costs they cut it back.

Right, that's exactly what I posted before and it is a matter of fact.

A shame when you know that sprites waste half of the memory by using only 4bit per byte. It may be why we don't get 32 at end...

Exactly! The original design provides 255 colors + invisible. Now they saved half the RAM again, so 4 of 8 bits ramain, that makes 15 colors + Invisible.

However, the protype-ASIC is to hard to solder in the 6128 Plus. All that SMD stuff is no fun. So I sadly see very limited practical use.
However a clone of the 6128 Plus could contain all that features in an bigger ASIC.

[arnoldemu]

Right, that's exactly what I posted before and it is a matter of fact.

I didn't know it was fact that it would have 32 sprites and 256 colours?

[MacDeath]

While the sprites of the PLUS are clearly somewhat bastard, they have the merit that each pixels can be addressed individually thx to the fact they "waste" 4bits...


Had they gone for 32 sprites in "real" 4bpp (= mode0 like)  this could have been nice too, but having twice the number of sprites to implement/manage would have been definitely a lot of additionnal stuff inside the ASIC...

Even 16 sprites but in 32x16 pixels in real 4bpp could have been nice. But it wouldn't be a gain in the speed when uploading sprites Datas into ASIC, and this could even result in somewhat too big sprites (not a problem to me...)

Had they kept the 16 sprites in 16x16x16 in real 4bpp, you may have the sprites twice faster to upload into ASIC I guess (sort of...I mean this would wheight half), but then you loose this ability to go easily for individual pixels address.

In Demo it can really be interesting to address each sprites' pixels, in games perhaps less interesting/exploitable.


BTW PLUS would really need 2 ASICs to be perfect, and it was clearly a No-No from mister Sugar.





MSX2+ were expensive to build, Amstrad PLUS weren't..

[TFM]

Up to the 6128 the Amstrad company did quite well. Then ... they planned the ANT and dropped it, then... they planned the 6128Plus ... and cut it in a quarter. The left quarter was finally sold. So - however - even if the sprites only have 15 colors and it has only 16 sprites. This stuff can be used very nicely.

The only thing I really miss (and that would have solved ASIC-RAM cost problems too!) is the feature to define a RAM part for a sprite. This would make a quantum jump!!!
Imagine you just tell the machine where in RAM the sprite starts... imagine 

[arnoldemu]

Up to the 6128 the Amstrad company did quite well. Then ... they planned the ANT and dropped it, then... they planned the 6128Plus ... and cut it in a quarter. The left quarter was finally sold. So - however - even if the sprites only have 15 colors and it has only 16 sprites. This stuff can be used very nicely.

The only thing I really miss (and that would have solved ASIC-RAM cost problems too!) is the feature to define a RAM part for a sprite. This would make a quantum jump!!!
Imagine you just tell the machine where in RAM the sprite starts... imagine 

@TFM: Do you have any proof that the ASIC would have more sprites and more colours for each sprite?
Any magazine information?
What about the ANT do you have any information here?

[McKlain]

The only thing I really miss (and that would have solved ASIC-RAM cost problems too!) is the feature to define a RAM part for a sprite. This would make a quantum jump!!!
Imagine you just tell the machine where in RAM the sprite starts... imagine 

Just like the c64, doesn't it?

[TFM]

@McKlain: Of Course :-)

@Arni: Proof? Gosh.... the MI6 will not allow me... /connection interrupted/
Well, I have to look that up, but about the ANT (IMHO) you should find some stuff here (Wiki). No, I don't own any of that hardware. Got some papers in good old Germany though.

[ivarf]

Up to the 6128 the Amstrad company did quite well. Then ... they planned the ANT and dropped it, then... they planned the 6128Plus ... and cut it in a quarter.
Imagine you just tell the machine where in RAM the sprite starts... imagine 

Imagine the ANT and 6128+ being done by MEJ electronics and Locomotive Software like the first 3 CPCs. They didn't do anything for Amstrad on these later CPCs did they?

[TFM]

Well, yes!

The fun part of this story is the Joyce, because .... At the beginning of the developpment the joyce and the ANT shared the same motherboard. So even today the Joyce has features (GFX, videos stuff) which actually make no sense for this machine. It's the last remaints of the ANT. However the ANT was abandoned in an early stage.
A rumor once spread told that a single person has a single ANT motherboard in his attic in GB.

[McKlain]

@McKlain: Of Course :-)

I still wonder why they didn't went that way if  the commodore guys already did it in 1981 for a cheap ass price. ¿Backwards compatibility problems?

[TFM]

Either that or creed ;-)
Well, the CRTC can access the first 64 KB... so ... hmmmmm..... dunno.
What I do like about the Plus sprites is that they can have up to 15 colors in MODE 2 resolution. Which allows very detailed GFX in sprites.
On the other hand, using animation means to reload every phase into the sprite... or you use less hardsprites at the same time.
I calculated that with my Giana Game and saw that (aside of the better resolution) it will save about 50% of CPU time compared to software sprites. Here the c64 is definitely way more quick.

[McKlain]

When I first heard about how the asic sprites work, I was quite shocked.


If they had gone the other way, the sprites would be really useful and you could do all kind of crazy tricks with them. Just look at how they are still discovering new tricks on the VIC-II chip.


Megademo90 / Cosmos Designs [C64 Demo]


Krestage 3

[arnoldemu]

Some things can be done with the asic sprites such as reprogramming the x,y coordinate whenever you want, so you can stretch them and duplicate them. With some clever crtc setup this can be done with 0 processor time, because the coords are based off crtc values.

e.g. set R9 to 31, and the sprite lines will repeat.

The real problem is the sprite ram is on the asic as we all know.

BTW,

I will soon release a cpc+ library to be used with sdcc so people can code in c and use plus features.
I know that Arnaud did something similar, this will expand on that idea.

New games for plus coded in c? Why not

[SyX]

Just like the c64, doesn't it?

And Nes, SMS, GB, GBA, MD, SNES, MSX, Coleco, Atari 8 bits computers, Atari Lynx, Amiga, X68000, FM Towns, Texas Instrument  TI-99/4, every arcade machine using sprites, ... it's much more faster to say which systems have this kind of defective sprite system, the Atari 2600 (although in the way that you code for this machine, you learn to multiplex yes or yes) and the CPC+ 

And in that list there are systems from the 70s, 80s (the most part, including Amiga, were finished before 1985) or contemporary (as SNES).

Even lack of one feature guaranteed in a typical sprite system, being able to choose the priority between the sprites and the background, with that at least we can put the sprites under the background and have a nice parallax plane.

And we could argue about if the way the asic was embedded in the machine, it could not be more "native" (I/O ports expanding the Gate Array, instead of memory mapped registers).

We can love the machine, but the CPC+ sprite system was a failure, the CPC+ was a failure, not only by the obsolete hardware... but the obsolete hardware was a big part of it.

[arnoldemu]

And Nes, SMS, GB, GBA, MD, SNES, MSX, Coleco, Atari 8 bits computers, Atari Lynx, Amiga, X68000, FM Towns, Texas Instrument  TI-99/4, every arcade machine using sprites, ... it's much more faster to say which systems have this kind of defective sprite system, the Atari 2600 (although in the way that you code for this machine, you learn to multiplex yes or yes) and the CPC+ 

all of these were designed for games. cpc wasn't.

Although the cpc+ is a failure we can still love it

[SyX]

 

all of these were designed for games. cpc wasn't.

I have mixed consoles and computers in the list.

Sure the japanese computers always had more exciting hardware, all the sexy electronics companies were there (YM never had a rival for general sound chips and made very difficult for not japanese companies use its best chips), but the real reason was that they needed better graphic hardware for giving support to its language (better screen resolutions, use of tile modes for fast text printing, ...). And for that, in my book they are computers, not toys.

And it's well documented than Amiga was planned as a computer since the first day and Atari tried that the 8 bits family didn't collisioned with its consoles, because that, discouraged its staff of making games for them.

But other than that, we are talking about a machine sold in 1990, by then the vga cards were very common in pc compatibles, what less than having 32 sprites at 256 colours... and a little blitter or a tile mode or both for reduce the most well-known cpc disadvantage... and the unlock sequence should have unlocked extra registers/features in the PAL, GA, CRTC, PPI and AY.

And the most fun thing is when Sugar saved the british pride buying sinclair, they threw away the Loki project (Loki -> Konix Multisystem -> Atari Panther -> Atari Jaguar), a lot of that technology could have been used in the CPC family.

A successful machine for the 90s, it should have been a mini-amiga 500 or a C65 and having Klax... we only had Klax, and not very cpc+ish xDDD

Although the cpc+ is a failure we can still love it

Of course  

I like the palette, the raster interrupts and depend of the day, the scroll hardware... although i had loved the scroll steps were in mode 2 pixel size always

[TFM]

all of these were designed for games. cpc wasn't.

AMSOFT may not share your point of view 

[Sykobee (Briggsy)]

I think there wasn't enough memory bandwidth / timing slots for sprite data to be loaded from main memory in the CPC - at least not if you wanted 16+ 16-colour sprites.

If the ASIC had the pin-outs available for another memory bus + data bus, then sprite RAM could have been external rather than internal. I can imagine a 16KB RAM being used as sprite RAM.
That would have switched the cost from the internal SRAM to the external quantity of pins on the ASIC plus the RAM chip. Then we could have had addressed sprites to enable decent animation.


I don't see a need for 256 colour sprites, but I think having different 16-colour palettes for different sprites would have been very nice.


Maybe something for someone to experiment with for future FPGA CPC+ implementations.