8bit-times Ep.24: The VIA Shift Register Bug

Подписаться 998

Просмотров 17 тыс.

50% 1

Update: I have done a followup with the response from WDC about this situation, and other interesting use cases for the VIA! • 8bit-times Ep. 25: VIA...
---
In this video we take a technical deep dive into the VIA 6522 Shift Register Bug - the cause why the Commodore (serial) disk drives like the 1541 were so slow.
We look at the bug, the conditions it happens, and test it out with various types of VIAs we have available. We also look at how to prevent it.
We reached out to Western Design Center about the bug, to see what they have to say to it. Unfortunately they said they need more time, so I'll keep you updated here when we get it.
Note that I cooperated with Dave McMurtie from the @Commodore International channel, who at the same time publishes a video on the historical aspects of the topic why Commodore disk drives are so slow. I recommend you watch it:
Dave's companion video: • Why Was the Commodore ...
Dave's channel: @commodorehistory
PS: Martin Thierer pointed me to a test he did where he generated synthetic control signals for a 6522 using an STM32F4, and could reproduce the bug. It consistently happens when the positive CB2 edge happens 90-40ns (in his tests) before the negative edge of Phi2. Here's the (German) writeup: www.forum64.de/index.php?thre...
PPS: yes, the Apple // did NOT have a VIA ...
Sections:
00:25 Introduction
01:40 Commodore IEEE vs serial bus
02:00 Shift register use in the Commodore serial bus
02:54 The Shift register bug
03:43 PET Shift register sound demo
04:18 Shift register serial communication and how the bug affects it
06:50 The Commodore "Fix"
07:11 Testing the bug
07:58 Test program and errors detected
08:49 My test setup
09:47 VIA variants tested and how to run the tests
10:33 Test variations
11:42 How to fix the shift register bug
12:55 Dave's tests on the VIC-20
16:19 Test results
21:06 Verifying the schematics
22:34 Test results summary
23:00 Consequences
25:50 Epilogue - two days later
Links:
Synertek SY6522 datasheet with shift register warning:
web.archive.org/web/202207081...
W65C22 datasheet at the WDC website
www.westerndesigncenter.com/w...
The test programs we used:
github.com/fachat/via-sr-bugtest
Reversed engineered VIA internal schematics:
forum.6502.org/viewtopic.php?f...
VIA shift register bug Fix:
forum.6502.org/viewtopic.php?p...
VIA differences and Fixed VIAs:
archive.6502.org/datasheets/ro...
CIA 6526 datasheet:
web.archive.org/web/201811260...
Western Design Center
www.westerndesigncenter.com/
PET sound demos:
shiru8bit.bandcamp.com/album/...
retrocomputingforum.com/t/bac...
• No Pets Allowed (Speak... (Sound first with Shift register, then with SID)

Наука

Опубликовано:

23 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 110

@networkg 9 дней назад

7 subs more to 1000 . I'm all in. Quality content.

@8bittimes 8 дней назад

Only six more to go!

@Mr_ToR 6 месяцев назад

Actually your video was recomended to me before Dave McMurtie's. RU-vid apparently knows how much I like your videos. Eventhough his videos are best in his class, a video from you is a bigger event than his imho.

@commodorehistory 6 месяцев назад

^ I agree :)

@Mr_ToR 6 месяцев назад

@@commodorehistory 😂👍

@commodorehistory 6 месяцев назад

@@Mr_ToR I've been following André's website since the 90s. Being able to meet him and work with him on this was a tremendous honor for me.

@semuhphor 6 месяцев назад

I'm not a commodore user, but I enjoyed the video. Thank you for the info!

@AnnatarTheMaia 6 месяцев назад

Love the technicalities, by the by.

@winstonstrongarm8929 6 месяцев назад

It's 5am but I can't stop watching, subbed

@MotownBatman 6 месяцев назад

New Sub! Detroit, Michigan, US Never got to enjoy a c64 back in the day, but I'm a nerd none the less and really enjoyed the video. Well Done!

@MatthiasWelwarsky 5 месяцев назад

