On 6/28/2017 11:09 AM, smf wrote: > On 28/06/2017 15:40, firstname.lastname@example.org wrote: >> I don't stand firmly behind the version I mentioned. I wasn't there >> where and when it happened. I only repeat the most common rumour, >> source of which is supposed to be credible (as with all rumours :-) > > We may be arguing at odds. The 1540 prototype was created by someone > on the TOI group by hacking the IEEE connector off a 2031 and when > they plugged it into a vic 20 prototype, they found the bug. It's a > monster drive which looks nothing like the 1540 or the 2031LP, which > took another year or two to create. So that part of the hardware > wasn't finished. > > The VIC20 motherboard had to be revised as different VIA pins needed > hooking up to the IEC port. So that hardware wasn't finished either. > > I don't remember where I read it (maybe bagnalls book), but they > supposedly floated the idea of working round the 6522 bug (which goes > something like this): > > http://forum.6502.org/viewtopic.php?f=4&t=2175 > > They could also have had the 6522 in the vic 20 always generate the > clock and just have the drive signal when a byte was ready to be > transferred. The drive could have had expensive stuff in it to fix the > issue, because it was expensive anyway plus they had way more time to > ship it. > > The 6522 had been around since 1977, for nobody to know about the > issues seems unlikely. > > What seems to have happened is Jack shouted & so they picked the > option that they knew reliably how long it would take to change. It > could easily have been quicker to go with one of the other options, > but they didn't want to risk upsetting Jack. Because of the price of > SRAM, nobody expected users to be loading or saving much anyway so the > speed wasn't considered a major problem. Plus they would just sell > them a new computer the following year. > > > Message was sent through the cbm-hackers mailing list I think everyone around at the time has incomplete memories, but in the interest of filing in missing pieces, here is Jim Butterfield's perspective on the birth of the bus: http://www.retrocomputing.net/parts/commodore/vic20/docs/6522f.txt If I am to piece things together: * MOS/CSG knew about the bug, but the computing group did not (that does not surprise me at all, given Bil Herd's discussion on the VDC fiasco). * I think Jim had the wrong issue described in his detail, but the effect is the same. If the PHI2/CLK issue presented itself, bits would drop. * I think the design of the 1540 came later in the VIC-20 development cycle. At the time, a drive for a "toy" computer (sorry, just stating it like Jack would have) would have been the last thing on people's minds. Thus, I think the above skews the issue, as the VIC-20 motherboard could have been complete and in FCC testing before the drive issue was found. No other IEC peripheral would show the issue, as it only happens on inbound traffic * I agree with the above that there were HW ways to solve in the drive, but I agree none were passionately pursued, mainly due to Jack. Another article notes that Jack hit the roof when he found out the proce of Peddle's IEEE drive design. Jack probably agreed to the 1540 only because Marketing pushed him to allay fears, he wanted the machine to be seen as a full featured unit, and he knew he had a drive tech to cost reduce on the product. He no doubt made an edict to cut costs on the drive, or else! I thus concur the idea would have gotten little traction. And, I agree, there was no no problem to solve. Jack and other managers (and Michael T.) would have said: You geeks, why are you solving a non-problem? people will load at most 35kB of data, and it'll drop in at ~40uS/bit, or 400uS/byte, ~2bytes/mS, or 2000bytes/sec. or 17 seconds for a full file. Where exactly is the problem? Quit being such perfectionists and ship the darn thing! Chuck is still around, so perhaps someone can ask him for the uncomfortable truth about the drive... jim -- Jim Brain email@example.com www.jbrain.com Message was sent through the cbm-hackers mailing listReceived on 2017-06-28 19:00:02
Archive generated by hypermail 2.2.0.