Twilighte has requested that I implement the VIA shift register before now, and I always intended to, but its not that simple.
Unless the 6522 in the Oric was a synertek one (of a specific revision), the shift register interferes with the other operations of the chip (its basically broken)*.
If I implement the shift register as described in the 6522 datasheet, and someone uses it, they'll probably be in for a shock when they try their program on a real Oric.
As I understand it, there isn't any existing Oric software that uses the shift register, and Euphoric doesn't emulate it at all.
So, I'm not going to implement it unless one of two things happen:
1) Someone confirms that all Orics have the fixed synertek 6522
or
2) I find complete, correct, documentation of exactly what the side effects of the shift register are.
*(interesting note: the broken shift register in the 6522 is the reason that the 1540 disk drive for the Commodore VIC-20 is more than 8 times slower than it was originally designed to be; the CPU had to bit bang the bytes from the drive instead of letting the VIA shift them in).
VIA shift register
I've found some better info on the bugs here.
What i'll probably do is implement the SR, but not release a build until i've included all the bugs. This is pretty far down my todo list, because, tbh, i've read the 6522 datasheet, and i'm still not 100% sure how the SR is supposed to work properly, let alone with bugs included
What i'll probably do is implement the SR, but not release a build until i've included all the bugs. This is pretty far down my todo list, because, tbh, i've read the 6522 datasheet, and i'm still not 100% sure how the SR is supposed to work properly, let alone with bugs included
- ibisum
- Wing Commander
- Posts: 1646
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Why not implement it but leave it as a config option in the menu somewhere so that those of us who will help you with testing it can turn it on/off/configure it as needed during the process of getting it right? I'm tracking all your daily SVN changes where I can, and if you do this work I'll see if I can help you test with a real Atmos versus the emulator and so on ..
Right. The code in the SVN now doesn't start shifting until you read or write the SR, even in T2 free-run continuous shift-me-do mode.
When you read/write the SR in this mode, it uses the value in the lower 8-bits of the T2 latch to determine the shift rate, it doesn't use T2 itself, since T2 doesn't reload (it is only one shot, the continues from $FFFF).
This is the only way I can imagine it working from reading the datasheet, so unless you know differently, I think this mode should now be reasonably well supported.
When you read/write the SR in this mode, it uses the value in the lower 8-bits of the T2 latch to determine the shift rate, it doesn't use T2 itself, since T2 doesn't reload (it is only one shot, the continues from $FFFF).
This is the only way I can imagine it working from reading the datasheet, so unless you know differently, I think this mode should now be reasonably well supported.
Well actually shifting in could make sense, for the vsync frame skipping thing mentioned in another forum thread here..Xeron wrote:Well, i've implemented the shift-out modes of the shift register (since the CB2 output is hard wired to the AY BDIR pin, shifting-in makes no sense).
http://forum.defence-force.org/viewtopic.php?t=571
Eh? You'd still need to shift out, otherwise the SR would fill up with... well, i don't know what reading the BDIR pin of the AY would result in (could be all 1s, could be all 0s, could be noise, who knows), but it wouldn't be useful. Your scheme described there would still require a shift out mode.Twilighte wrote: Well actually shifting in could make sense, for the vsync frame skipping thing mentioned in another forum thread here..
http://forum.defence-force.org/viewtopic.php?t=571
hehe, oops i forgot which way it works... yes you are right.
Anyway i keep trying to find out more info about the curcuits the shift register adversely affected. Its easy to find reports of issues but nye impossible to get exact details
Anyway i will keep trying.
By the evidence reported, it would appear that PET users always switched off sound whenever they used the cassette system. I suspect cassette routines used one of the timers (for timing) whilst i read they used CB2 and the shift register to produce sound. It would be interesting to discover if the Cassette on the PET was connected to a specific 6522 pin and the shift register affected that
But apparently it also affected the PET disk drives forcing them to be run 5 to 6 times slower because they had to do the shifting manually. I guess reading up on both should give us a much better idea of what curcuits were corrupted.
Anyway i keep trying to find out more info about the curcuits the shift register adversely affected. Its easy to find reports of issues but nye impossible to get exact details
Anyway i will keep trying.
By the evidence reported, it would appear that PET users always switched off sound whenever they used the cassette system. I suspect cassette routines used one of the timers (for timing) whilst i read they used CB2 and the shift register to produce sound. It would be interesting to discover if the Cassette on the PET was connected to a specific 6522 pin and the shift register affected that
But apparently it also affected the PET disk drives forcing them to be run 5 to 6 times slower because they had to do the shifting manually. I guess reading up on both should give us a much better idea of what curcuits were corrupted.