| |
Krill
Registered: Apr 2002
Posts: 2969 |
Was the SID designed with replay of digitised samples via $d418 in mind?
Reading the comments to Flash for Fantasy with remarks such as
Quoting RudiI remember the first time i heard this. I was totally impressed by the fact that the C64 could play digitized samples. and
Quoting DivertigOI used to have dreams in the 80s that my computer could display or play things that were a technical impossibility. Hearing this for the first time felt surreal. i again wondered whether this was an actual "invention" or "discovery" at some time or known right from the start (at least by its creator).
Referring to the authorities:
Quoting Bob Yannes himselfThe final amp was a 4-bit multiplying D/A converter which allowed the volume of the output signal to be controlled. By stopping an Oscillator, it was possible to apply a DC voltage to this D/A. Audio could then be created by having the microprocessor write the Final Volume register in real-time. Game programs often used this method to synthesize speech or play "sampled" sounds. Quoting SID 6581 datasheetBits 0-3 (VOL0-VOL3) select 1 of 16 overall Volume levels for the final composite audio output. The output volume levels range from no output (0) to maximum volume (15 or #F) in 16 linear steps. This control can be used as a static volume control for balancing levels in multi-chip systems or for creating dynamic volume effects, such as Tremolo. Some Volume level other than zero must be selected in order for SID to produce any sound. Now, Mr Yannes makes it sound as if sample replay via $d418 was indeed a feature designed by him, but he remains inexplicit. The 6581 datasheet mentions no such thing, and with 8580, sample replay as used thus far broke due to "bug fixes" (was Bob Yannes still involved or did other engineers strictly adhere to some spec not mentioning sample replay?).
A related question is when the first program to play 4-bit samples surfaced, and who made it. |
|
... 10 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Quote: Oswald: Care to quote or recap? :)
well, there's the long story of why commodore drives are friggin slow, from the buggy chip, to the factory optimising the parallel lines away, and finishing at Tramiel himself telling the programmer the drive must be on his desk working by mondey (on friday or so).
or there's the VDC, with DMA with no designated function to trigger an irq when finished. yes the designer of the VDC thought the cpu has no other task than busy polling the VDC wether DMA finishd.
or the constant struggle with prototypes at CES, fex they had a handful of working c128, but none of them worked fully, so each displayed a demo whcih it could run flawlessly :)
Read that book its filled with stories like this, you will understand that the c64 and the amiga, or even commodore as a tech company was more of a lucky coincidence, then part of a master plan. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Sounds like business as usual in any given tech company to me. :D
And what does that have to do with living under a rock? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
indeed, i bet everyone working in IT could tell similar stories from projects happening around him..... all tech stuff is barely working =D |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Quote: Sounds like business as usual in any given tech company to me. :D
And what does that have to do with living under a rock? :)
the final product is more of luck and randomness, than careful planning, like "oh many games use the volume glitch, lets not optimise away that", and if you think a company working like this is pretty normal, then why are u suprised 0 fucks were given of old digi compatibity ? |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Because it appears that they weren't even aware of the - pretty significant - use of that glitch.
Usually it's the old road-paved-with-good-intentions thing where ultimately some things have to go while engineering is done either quick-n-dirty or by trial-n-error - but fixing a bug requires time and effort that would probably be better spent on new features and such if one is aware that the fix would break existing software.
But yeah ok, living under a rock indeed, it seems :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Another recent tidbit from Bil, was that they didn't think anybody would use Illegal Opcodes. Maybe 5 people. This was in response to somebody doing a test and getting a value of about 50%.. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Also I think the 8580 was "fixed" in that it actually followed Bob's Spec, were as the 6581 was just thrown together, and well stuff just happened. Bob even admitted that he put the filter equations into the simulator and the simulator said, that is not going to work or do something consistent. But they still made the chip with them... But compared to the sparkle bug what is dodgy audio filters ;)
I've read that the d418 digi happened because one of the internal traces was too close to another, which let it bleed through thanks to the crapness of NMOS. The 8580 the designer put in proper gaps and hence "broke" it. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting oziphantomI've read that the d418 digi happened because one of the internal traces was too close to another, which let it bleed through thanks to the crapness of NMOS. The 8580 the designer put in proper gaps and hence "broke" it. That pretty much settles it, and it also explains why $d418 samples are still audible on 8580, albeit mutedly. Do you have a source? |
| Previous - 1 | 2 - Next |
