Shift Register doesn't shift when expected in mode 100

[GoogleCodeExporter]

Using the test program in hs.tap (first attempt at HardSID) the program 
attempts to use the Shift register in mode 100 to shift out free running 
at T2 rate onto CB2 which sends 00 (Decay code) to the AY cycle register.

The program will infinite loop at start. Skip jump in debugger then step 
through code to second infinite loop.

As T2 counts down (here it occured at AF08) the shift register shifted 
before timeout of T2 high OR low.

It is understood the first shift occurs on writing to SR but could not 
find what triggered the shift register to shift the second time when it 
did.

Using Oricutron 0.4 under Windows build

Original issue reported on code.google.com by Jonathan...@gmail.com on 17 Feb 2010 at 9:51

Attachments:

• hs.tap

[GoogleCodeExporter]

I have updated hs.tap utility to allow one to edit the parameters. It should be 
possible to generate all sorts of wonderful sounds but currently the shift 
register 
for mode 100 does not appear to be relying on T2 low order timeouts to shift.

Original comment by Jonathan...@gmail.com on 18 Feb 2010 at 10:37

Attachments:

• hs.tap

[GoogleCodeExporter]

I can't seem to make it do anything at all. Certainly timer 2 is never written 
to.

Original comment by p...@petergordon.org.uk on 2 Mar 2010 at 8:42

[GoogleCodeExporter]

I/We need to try this prog on a Real Oric
If my understanding is correct a shift occurs either when a value is stored in 
SR or 
when Timer 2 latches the low order byte.

Original comment by Jonathan...@gmail.com on 3 Mar 2010 at 10:24

[GoogleCodeExporter]

What i mean is, the program itself doesn't seem to work at all. I press space, 
but no
registers seem to ever get written to at all.

Original comment by p...@petergordon.org.uk on 3 Mar 2010 at 1:38

[GoogleCodeExporter]

BTW, when you say:

"Timer 2 latches the low order byte"

you seem to think that timer 2 will expire, then reload from the latch. I find 
no
evidence from the datasheets i have to hand that this is the case. As far as I 
can
tell, timer 2 *always* decrements through zero and carries on from $FFFF.

This is why my current "shift out under T2 control" shifts at a rate determined 
by
the timer 2 latch value, and doesn't use the actual timer 2 counter itself. I 
don't
have an easy way to test a real VIA at this time, so if you could prove or 
disprove
this, i'd be grateful ;-)

Original comment by p...@petergordon.org.uk on 3 Mar 2010 at 1:44

[GoogleCodeExporter]

Err... yes... so to be clear, my implementation currently does the following:

* Writes to the T2 low order latch set the shifting rate, but does not trigger 
a new
shift operation
* A read or write of the SR triggers the beginning of the shift operation
* A shift operation occurs once every "timer 2 latch value" cycles

This is how I understand the datasheet.

Original comment by p...@petergordon.org.uk on 3 Mar 2010 at 1:46

[GoogleCodeExporter]

It seems that the wikipedia article on the 6522 has been updated and is more 
accurate regards the 6522 Shift Register bug. Is it more acurate for you to 
more accurately emulate the Shift register? :P

Original comment by Jonathan...@gmail.com on 21 Jun 2010 at 1:00

[GoogleCodeExporter]

It looks like it does, but i'd have to go back and re-read the datasheet as 
i've pretty much totally forgotten how the VIA works at that level of detail :)

None of this changes any of what I said above, btw.

Original comment by p...@petergordon.org.uk on 21 Jun 2010 at 2:48

[GoogleCodeExporter]

Ok, I re-read all the above earlier and i realise i avoided many of your 
questions, apologies. i'll need to take a look at hs.tap

Original comment by Jonathan...@gmail.com on 21 Jun 2010 at 3:55