CPCWiki forum

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? ;)

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

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.

Quote from: arnoldemu on 09:12, 26 September 12
...
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!

Quote from: TotO on 17:11, 26 September 12
... 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).

Quote from: TotO on 17:11, 26 September 12
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.

Quote from: arnoldemu on 17:51, 26 September 12
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...

Quote from: TotO on 17:59, 26 September 12
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.

Quote from: arnoldemu on 17:51, 26 September 12
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.

Quote from: TotO on 17:59, 26 September 12
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.

Quote from: TFM/FS on 20:39, 26 September 12
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?

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..

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  :laugh: :o :(

Quote from: TFM/FS on 19:35, 27 September 12
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  :laugh: :o :(

@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?

Quote from: TFM/FS on 19:35, 27 September 12The 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  :laugh: :o :(

Just like the c64, doesn't it?

@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.

Quote from: TFM/FS on 19:35, 27 September 12
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  :laugh: :o :(

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?

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.

Quote from: TFM/FS on 17:27, 28 September 12@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?

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.

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] (http://www.youtube.com/watch?v=-pXGoPQfpZ4#)

Krestage 3 (http://www.youtube.com/watch?v=zO5hx4uHSNY#)

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 ;)

Quote from: McKlain on 10:14, 28 September 12Just 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+  :P

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.

Quote from: SyX on 10:49, 29 September 12
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+  :P

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

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

 

Quote from: arnoldemu on 11:02, 29 September 12all 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

Quote from: arnoldemu on 11:02, 29 September 12Although 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 ;)

Quote from: arnoldemu on 11:02, 29 September 12
all of these were designed for games. cpc wasn't.

AMSOFT may not share your point of view  ;)

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.

Quote from: Briggsy on 14:05, 02 October 12I 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.

Absolutely, like most existing systems. 4bit colors + 4bit palettes as exemple.

Quote from: SyX on 12:35, 29 September 12


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.

All of these machines were bigger failures than the CPC+!!!

It's not about the failure, it's about a nice technology that amstrad got free and instead of using or studying it, they sent to the trash the first day without take a look.

I can imagine the situation:


-Mr. Sugar: Can we sell this?
-Staff member: Well, not yet.
-Mr. Sugar: Fuck it.

Quote from: SyX on 15:54, 02 October 12
It's not about the failure, it's about a nice technology that amstrad got free and instead of using or studying it, they sent to the trash the first day without take a look.

I have been looking around and it seems that the techology wasn't there when Amstrad took over. It was developed later by Flare. The Jaguar was released in desember 1993, 7 years and 9 months after amstrad bought Sinclair. Most people at Sinclair and Amstrad at the time considered the Loki to nothing more than a wishlist that would have needed years of development. Some of this seems to have been used for the Sam Coupes graphics, but I can't find much there that Amstrad couldn't have done on their own. What the CPC+ doesn't have has probably more to do with cost and compability issues than what was possible for Amstrad.

Ok...


=ASIC was screwed by the fact it included the ACID system management... This used some space inside it that could have been certainly used for more DMAs or Palettes or Sprites or clever RAM management or extra colours attributes or Whatever.

QuoteAnd 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.

was the "Loki" Z80 based ?


ok what Sinclair could actually offer...


=Zx speccy : was exploited by Amstrad as it used a lot of common component with CPC and PCW... (being a Z80...) Saddly the CPC wasn't upgraded into a full 128k range. >:(


=Sinclair QL : a 68008 based computer... Amstrad produced none of those. Also QL was screwed by hugeload of bad technological choices, such as freaking microdrive, the Video was even almost inferior to what a CPC could do. Too many new componnents to buy or too many research to make this QL like it should be...
And "Amstrad QL" would be actually some sort of Atari ST with 3" disk drives and only 128K RAM... :laugh:


=PC200 (or PC20 ?) : an "IBM PC" compatible machine in CGA put into an Atari ST casing. Was actually released and was utter failure. Could sort of have worked provided it included a custom video standard (like some CPC upgraded into EGA like power) and a little AY for sound too and even some MIDI port.
Hell even the PC1512 and PC1640 were somewhat better.






What I don't understand is that the Amstrad PLUS should have been somewhat compatible with PCW, CPC and Speccy alongside a super "PLUS" mode... to be perfect. With 2 ASICs and different cartridges OS it could really have been manageable. ::)

Quote from: MacDeath
=Sinclair QL : a 68008 based computer... Amstrad produced none of those. Also QL was screwed by hugeload of bad technological choices, such as freaking microdrive, the Video was even almost inferior to what a CPC could do. Too many new componnents to buy or too many research to make this QL like it should be...
And "Amstrad QL" would be actually some sort of Atari ST with 3" disk drives and only 128K RAM...  

It looked damn awesome though. I love mine (even though it had developed a problem with keyboard. I was too heart-broken to look into it :( )

Quote from: Gryzor on 09:02, 03 October 12
It looked damn awesome though. I love mine (even though it had developed a problem with keyboard. I was too heart-broken to look into it :( )

You got a new membrane for your QL Gryzor? I did and it works fine :)

Quote from: emuolaQuote from: Gryzor on Today at 11:02:27It looked damn awesome though. I love mine (even though it had developed a problem with keyboard. I was too heart-broken to look into it )
You got a new membrane for your QL Gryzor? I did and it works fine

To tell you the truth, no. As I said, I was really sad when it broke down and, combined with a lack of time I never looked into it. How much do they go for?

Quote from: Gryzor on 09:10, 03 October 12
To tell you the truth, no. As I said, I was really sad when it broke down and, combined with a lack of time I never looked into it. How much do they go for?

Seems to be £14 here:

New Sinclair QL Keyboard Membrane (http://www.sellmyretro.com/offer/details/New_Sinclair_QL_Keyboard_Membrane-2340)

Cheers, much appreciated. I wonder if it's the membrane indeed or something else, though it surely looks like it (IIRC the left half of the keyboard doesn't work). 

Quote from: Gryzor on 13:25, 03 October 12
Cheers, much appreciated. I wonder if it's the membrane indeed or something else, though it surely looks like it (IIRC the left half of the keyboard doesn't work).

You're welcome :) I'm 99% sure your problems with the QL keyboard are caused by the faulty membrane. If/when you decide to open the computer you'll be amazed how crappy the membrane actually has turned
into during the years. It's like papyrus ;D

perhaps you can refit a QL mother board inside a CPC6128 unit ?

Well, actually I had taken a look into the membrane, and it looked ok. I looked at it because the darn thing stopped working after I first opened it up. I'm not sure, but I seem to recall that opening it up puts a strain on the membrane/ribbon?

@MacDeath: why would you?

Quote from: Gryzor on 21:24, 03 October 12
Well, actually I had taken a look into the membrane, and it looked ok. I looked at it because the darn thing stopped working after I first opened it up. I'm not sure, but I seem to recall that opening it up puts a strain on the membrane/ribbon?

@MacDeath: why would you?

@ Gryzon: Yes, opening an old QL will mostcertainly break the ribbon(s) that lead from the actual membrane to the mb. I know, because that's what happened to me. The original membranes have become really fragile, but the ones I posted a link are manufactured recently=way more durable. The original design of how the membrane is fitted is really awful, because it puts a real strain on the membrane (the part that's hooked up tp mb gets bent pretty badly due to space restrictions inside the case).

I guess this is kinda off-topic, but anyway...

I've always been fascinated about the original PC-Engine/TG-16 design: It's as early as 1987, very compact and yet very powerful (if you ask me). Of course it does not have a floppy/keyboard/serial etc, but as pure cpu/graphics combo its pretty neat. I know the amount of RAM is pretty lame, but combined with HuCard as game media, it did not stop from creating some really impressive games. More tech savvy people here can give their insights on this machine, but I love it anyway :) Combined with Everdrive (sd-adapter) its a real 80's game dream machine.

