VIA shift register

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
Post Reply
User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

VIA shift register

Post by Xeron » Mon Feb 08, 2010 5:21 pm

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).

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron » Tue Feb 09, 2010 10:34 am

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 ;-)

User avatar
ibisum
Squad Leader
Posts: 879
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Tue Feb 09, 2010 11:13 am

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 ..

User avatar
Dbug
Site Admin
Posts: 2394
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Tue Feb 09, 2010 8:50 pm

To my knowledge, the local Shift Register expert is Twilighte.

He has some code that runs on the real orics that uses the SR to play music faster.

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron » Tue Feb 16, 2010 4:18 pm

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).

It enough for the end sample of Quintessential to work, anyway.

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron » Wed Feb 24, 2010 4:32 pm

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.

User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte » Thu Feb 25, 2010 10:12 am

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).
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

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron » Sat Feb 27, 2010 11:37 am

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
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.

User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte » Sat Feb 27, 2010 5:17 pm

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 :P
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.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests