Well in terms of explaining how CSAVE and CLOAD work and what is really going on with all those sounds this was great. I'm always amazed by the depth of detail in your content and how much I learn. Wonder if the guy's working on NitrOS9 handle this stuff any better.
Glad it was helpful! I will make sure to ask Curtis Boyle this weekend on CocoTalk. What do you bet that they don't use the tapes anymore? They are quite sophisticated in Nitros9. Gotta learn more about it next year. For now though and probably always, I am getting a kick out of the retro sound and the nostalgia of those tapes.
Seriously, though this is 2 years later, it was a closet genius move to think that by quartering the resolution of the in-ROM table it would fix the issue. The obvious move would have been to make give it more range and you did the opposite. Truly Out of the Box thinking!
As someone who was frustrated countless times by unreliable files on tape, I love this! Great video, really well explained. Thanks for taking the time to share.
One more thing I learned after the video was that some recorders have two inputs, mic and aux, and the one that has more load to ground will work better with the Coco. The one turned out to be the *other* one.
David Ladd sent me... great video. It remed me of watching a PBS computer show back in the day. Very interesting. I saved a ton of tapes us the double speed POKE. I hope I can still read them when I try digitizing them.
@@acs8-bitzone651 I guess it was more the style of a technical presentation about how computers worked. Haven’t really seen anything like that on TV since the early 80s when they were trying to teach us that POKE couldn’t blow up a computer. Heh.
Hi @Allen Huffman , I found a letter to Rainbow magazine in the Sept 1983 issue talking about the PBS show "Computer Programme". Maybe it is what you remember. The letter said the show was originally produced in England and offered a wealth of information including some wonderfully clear explanations of BASIC programming as well as featuring some of the latest applications for the computer. It is a serialized show that 'builds' from week to week. It appears to be designed to increase the computer literacy of the general public." I'm sorry that I missed out on that series back in the day!
@@acs8-bitzone651 I definitely watched that. They’d show weird machines I had never heard of. Those old programs explaining stuff have disappeared. That’s the vibe I get from your videos.
Thanks for the feedback! Like I mentioned in another comment, it makes me wonder if earlier tapes would have shown the DAC was faster or somehow stronger driving many years ago. Or, were some models of either the Coco or the IC itself a different model of the part.
As far as I know the high speed poke was mainly done on the CoCo 3 which could yield a double data rate on the cassette. On the CoCo 1 and 2 doing the full double speed poke would turn off RAM refresh and cause possible RAM corruption. Though this is still a interesting topic to look at as to how far the cassette system could be pushed.
Yes, and it probably makes sense to get a sampling of some more DACs and slew rates and then see how the Coco 3 managed the signal rates for double speed.
@@acs8-bitzone651 , Well if you like I can do a audio capture using my sound card at 44100 rate and see what the waveforms look like or just send you the WAV file to look at. Sadly with me not having a oscilloscope I can only rely on what I can capture using sound cards.
@@acs8-bitzone651 , Also I have been doing some more tinkering with the cassette port and wanted to know if you have seen this? github.com/MyTDT-Mysoft/COCO-FastLoader
@@acs8-bitzone651 , Also I created a comparison video showing load times with the same binary on the same system via the cassette port. What do you think? ua-cam.com/video/ygX111dDvfg/v-deo.html
@@David_Ladd I watched that about the Fastloader. Neat! I can't tell how it works from the video. It seems there is some speed boost plus compression happening and the CoCo would need some ROM updates to do it.
The cassette ROM code and sine table were written for the original CoCo and remained unchanged in the CoCo 2 and 3. The CoCo 1 does not have a DAC chip. Instead it uses a hex buffer, resistor ladder and a few other parts. It would be interesting to see how different the performance characteristics are between the CoCo 2/3 DAC and the discrete implementation used in the CoCo 1.
That is a good point and it's been a few months ago but I remember looking at the Coco 1 circuit and even observing a stronger drive. Also, I've since discovered that cassette recorder input loading can vary and the inputs with heavier resistive loading help the DAC drive low faster. Thanks for the comment!
I notice that the cassette output runs through a buffer but the regular sound output goes through the analog switch. I wonder if that buffer may be leading to at least some of the slew. It would be interesting to see how the output wave form compares between the cassette output and regular audio output. I guess one could compare that by patching the tape output to select the regular sound output instead of tape output. Should be a single byte poke somewhere.
Yes, there's that difference in the paths. And there is also the different circuits from Coco1 to 2. COco 1 had the discrete components and the 2 pulled them into the DAC IC (for cost reduction?). There was another variable I ran across after recording this video. The CCR-82 manual recommended the AUX input instead of MIC for the input. But the other way around is better. The first had input loading of 1 Meg Ohm to ground and the other has 1k Ohm to ground. The lower value which provides more load on the DAC actually helps the DAC output pull the voltage down and improved those falling slew rates! I wish I knew it while recording the video, but anyone out there, try the other input on your CCR-82 if the recommended one gives you the problems I was having. It may very well fix the issue!
@@acs8-bitzone651 , I just tested the disk image with MAME and created a wav file that shows the difference between before and after running the csavemod.bas :)
Very interesting video and great explanation. Question, once hacked, what are the impacts to program tapes that have been recorded with the original ROM tables, will those still work?
i think the files have to be re-saved. the problem is that CSAVE is feeding a distorted waveform to the cassette. Decoding a distorted waveform is harder than a clean waveform.
Good question! They will still work! The hack only changed the CSAVE portion so if the audio was good enough to CLOAD, it will still be good enough. If the user's DAC was distorted like mine was, then a new CSAVE could potentially improve the save quality however. You can determine you are having the issue if a CLOAD is really sensitive and only seems to work on higher volume levels. If so, then the Coco that created the tape probably has the issue like mine with the weak or slow DAC. Here's another thought/question... would a Tandy/Radio Shack official program stored on cassette tape have a more professional recording quality than one saved with a Coco and be more forgiving to volume sensitivity?
@@supwicha1 Sure. There are devices called PROMs programable (one time) read only memories. They use a special device to program the chip. But then the chip plugs into the motherboard just like the previous ROM. There are also EPROMS. Erase-able programable read only memories. They use a ultra violet light source to erase the contents of the chip, ready to be programed again. There are also EEPROMS. Electronically erase-able programable read only memories. These devices are erased by sending special commands to the chip.
I just found this video and it's great! I had ccr82 also and I must ask a question....why did you just not use the "p" setting? I remember my I had an old Panasonic I used to use with my 2 and it was finicky. When I got my ccr82 I don't think I ever again had a failed load. I thought it was the greatest recorder ever .. I used it so much the lid broke. I really never knew this was a problem, but it sure is a great fix. Of course you fixed it too good so you can't justify that better tape recorder now!
I meant to reply earlier, the "P" setting for preset is supposed to always work. And it usually does with professionally recorded tapes from the software producers. I think my issues came from self-recorded tapes, and forgetting what the "P" setting was for. Thanks for the reminder!
I really enjoyed this video. It would have been nice to see the ZCD overlay before you made the table edit. It would be interesting to do a study of old tapes and measure the slew from a large sample of recorded audio. Do you think it would require an oscilloscope to do this, or could you get the data from regular 44kHz sampling?
Noted! There may be a chance in a future video to do some followup on that exact thing. It would be interesting to sample some of my other Cocos and see comparisons. Either outcome would be interesting. I will make sure to show more on the before and after at the ZCD output. Also, I will capture some eye diagrams and show how the "eye window" closes as the volume is lowered (or the CLOAD speed is doubled!). Thank you for the feedback!
I was thinking the same at the time of the video. Later, I started to consider the fact that the different tape players can have a different resistive load internal to them, and that changes the overall wave. So, I should probably temper my statement about how messed up it was.
That was a borrowed Tektronix but I've been using my Siglent SDS1104X-E for more than a year now. It is great for the 100 MHz range of scopes and much better than I expected. My concern was that being used to using professional scopes would leave me unable to enjoy a lower end scope at home. That was not the case!
I wonder how the Model-I and III saved and loaded tapes? I don't think it used a DAC. Think it just output pulses. It was notoriously unreliable - nightmares of *C showing up in the top-right indicating a checksum error. Actually of course you didn't hack the ROM (because you can't write to ROM), but a copy of it in RAM. I suppose you could copy the ROM onto a new one with the new values?
Well in terms of explaining how CSAVE and CLOAD work and what is really going on with all those sounds this was great. I'm always amazed by the depth of detail in your content and how much I learn. Wonder if the guy's working on NitrOS9 handle this stuff any better.
Glad it was helpful! I will make sure to ask Curtis Boyle this weekend on CocoTalk. What do you bet that they don't use the tapes anymore? They are quite sophisticated in Nitros9. Gotta learn more about it next year. For now though and probably always, I am getting a kick out of the retro sound and the nostalgia of those tapes.
Agreed. AC’s technical deep dives are always really well explained and very informative. Keep it up, AC!
Remarkable computing AC! I will be trying this out at some point. Love your Coco videos.
A big thanks for your comments!
Seriously, though this is 2 years later, it was a closet genius move to think that by quartering the resolution of the in-ROM table it would fix the issue. The obvious move would have been to make give it more range and you did the opposite.
Truly Out of the Box thinking!
thanks for the nice comments!
Fascinating explanation of the CoCo Cassette technology!! Loved it!
Many thanks!
As someone who was frustrated countless times by unreliable files on tape, I love this! Great video, really well explained. Thanks for taking the time to share.
One more thing I learned after the video was that some recorders have two inputs, mic and aux, and the one that has more load to ground will work better with the Coco. The one turned out to be the *other* one.
David Ladd sent me... great video. It remed me of watching a PBS computer show back in the day. Very interesting. I saved a ton of tapes us the double speed POKE. I hope I can still read them when I try digitizing them.
Hi Allen, thanks for joining the channel! Glad you enjoyed this. I didn't see anything like this on PBS in my days of watching, but thanks I think!
@@acs8-bitzone651 I guess it was more the style of a technical presentation about how computers worked. Haven’t really seen anything like that on TV since the early 80s when they were trying to teach us that POKE couldn’t blow up a computer. Heh.
Hi @Allen Huffman , I found a letter to Rainbow magazine in the Sept 1983 issue talking about the PBS show "Computer Programme". Maybe it is what you remember. The letter said the show was originally produced in England and offered a wealth of information including some wonderfully clear explanations of BASIC programming as well as featuring some of the latest applications for the computer. It is a serialized show that 'builds' from week to week. It appears to be designed to increase the computer literacy of the general public." I'm sorry that I missed out on that series back in the day!
@@acs8-bitzone651 I definitely watched that. They’d show weird machines I had never heard of. Those old programs explaining stuff have disappeared. That’s the vibe I get from your videos.
Brilliant!
Well done explanation. I like the slew rate explanation which makes a lot of sense if the DAC can not handle the change in voltage fast enough.
Thanks for the feedback! Like I mentioned in another comment, it makes me wonder if earlier tapes would have shown the DAC was faster or somehow stronger driving many years ago. Or, were some models of either the Coco or the IC itself a different model of the part.
As far as I know the high speed poke was mainly done on the CoCo 3 which could yield a double data rate on the cassette. On the CoCo 1 and 2 doing the full double speed poke would turn off RAM refresh and cause possible RAM corruption.
Though this is still a interesting topic to look at as to how far the cassette system could be pushed.
Yes, and it probably makes sense to get a sampling of some more DACs and slew rates and then see how the Coco 3 managed the signal rates for double speed.
@@acs8-bitzone651 ,
Well if you like I can do a audio capture using my sound card at 44100 rate and see what the waveforms look like or just send you the WAV file to look at.
Sadly with me not having a oscilloscope I can only rely on what I can capture using sound cards.
@@acs8-bitzone651 ,
Also I have been doing some more tinkering with the cassette port and wanted to know if you have seen this?
github.com/MyTDT-Mysoft/COCO-FastLoader
@@acs8-bitzone651 ,
Also I created a comparison video showing load times with the same binary on the same system via the cassette port.
What do you think?
ua-cam.com/video/ygX111dDvfg/v-deo.html
@@David_Ladd I watched that about the Fastloader. Neat! I can't tell how it works from the video. It seems there is some speed boost plus compression happening and the CoCo would need some ROM updates to do it.
thumbs up for the monitor stand!!!!
Hacked together and makes a big difference. Thanks!
The cassette ROM code and sine table were written for the original CoCo and remained unchanged in the CoCo 2 and 3. The CoCo 1 does not have a DAC chip. Instead it uses a hex buffer, resistor ladder and a few other parts. It would be interesting to see how different the performance characteristics are between the CoCo 2/3 DAC and the discrete implementation used in the CoCo 1.
That is a good point and it's been a few months ago but I remember looking at the Coco 1 circuit and even observing a stronger drive. Also, I've since discovered that cassette recorder input loading can vary and the inputs with heavier resistive loading help the DAC drive low faster. Thanks for the comment!
I notice that the cassette output runs through a buffer but the regular sound output goes through the analog switch. I wonder if that buffer may be leading to at least some of the slew. It would be interesting to see how the output wave form compares between the cassette output and regular audio output. I guess one could compare that by patching the tape output to select the regular sound output instead of tape output. Should be a single byte poke somewhere.
Yes, there's that difference in the paths. And there is also the different circuits from Coco1 to 2. COco 1 had the discrete components and the 2 pulled them into the DAC IC (for cost reduction?). There was another variable I ran across after recording this video. The CCR-82 manual recommended the AUX input instead of MIC for the input. But the other way around is better. The first had input loading of 1 Meg Ohm to ground and the other has 1k Ohm to ground. The lower value which provides more load on the DAC actually helps the DAC output pull the voltage down and improved those falling slew rates! I wish I knew it while recording the video, but anyone out there, try the other input on your CCR-82 if the recommended one gives you the problems I was having. It may very well fix the issue!
Great video sir :)
I can't wait to tinker with this myself :)
Hi David, please try the link I've added at the end of the description. Would you be so kind as to let me know if you are able to access the dsk file?
@@acs8-bitzone651 , ah cool
I didn't see that last night when I looked. lol
@@acs8-bitzone651 ,
I just tested the disk image with MAME and created a wav file that shows the difference between before and after running the csavemod.bas :)
Very interesting video and great explanation. Question, once hacked, what are the impacts to program tapes that have been recorded with the original ROM tables, will those still work?
i think the files have to be re-saved. the problem is that CSAVE is feeding a distorted waveform to the cassette. Decoding a distorted waveform is harder than a clean waveform.
Good question! They will still work! The hack only changed the CSAVE portion so if the audio was good enough to CLOAD, it will still be good enough. If the user's DAC was distorted like mine was, then a new CSAVE could potentially improve the save quality however. You can determine you are having the issue if a CLOAD is really sensitive and only seems to work on higher volume levels. If so, then the Coco that created the tape probably has the issue like mine with the weak or slow DAC. Here's another thought/question... would a Tandy/Radio Shack official program stored on cassette tape have a more professional recording quality than one saved with a Coco and be more forgiving to volume sensitivity?
I agree, if others are seeing this issue (and don't know why it would be isolated to me) they could get a cleaner waveform, like you said.
Is there a way to make the ROM permanent?
@@supwicha1 Sure. There are devices called PROMs programable (one time) read only memories. They use a special device to program the chip. But then the chip plugs into the motherboard just like the previous ROM. There are also EPROMS. Erase-able programable read only memories. They use a ultra violet light source to erase the contents of the chip, ready to be programed again. There are also EEPROMS. Electronically erase-able programable read only memories. These devices are erased by sending special commands to the chip.
Great Video !!
Thanks! Glad you enjoyed it. Nice UA-cam icon, btw. XOR gate!
I just found this video and it's great! I had ccr82 also and I must ask a question....why did you just not use the "p" setting? I remember my I had an old Panasonic I used to use with my 2 and it was finicky. When I got my ccr82 I don't think I ever again had a failed load. I thought it was the greatest recorder ever .. I used it so much the lid broke.
I really never knew this was a problem, but it sure is a great fix. Of course you fixed it too good so you can't justify that better tape recorder now!
I meant to reply earlier, the "P" setting for preset is supposed to always work. And it usually does with professionally recorded tapes from the software producers. I think my issues came from self-recorded tapes, and forgetting what the "P" setting was for. Thanks for the reminder!
I really enjoyed this video. It would have been nice to see the ZCD overlay before you made the table edit.
It would be interesting to do a study of old tapes and measure the slew from a large sample of recorded audio. Do you think it would require an oscilloscope to do this, or could you get the data from regular 44kHz sampling?
Noted! There may be a chance in a future video to do some followup on that exact thing. It would be interesting to sample some of my other Cocos and see comparisons. Either outcome would be interesting. I will make sure to show more on the before and after at the ZCD output. Also, I will capture some eye diagrams and show how the "eye window" closes as the volume is lowered (or the CLOAD speed is doubled!). Thank you for the feedback!
Great video here!
thanks!
it seems to me, nobody bothered to look at a scope while doing the tape code, in the first place.
I was thinking the same at the time of the video. Later, I started to consider the fact that the different tape players can have a different resistive load internal to them, and that changes the overall wave. So, I should probably temper my statement about how messed up it was.
Sorry to be off the topic, but what oscilloscope are you using?
That was a borrowed Tektronix but I've been using my Siglent SDS1104X-E for more than a year now. It is great for the 100 MHz range of scopes and much better than I expected. My concern was that being used to using professional scopes would leave me unable to enjoy a lower end scope at home. That was not the case!
I wonder how the Model-I and III saved and loaded tapes? I don't think it used a DAC. Think it just output pulses. It was notoriously unreliable - nightmares of *C showing up in the top-right indicating a checksum error. Actually of course you didn't hack the ROM (because you can't write to ROM), but a copy of it in RAM. I suppose you could copy the ROM onto a new one with the new values?
How would you use this mod with a ROM PAK like Color File or Personal Finance?