I had a smirk on my face watching this video. I have been bitten by a similar bug on a much more modern chip from TI, an OMAP5910. There was a lock-up in the DMA controller when the clock of the external memory bus was not synchronized with one of the internal clocks that drove the DMA controller. The fix was the same, using a D-FF to sync the external bus clock with the internal clock, which very fortunately could be routed out to an external pin.

@brocktechnology 6 месяцев назад

Seems obvious there isn't going to be bug fixes in a 50 year old legacy part, It has to be the same as the original to be marketable. Also this bug was fixed in this parts successor and it's the flawed original that continues to find a market. I do agree however that it is inexcusable that the bug and it's workarounds are still not documented in the data sheet.

@Mr_ToR 6 месяцев назад

Great video. Thnx.

@GeorgeFoot 6 месяцев назад

Thanks for publishing this Andre, interesting tests. I think PHI2-driven shifting is about two times too fast for the receiving end to cope with - the datasheet says the external clock needs its high and low periods to both be at least two local clock cycles long. It will also not be helped by the D flipflop skewing things out of phase a bit more. Did you try having the receiver generate the clock, rather than the sender? That could also be interesting.

@8bittimes 6 месяцев назад

Indeed. It may be useful for other purposes, but not for receiving with another VIA.

@hansvanderlinden6545 6 месяцев назад