Here's are the specs (from wikipedia):

 
  (http://bits.wikimedia.org/static-1.20wmf12/skins/common/images/magnify-clip.png) (http://bits.wikimedia.org/static-1.20wmf12/skins/common/images/magnify-clip.png) The American TurboGrafx-16 console with CD unit   

   
• CPU (http://en.wikipedia.org/wiki/Central_processing_unit): 8-bit HuC6280A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6280), a modified 65SC02 (http://en.wikipedia.org/wiki/65SC02) (a separate branch from the 65C02, of the original MOS 6502 (http://en.wikipedia.org/wiki/MOS_Technology_6502)) running at 1.79 or 7.16 MHz (switchable by software). Features integrated bankswitching hardware (driving a 21-bit external address bus from a 6502-compatible 16-bit address bus), an integrated general-purpose I/O port, a timer, block transfer instructions, and dedicated move instructions for communicating with the HuC6270A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6270) VDC.
• GPU (http://en.wikipedia.org/wiki/Graphics_processing_unit): A dual graphics processor setup. One 16-bit HuC6260 (http://en.wikipedia.org/w/index.php?title=Hudson_Soft_HuC6260&action=edit&redlink=1) Video Color Encoder (VCE), and one 16-bit HuC6270A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6270) Video Display Controller (VDC). The HuC6270A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6270) featured Port-based I/O similar to the TMS99xx VDP family.

Display  Resolution

   
• X (Horizontal) Resolution: variable, maximum of 565 (programmable to 282, 377 or 565 pixels, or as 5.37mhz, 7.16mhz, and 10.74mhz pixel dot clock)^[18] Taking into consideration overscan limitations of CRT televisions at the time, the horizontal resolutions were realistically limited to something a bit less than what the system was actually capable of. Consequently, most game developers limited their games to either 256, 336, or 512 pixels in display width for each of the three modes.^[19]
• Y (Vertical) Resolution: variable, maximum of 242 (programmable in increments of 1 scanline). It is possible to achieve an interlaced "mode" with a maximum vertical resolution of 484 scanlines by alternating between the two different vertical resolution modes used by the system. However, it is unknown, at this time, if this interlaced resolution is compliant with (and consequently displayed correctly on) NTSC televisions.
• The majority of TurboGrafx-16 games use 256×239,^[18] though some games, such as Sherlock Holmes Consulting Detective did use 512×224. Chris Covell's 'High-Resolution Slideshow' uses 512×240.

Color

   
• Depth: 9 bit
• Colors available: 512
• Colors onscreen: Maximum of 482 (241 background, 241 sprite)
• Palettes: Maximum of 32 (16 for background tiles, 16 for sprites)
• Colors per palette: 16 per background palette (color entry #0 of each background palette must be the same), and 15 per sprite palette (plus transparent, which is displayed as an actual color in the overscan area of the screen)

Sprites

   
• Simultaneously displayable: 64 on-screen, 16 (256 sprite pixels) per scanline
• Sizes: 16×16, 16×32, 16×64, 32×16, 32×32, 32×64
• Palette: Each sprite can use up to 15 unique colors (one color must be reserved as transparent) via one of the 16 available sprite palettes.
• Layers: The HuC6270A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6270) VDC was capable of displaying one sprite layer. Sprites could be placed either in front of or behind background tiles by manipulating a bit which caused indirect pixel color entry #0 of the background tile(s) to act as transparent.

Tiles

   
• Size: 8×8
• Palette: Each background tile can use up to 15 unique colors via one of the 16 available background palettes and 1 shared color (BG color #0) for a total of 16 colors per tile. The first color entry of each background subpalette is ignored. Instead, color #0's RGB value is shown in its place (the common/shared color). When a specific sprite is set to show behind the BG layer via the priority bit, all tiles that use relative color #0 (of 16) will not show BG color #0. But instead will show the sprite pixel (if not opaque).
• Layers: The HuC6270A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6270) VDC was capable of displaying one background layer.

Memory

   
• Work RAM: 8 kB (http://en.wikipedia.org/wiki/Kilobyte)
• Video RAM: 64 kB

Audio capacity

   
• 6 Mini-Wavetable stereo audio channels, programmable through the HuC6280A (http://en.wikipedia.org/wiki/Hudson_Soft_HuC6280) CPU.
• Each channel had a frequency (http://en.wikipedia.org/wiki/Frequency) of 3.58Mhz PCM sample clock (while not in D/A mode) with a bit depth (http://en.wikipedia.org/wiki/Audio_bit_depth) of 5 bits. Each channel also was allotted 20 bytes (32×5 bits) of RAM for sample data.
• The waveforms (http://en.wikipedia.org/wiki/Waveform) were programmable so the composers were not limited to the standard selection of waveforms (square, sine, sawtooth, triangle, etc.).
• The first two audio channels (1 and 2) were capable of LFO (http://en.wikipedia.org/wiki/Low_frequency_oscillation) when channel #2 was used to modulate channel #1. This was used to achieve FM (http://en.wikipedia.org/wiki/Frequency_modulation_synthesis)-like sound qualities.
• The final two audio channels (5 and 6) were capable of Noise (http://en.wikipedia.org/wiki/White_noise) generation.
• Optional software enabled Direct D/A (http://en.wikipedia.org/wiki/Digital-to-analog_converter) which allows for sampled sound to be streamed into any of the six PCM audio channels. When a channel is in D/A mode the frequency is as fast as the CPU can stream bytes to the port, though in practicality it's limited to 6.99 kHz when using the TIMER interrupt with the smallest loop setting (1023 cpu cycles). Additionally, a programmer could use the scanline interrupt to generate a 15.7khz interrupt system to play samples.
• Each channel has its own DAC and two layer attenuation device (two volume mechanism controls) allowing a combination of two channels in Direct D/A mode to be paired and play back 8-bit, 9-bit, or 10-bit linear PCM samples.
• Each channel has a 4bit left and 4bit right fine pan volume register for stereo volume control. The audio unit also contains a master 4bit/4bit pair fine pan volume control, used to set volume/stereo level for all channels as a whole.
• The addition of the CD-ROM peripheral adds CD-DA sound, and a single ADPCM channel to the existing sound capabilities of the TurboGrafx-16.

Sure, we can all check the wikipedia page. ;)

On a videogame system, you don't need so much RAM as all is running from the ROM, except for computing... It's why most 8/16bit video game system don't exceed the 64K 16bit memory adressing. (8/16K is already great)

Hudson made first this technology to improve it's own games on Famicom/NES system by adding chips inside the games cartridges.  (like Nintendo, Capcom and Konami does with poor add)
But Nintendo disagree because it was too much powerful and they plan to release the SNES later... So they found NEC to produce a stand alone system... Yes, the "Playstation" story was not the first Nintendo's fail...

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

They had been the slowest 8-bit computer ever.

Quote from: emuola@ Gryzon: Yes, opening an old QL will mostcertainly break the ribbon(s) that lead from the actual membrane to the mb. I know, because that's what happened to me. The original membranes have become really fragile, but the ones I posted a link are manufactured recently=way more durable. The original design of how the membrane is fitted is really awful, because it puts a real strain on the membrane (the part that's hooked up tp mb gets bent pretty badly due to space restrictions inside the case).

Thanks! Will be locating my QL in all the boxes and getting a new one... :)

QuoteI looked at it because the darn thing stopped working after I first opened it up.

Weren't all those Sinclair computer reputed for a massive lack of reliability and bad quality control ?


So it can fail in many parts.


PCengine :
Guys you're talking about an electronic masterpiece...
NEC was far better than Amstrad concerning design.


The CPU is largely "overclocked", the Video and sounds chips are also largely superior to most "8bit" things.
I even like to think PCengine could do a great computer if provided with 512K RAM and a sweet Disk Drive, HDD and CR-ROM and sweet OS.
SegaMD would also do a freaking great computer, with 512k of proper RAM, the CD option and so on.

QuoteOn a videogame system, you don't need so much RAM as all is running from the ROM, except for computing...

Well, the CD-ROms actually had to add a "huge" load of RAM to buffer from the CD.
So puting so few RAM on those systems was a setback in the long term.


But ok, most of those consoles had actual VRAM and quite very few "normal RAM".
still as Cartridges were expensive and limited technology, having more RAM to buffer, do some manipulations (swap/flip sprites or tiles, change a few colours) or manipulate numbers and values, decompress some datas or do 3D or whatever the computers could do more "easily".


Those console were quite handicaped concerning procedural graphics hence the too often classic "arcade 2D tiles and sprites engines".


SegaMAsterSystem also suffered a few from having too short RAM... and some kind of games weren't that often ported on Consoles unless you add extra chips on the Cartridge.

Also supergraphix was nice but actually too huge on graphics so the CPU could have a few problems...
(SuperNES was also too huge on graphics so it limited some games to 1player modes only).


At one point the GX4000 was flawed because it had no way to be upgraded with Tape/Disk and keyboard IMO...


But the 64K RAM was actually needed because it was also used as "VRAM" and a fullscreen/overscan in doublebuffering would actually need 64K.
On the other hand GX4000 (and CPC/PLUS) also suffered from having no proper VRAM at all.

Quote from: MacDeath on 21:22, 04 October 12
Guys you're talking about an electronic masterpiece... NEC was far better than Amstrad concerning design.

Like I said, it's not NEC but Hudson who designed all those evolutive PC-Engine master pieces.

Quote from: TotO on 08:22, 05 October 12
Like I said, it's not NEC but Hudson who designed all those evolutive PC-Engine master pieces.

Go Hudson, Go!  :D

Quote from: emuola on 10:15, 05 October 12Go Hudson, Go!  :D

May 18th, 1973 - March 1st, 2012.
R.I.P.

Quote from: TotO on 10:24, 05 October 12
May 18th, 1973 - March 1st, 2012.
R.I.P.

Da*n, forgot about that :( One of the last "old giants".

Quote from: emuola on 11:06, 05 October 12
Da*n, forgot about that :( One of the last "old giants".

The ones that survived had less talent in innovating than in stealing ideas and marketing... :(

QuoteThe ones that survived had less talent in innovating than in stealing ideas and marketing.

are you implying Apple was never cheap nor innovative ?
oh wait... ;D


But hey, still NEC provided the production, and boy they were good at that.


Remember the NEC PC6xx1 used to have speccy specs, then CPC specs, then... CPC with better resolution specs ? (sort of)