Hey , just gave a reaction based on my experience. PHI2 driven is way to fast for e.g. an Arduino. The focus on this topic is the comms with the shift register using external clocking. And I will go further on this way of having the Arduino clocking comms in both directions. Next step: a single flip flop device to have a work around (in SOT-353-5 package, the 74AHC 1G79GW. I expect to be able to give an update in a month.

@bwack 6 месяцев назад

I loved it ! Thanks! I've heard about the bug before, but never knew what the bug was. Still don't really know what, but it certainly doesn't resync the incomming signals with the receivers clock. I wonder, if you'd look at the die shots of a recent 6522 and one from back in the day, would this shift register be a photo copy ?

@8bittimes 6 месяцев назад

As far as I know only old versions have been re-engineered using die shots, e.g. here forum.6502.org/viewtopic.php?f=4&t=6573&start=0

6 месяцев назад

Very interesting study, I love the details and extensive testing! I would be very happy to hear WDC's answer. I've heard about the VIA SR bug, but I always wondered: OK, no time at the release of VIC20/1540, so the bug made Commodore to do a software solution instead. But at the time of the C64/1541, at the C64 side, there was the CIA (no bug) and the 1541 side, though it used VIA still, at least they could implement a "hw workaround". Or they could opt out for using CIA in 1541 as well (probably they wanted compatibility between 1541 and 1540 though, that the same IC is used). Also somehow I am sad, that no new CIAs are produced, only VIAs. C64 and Amiga guys would be very happy to have new CIAs (though the CIA variant used in Amigas - AFAIK - uses binary coding for the TOD unlike the BCD on 6526).

@8bittimes 6 месяцев назад

Watch the video by Dave McMurtrie that I linked in the description. He explains why the C64 doesn't have fast IEC. Because it was actually planned

@bcstechnologylimited896 5 месяцев назад

The CIA did have bugs. If the interrupt status was read one or two Ø2 cycles before timer B was due to interrupt, the IRQ would never occur. The TOD alarm would likewise fail to interrupt if the alarm time tenths-of-seconds was zero.

@8bittimes 3 месяца назад

Oh, btw did you see my followup? We got an answer from WDC: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-nvnz_34uWSg.html

3 месяца назад

@@8bittimesYes, of course I've seen it :) Very interesting, I was surprised that it's actually not so much a bug, I mean it was not a design choice to behave as many would expect without sync'ed clocks. Thanks for the interesting videos!

@cmjones01 6 месяцев назад

Thank you for the very detailed testing and analysis. It looks to me like this isn't a bug - it's a perfectly normal synchronisation problem. Every synchronous digital system has this problem when dealing with signals generated from an asynchronous clock source. It's not a bug that can be fixed, it's just statistics. The correct way to deal with it is to add the D-type latch on the input clocked by the receiver's system clock - better, actually, to have two latches, one after the other, known as a two-stage synchroniser. This is how it's done even inside FPGAs when passing signals from one clock domain to another. If you don't do it, you get a lot of indeterminate results and errors. This is expected. The newest version of the 6522 also has this problem because the only way to fix it is to add the synchroniser, which adds at least one clock cycle of delay and so compromises the behaviour of the shift register in ways which would be incompatible with some applications for it. So it remains a synchronous device, and will always need an external synchroniser if it's fed from a different clock domain. Neither WDC nor anyone else can change that. The 1541 problem is really down to Commodore not realising that they'd have this issue at the design stage - the 6522 is a synchronous design, so care is needed when introducing another clock domain.

@8bittimes 6 месяцев назад

The problem is, if the synchronization is not built in, they should have said so in the datasheet. As the datasheet reads, it actually says there is a synchronization in (... sampled on next phi2 edge after shift clock ...). So, I'd still consider this a bug because it does not work as the datasheet says. The 1541 design relied on what the datasheet said. The chip designers actually knew at that time, but the two didn't talk.

@cmjones01 6 месяцев назад

@@8bittimes it's a long time since I've read the 6522 data sheet, so thank you for the update. That description sounds like there's at most one stage of synchronisation in there, and the results you measured are consistent with what I'd expect from a single stage. Not a disaster, but far from perfect. That would also explain why a single external stage of synchronisation fixes the problem. Two stages is generally enough. I do agree that the data sheet ought to point out that extra care will be needed if the clock source isn't synchronous with phi2, since this seems like a pretty obvious use case for the shift register!

@ArneChristianRosenfeldt 6 месяцев назад

The video and comments are so long. I don't get why a receiver VIA even listens to the clock of the receiving system. The sender dictates the clock. Is the problem that the receiving VIA needs to notify the system that it now has all the data in its register? Why was there no genlock for the drive? The same drive should work with PAL and NTSC? And then Commodore repeats the same mistake in the C128 with the video.

@8bittimes 6 месяцев назад

Both sender and receiver can be completely unrelated systems. It can be two different computers. It can be two devices without screen. And any drive should of course be usable with systems using PAL and NTSC. So, synchronizing system clocks would not work in all scenarios. Therefore the sender sends a generic clock on the bus as well. The receiver VIA listens to the clock on the bus. But the VIA itself is of course synchronized with its receiver system clock, and needs to count each clock pulse to shift in each data bit. Maybe compare the receiving VIA with the host for a PS/2 keyboard. The VIA would have the same problem with loosing shift clock pulses receiving a byte from a PS/2 keyboard. Why/How should the keyboard have a genlock with the PC?

@melkiorwiseman5234 6 месяцев назад

I'd call it a bug because the receiving circuit of each VIA should have been set up to clock each bit in on the edge of the received clock signal while ignoring its own clock signal. Instead, the VIA seems to be paying attention to its own clock signal instead, which is definitely a bug. It sounds like that part of the design for the chip was slapped together by someone who literally didn't know what they were doing or understand what the system requirements really were.

@davethedaemon9024 6 месяцев назад

Thank you very much for this. I'm building a 65C816 computer and have the newer 65C22's and maybe one or two older ones. FYI - All my 65C51's have a hardware transmit interrupt bug. Transmit interrupts are broken and it drove me crazy debugging my code when the bug was really in the chip! The older 6551's don't have this problem, but are slower parts. Maybe the subject of a new video?

@8bittimes 6 месяцев назад

Frankly, I have long discarded the 6551 as option for asynchronous communication. It has no buffer, and the setting of the handshake lines influence the shift register in unfortunate ways (so that I typically even used other I/O for e.g. RTS/CTS/DTR/DSR...). My main chip to go currently is the 16550. It's got a 16 byte receive buffer (and send too IIRC), so it is much more manageable in a high load environment where not every interrupt can be served quickly and NMIs cannot be used due to other timing constraints.

@8bittimes 6 месяцев назад

And WDC's unfortunate bug does not make it better...

@davethedaemon9024 6 месяцев назад

@@8bittimes - Thanks! It sounds familiar. I think I have a 16550 someplace that I bought from Jameco and promptly forgot about it. Thanks for pointing this out!

@8bittimes 6 месяцев назад

You have to watch out for the Intel-style bus interface instead of the 65xx/68xx one. It's ... kinda strange. See an example integration here www.6502.org/users/andre/csa/duart/index.html

@davethedaemon9024 6 месяцев назад

@AndreFachat - Schematics complete with code. Thanks! My latest 65C816 design will use an ATF1508 for address decoding. It should be easy to separate out the RD/WR lines for Intel based devices. I already did it with an ATF22v10 and a PCF8584P I2C controller. It worked perfectly on a solderless breadboard with a 7Mhz CPU clock and 3 wait states (via clock stretching handled by another ATF22v10). I have a couple of WDC65C816SXB boards. I had replaced the _very_ slow CM078B/CD4078B with an ATF22v10 and got it to work nicely. Then I zapped one with a nice static shock. ("It's dead Jim") I guess I'll do it again and replace some other chips with faster parts this time. I think it's easier to mod this board than to start from scratch. (But I have a feeling you're going to clue me in on a better one.) The Windows compiler/debugger app for it is serviceable and works well enough. And I found the TL16C550 in a box of goodies.

@hugovangalen 5 месяцев назад

Very interesting! I wonder if the problem goes away if the two device would have a single oscillator source and whether that is at all feasible?

@8bittimes 5 месяцев назад

Indeed, if both sides have the same clock domain (derive from the same clock source), and make sure the the rising edge of CB1 stays out of the critical area of Phi2 (which should be easily doable within the same clock domain), the VIA shift register works just fine. For example it works in the "Steckschwein" homebrew computer this way www.steckschwein.de/hardware/

@akkudakkupl 3 месяца назад

They could have added D latches driven by the system clock to sample incoming data and clock. This would have fixed the clock boundary crossing problem. So probably what they needed was just 74LS74 and something like 74LS125 to control data direction in both the computer and the drive to make it work. Would drive up the cost a bit, but would fix the thing.

@8bittimes 3 месяца назад

That is about the fix that can now be used externally. I guess inside the chip they can optimize it better and just insert that register into an existing datapath. You can see if you find the right place in the chip dissection here forum.6502.org/viewtopic.php?f=4&t=7241 ;-)

@akkudakkupl 3 месяца назад

@@8bittimes It's just sad they didn't realize this for some reason when designing the VIC-20 (and that someone botched the C-64 PCB layout when it was designed).

@williamsquires3070 6 месяцев назад

Uh, no. The Apple ][ did not have a 6522 VIA chip, and neither did the Disk ][ floppy drive, nor the controller card, though some peripheral cards may have. And I’m pretty sure the Commodore PET motherboard didn’t either. Like the Apple ][, it was mostly all TTL glue logic, the NMOS 6502, and ROMs, plus a few support chips and discrete transistors in the cassette I/O and video circuits.

@8bittimes 6 месяцев назад

I remember checking the Apple about the VIA - but indeed I may have misinterpreted or misread something here. I stand corrected, the Apple II did not have a VIA. The PET, on the other hand, has had a VIA and two PIA from the very beginning. Only the video circuit was TTL in the first versions, and it later switched to a 6545.

@cmjones01 6 месяцев назад

The BBC Micro and its close relatives, on the other hand, have two 6522 VIAs which get used for all sorts of things. But not for the disc drives. They get a proper floppy controller chip!

@ethandicks3 3 месяца назад

Apple "Workstation Card" and the Mouse card had at least one 6522. LEGO card to talk to Dacta Interface A also had a 6522 (and reproduced most of the BBC Micro's 20-pin I/O port which the Interface A originally connected to) Apple did eventually embrace the 6522 but not until the IIe era.

@Randrew 6 месяцев назад

Has no one implemented a 6522 pin compatible replacement based on a modern microcontroller? Seems like a light-weight STM32 processor or similar on a 40-pin PCB could keep up with emulating all the VIA functions, including the shift register. I'd either use SPI pins or generic IO pins on interrupts.

@8bittimes 6 месяцев назад

I know there is such a replacement for the CIA 6526 of the C64. But as the VIA 6522 is still available - albeit with the bug - noone seems to have been motivated enough. There seem to be FPGA implementations out there for computer-on-a-chip systems, but I do not know any of their accuracy

@hansvanderlinden6545 6 месяцев назад

Hello folks, thanks for this video. I can't get enough of 6522 videos. But I must say I'm a bit confused. I always thought the bug for serial comms was only for the mode with external clocked communication. I'm building a DIY-project (using a wdc 65c22 1Mhz) in combination with an Arduino Uno acting as a terminal. I have a first build with a shift register (75hct595) sending (serial) to the Arduino, and a serial comms from the Arduino to CB1 and CB2 of the VIA. Without a patch data gets out-of-phase. When I use the clock of the 65c22 it seems to work alright, though I don't use bulk transfers like you did. My next build will be using a single flip flop (3mm x 4mm SMD) , and I hope this allows me to use the clock of the Arduino. This concept should make the 6502-board cooperate with the Arduino independent of the cpu/6522 clocking speed. Keep you posted.

@8bittimes 6 месяцев назад

Not sure I understand your problem. The VIA 'SR bug' happens when using external clock indeed, no matter if shifting in or out. So, your schematic seems to be vulnerable if I get it right that the Arduino sends the clock. I have a couple of projects where I use the VIA SR to implement an SPI host. The VIA shifts out via SR, and a 74xx shift register ('166 IIRC) shifts in and presents the received byte on a VIA port. No fix needed, minimum circuitry and totally stable. I do USB over SPI on the PET userport with this for example. www.6502.org/users/andre/cbmhw/cbmusb/index.html

@hansvanderlinden6545 6 месяцев назад

@@8bittimes My bad, the spreadsheet is hard to read on a phone. I thought your conclusion was that the fix was not always the right solution. I mounted a shift register for output on PA while CB1 and CB2 handle the input with some handshake. Talking of which, I have a question. Is there any risk for shorting CB1/CB2 when using them bi-directional? With this in mind I skipped to my two-port solution. Thanks. And will most certainly look at you SPI solution.

@8bittimes 6 месяцев назад

@@hansvanderlinden6545 Regarding the shorting - you have to make sure the you switch one side to input _before_ you switch the other side to output. This must be ensured by other handshaking. Otherwise the pins may draw overcurrent. Look at the datasheet on how these situations are handled for your particular parts.

@pepstein 6 месяцев назад

It's been a long time, but I seem to recall Commodore PETs run with a 1.00 MHz clock whereas NTSC Commodore VIC 20 and 64's run with a 1.02 MHz clock. Over a 256 byte page of data being transmitted in either direction, that's a significant amount of clock drift for VIA shift register based synchronous communication, is it not?

@8bittimes 6 месяцев назад

Yes. And my Micro-PET is even different, although in the same ballpark if set to run at 12.5MHz/12... However, the IEC is a synchronous bus, so the receiver waits for the clock line anyway per bit. It only needs to be fast enough to cope with the sender's bit rate. Clock drift would be important for asynchronous communication where there isn't a clock line

@pepstein 6 месяцев назад

@@8bittimes hmm. I’m still not getting it. Wouldn’t the slower 1541 clock mean it would slowly get behind the faster C64 when loading? Or is the data rate independent from the CPU clocks?

@8bittimes 6 месяцев назад

Both sides are synchronized at every(!) bit using the clock line. I recommend you look at this excellent description of the IEC serial bus here www.pagetable.com/?p=1135 by @mist64

@pepstein 6 месяцев назад

@@8bittimes thank you. Great article! I see each bit was going to take 8 microseconds to transmit, regardless of the CPU clock. So (a) it’s independent from the CPU clock and (b) it’s much slower than either CPU clock. I had assumed they were trying to send one bit per CPU clock, which is why I was so confused. My brother and I wrote our own fastload and fastsave routines back in the day. We sent two bits at a time, repurposing the clock line for the second data bit. So we had to account for clock drift due to the different CPU clock frequencies. A nice challenge for a couple of high school kids!

@8bittimes 6 месяцев назад

Writing a fastloader and making sure it works under many different circumstances is no easy feat. Cool!

@jammi__ 5 месяцев назад

The Apple Macintosh does have a VIA though.

@deralte650 6 месяцев назад

My 1985 Synertec Data book doesn't contain anything on a Shift Register Bug in 6522 / 6522A. :-O Ciao, Bernd

@8bittimes 6 месяцев назад

This datasheet from 1982 contains section 5.1 "shift register warnings": web.archive.org/web/20220708103848if_/archive.6502.org/datasheets/synertek_sy6522.pdf that describe the bug. Maybe they have fixed it in their later versions?

@rootbeer666 6 месяцев назад

I wish you had shown *your* final schematic of the fix as *you* have it implemented.

@8bittimes 6 месяцев назад

This will be part of a followup video

@davidwillmore 6 месяцев назад

I didn't see any serial termination resistors in your design. Are you driving those wires directly? That is going to cause issues especially with the faster chips.

@8bittimes 6 месяцев назад

In these tests I indeed didn't do termination. Basically it's only a few cm. Scope showed signals "behaving" ok. Also as shown, I did some tests with caps to verify if anything is needed, but we still get the error. In the last section you can see my IEC interface setup. This basically uses Schmitt-Trigger receivers and Open-Collector drivers (with pull ups on the line). Basically the same circuit Commodore itself uses. I get similar errors without the clock fix.

@geoffstrickler 6 месяцев назад

The Apple // did not include a 6522. The 6522 was used on some expansion cards from third parties.

@8bittimes 6 месяцев назад

Yes that has been pointed out. I still need to update the description

@geoffstrickler 6 месяцев назад

@@8bittimes I glanced through the comments before writing and didn’t see it or I would have just liked the other comment instead of posting it newly. Anyway, good video.

@AndreFachat2 6 месяцев назад

No worries, all good!

@AnnatarTheMaia 6 месяцев назад

That would make me angry, not sad.

@8bittimes 6 месяцев назад

Yes at least they could have documented it. But there is still the small chance our tests have some issues.

@MangoJones139 6 месяцев назад

Ben Eater ran into the same issue with his 6502 based breadboard computer a couple of month ago in one of his videos. I think he mentioned that WDC released an updated ref sheet that at least now inderectly hints at the bug in a footnote. I wonder why they never bothered to fix that bug. I'd assume it wouldn't break compatibilty if old software implements a workaround anyway. But on the other hand, if no one uses the shift register because of backward compatibilty with old hardware, there is probably no actual reason to fix it. Still hope you get a reply

@8bittimes 6 месяцев назад

Can you point me to the video from Ben? I can only find a video on a bug in the 6551, which is used for asynchronous communications like RS232 - but not the VIA

@MangoJones139 6 месяцев назад

@@8bittimes Ah, sorry. My bad. That was the video I meant. I somehow assumed they were the same chips. I should have checked that before posting.

@8bittimes 6 месяцев назад

@@MangoJones139 no worries 👍

@mibnsharpals 6 месяцев назад

The problem will probably be that there is simply no reason to fix it anymore. Almost all applications were solved around the error (more or less badly). Are there perhaps even solutions that build on the error and no longer work if it is eliminated? Lastly, there is simply no economic reason anymore.

@8bittimes 6 месяцев назад

I think that, unfortunately, you are right. But at least they can document it in their datasheet.

@mikehughesdesigns 6 месяцев назад

So why didn't WDC fix the bug before making new chips? Did they just reuse the old masks to save money?

@8bittimes 6 месяцев назад

That is a good question that you should ask WDC.

@jjeeeekk 6 месяцев назад

What a pitty that WDC is not reproducing the 6526 ... did everything from MOS get lost?

@8bittimes 6 месяцев назад

@@jjeeeekk There seems to be an FPGA replicas for various chips. The directly from MOS ... indeed seems to have gone lost, I'm afraid

@herrbonk3635 5 месяцев назад

Never understood why they didn't simply use a standard TTL shiftregister instead of this buggy proprietary crap.

@8bittimes 5 месяцев назад

It wasn't planned to be buggy.... Chip count and board space need to be optimized to save cost. So, if you have a shift register, PLUS I/O ports and timers on a single chip, that is an easy choice. When they found out it was buggy, they did not have the time anymore to fix it properly. If you watch Dave's video I linked in the description, you will learn that the 1541 was actually planned to have a CIA with working shift register instead of a VIA. But as the C64 was not ready for higher speed - it only became a 1540 with modified ROM and we only got fast serial with the 1571

@CB3ROB-CyberBunker 6 месяцев назад

oh and btw the 6526 as far as i know never fixed the problem. neither the 64 nor the 1581 nor the 128 do it 'the right way' just that the 128 can do it 'mildly faster' when paired with an appropriate drive but none of them do it irq driven and in hardware using the hardware shift register afaik. (or else it would just run at 1 or 2mbit/s no? ;)

@CB3ROB-CyberBunker 6 месяцев назад

but the c64 also has an additional problem in that the video chip hijacks the entire bus for significant time unless you turn it off (this already is a problem implementing ordinary terminal rs232 with hardware uarts and irq driving on them on any nowadays acceptable speed, let alone do proper disk interfacing)... and none of those shift registers have buffers and dma anyway (or they would only make that problem even worse than that shitbucket of a computer already has with it's timing ;)

@CB3ROB-CyberBunker 6 месяцев назад

and yet it -would- be funny to fully implement that bus as it was once intended. although we probably have to use different connectors to keep it apart from legacy hardware, as it will -never- be able to talk to any existing old commodore equipment out there (they also kinda skipped the 'synchronous communication' part while they were at it ;) (not entirely sure if a 65c22 can handle a let's say 10mhz clockpulse on the shift register -itself- when the clock signal for the chip itself would be just 4 or so, when talking to faster clocked units).

@CB3ROB-CyberBunker 6 месяцев назад

but eh yeah. still totally willing to implement a sas/sata ssd controller interfacing to -that bus- but done properly one day. just to see how it performs. (see it lacks the nifty stuff such as collission prevention (even with simple methods such as voltage compares and resistors like econet does) and is essentially half duplex no matter how it is implemented. but still. ;) lol. it also uses a looot of wires. but then again so does ethernet over anything but 100base-t1s

@CB3ROB-CyberBunker 6 месяцев назад

if that thing would have ever worked right you would have had 20 terminal screens on your cbm computer a day later :P like you also have 8 monitors on your pc today. all hooked up over that bus. and other manufacturers would have implemented it too just to also be able to access the devices for it. (See it can interface to way more than just 'diskdrives' and 'printers') :P but nah. they screwed up.

@8bittimes 6 месяцев назад

The 6526 did fix the problem. The max speed is about four clock cycles per bit for shifting out via the SR. Commodore indeed used it in the fast serial protocol. I'll probably show some measurements in a followup video

@jozsiolah1435 6 месяцев назад

Same thing is with phones and micro sd cards today. Games solve the problem, car games fix the load problem for Samsung phones. Possibly same with floppy drives, a good car game may load a proper code into the chip, replacing the bug. HC cards have lots of bugs, during successful gameplay the bugs are erased, and the card causes nice driving.

@d4qatoa 6 месяцев назад

These explanations still make no sense to me, if I'm to be frank about it. You show that with a fix to the shift register bug you get a minor speedup, but the drive is easily 10 times slower than the drives of other 8-bit systems. I appreciate t he video, but you seem to highlight an issue but no explanation why the drive is still so incredibly slow. Loading up a 32k program should take 10 seconds.

@8bittimes 6 месяцев назад

Commodore disk drives are a computer in their own right. Loading is probably as fast as you say if it were into the disk's memory. But Commodore did a design decision to use IEEE488 as interface bus, which is a standard bus and allowed to easily add many types of devices to the machine at no extra cost. There were measurement devices (IEEE488 was used a lot in those), modems, printer, plotter, and disk drives and what not, all connected using this standard interface with a standard protocol. Basically it was the "PET expansion port" in a way, albeit slower than a CPU bus, but tapping into lots of existing devices. But of course that incurred a cost in transfer time. I will talk a bit about this in a followup video I am preparing.