<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sun, 09 Mar 2008 23:41:05 +0100 (GMT)
From   : johan@... (Johan Heuseveldt)
Subject: TUBE chip, accessing 'Parasite' side

Hi,

On Sun 09 Mar, Jonathan Graham Harston wrote:
> > Message-ID: <Marcel-1.53-0308125220-0b0xSBG@...>
> Johan Heuseveldt wrote:
> > > On Thu 06 Mar, Jonathan Graham Harston wrote:

> > > > The contention logic is inside the Tube ULA itself. Each side can
> > > > be read and written independantly of what is happening on the
> > > > other side.
>  
> I think we may be talking about two different things. By
> contention logic I thought you meant systems that prevented
> problems if both CPUs tried to access the Tube ULA at the same
> time. That is dealt with by the fact that effectively the Tube ULA
> is two seperate devices, on two seperate CPU buses.

That seems logical, and was certainly what I suspected. But when seeing
the extra circuitry of the 6502 2ndP at the schematics, I was completely
confused. There must be some reason for that. As I stated in previous
posts, why did Acorn need that extra circuitry?
(I'm getting an idea though, read on...)

One reason could be there were different TUBE chips. Later ones might
be as you say. But how to make sure of that?

> The parasite
> accessing the parasite side of the Tube ULA doesn't interfer with
> the host side accessing the host side of the Tube ULA and vic
> versa.

Channel 3 is a good example for problems. There is actualy only one FIFO,
wether 1 or 2 bytes. What will happen if one side reads the data register,
thereby changing status bit, and the other side is just reading that status
register.

Channel 1 is completely different for its both directions. Obviously!

> Just like there's not contention between a computer and a printer
> when the computer accesses its parallel port and the printer
> accesses the other side of the same parallel port.

For me not so good as an example.
The computer will do a new byte because the previous byte was accepted -
informed via auto or polled handshake - or the system was dormant. And in
some way the data path has some sort of start and end registers.
(like the two 6522 backed to each other, and the TUBE as well??)

Even if the computer is polling, it could be a fraction to early for flag
update that printer has read the data. That takes an extra poll cycle for
the computer to see the printer has read the data. Which gives some
processing overhead, see later!, this gets me on track somehow)

> Now that I think I know what you're talking about, though, I see
> that the 6502 and Z80 copros feed PCS and HCS into an OR that
> feeds the timing circuitry - probably your cycle stretching.

Yes, and /if/ there must be a slow down or clock stretching, and the
parasite was /writing/, that process is put on hold - with RnW being
/low/ (of course) while the parasite write strobe (nPWRS) IS KEPT /HIGH/!!!

  This is done by FF1 in IC27 being /not/ clocked on its clock input pin3,
  as the Ripple Carry Output from binary counter IC11 LS161A pin15 is low,
  caused by the Enable Input pin10 kept low.

That's why I would like certainty about the full seperate sides issues,
as this /does/ suggest differently. Which could mean that it was an issue
with older TUBE chips, but we have to know then some history details.
But it may be another issue I'm starting to think of!!!

> Interestingly, the 32016 and 80186 copros don't.

I've seen that for the 80186 indeed, as I have the schematics. But as
I'm unfamiliar with the 80186, I'm still not sure: Something could be
done from inside the 80186.

Same applies for the 32016 of course, for me that is.


I wonder if you would be able to find this out on the the 6502 CoPro board?

I'm looking at it now: apart from the 8 RAM chips, the processor, TUBE
and EPROM, there are 10 other ICs. Hm, not too convincing I'm afraid. A
few are familiar and can be guessed. But a LS109 and a LS73 - both dual
J/K FlipFlops suggest some timing issue. :-(((

  74LS00  (close to the the 16MHz crystal; obvious)
  74LS02
  74LS73
  74LS393 (probably the refresh counter)
  74LS133 (probably the TUBE address decoder)
  74LS257
  74LS257
  74LS590
  74LS109
  74LS20

If it was an old hardware issue, like older TUBE chips, then certainly a
much newer design as the internal Master 6502 CoPro, would without this
extra logic. I have a vague feeling it has something similar. That confirms
quite another thought that recently started to grow in my grey cells



So I look at it from a software point of view. Imagine a data transfer,
let's say channel 3, accessed by both sides. One side polls the status
register to determine if new data can be read or written. 

This software is obviously in a loop. When the test fails, the opcode
must be read to determine that fact, and branched accordingly back to
read the opcode again to do the test again. Many clock cycles are involved.

Suppose that the polling co-processor is just a fraction sooner than the
other side is read/write the data. Then failing the test is almost old news.
At the moment the test fails, data was ok, thereby waisting the time for the
branch and rereading the test.

At that particular point is would be benificial if the other side was that
fraction sooner, or this side the fraction /later/!
I hope you see what I mean!
It's nothing to do wether the TUBE chip can cope, but a software
loop is made for 99% unnecessary. Again I hope my kind of explanation is
clear enough.

Instead waisting time on a branch and test again, the current cycle is
stretched as long as the other side is accessing the TUBE, most likely our
data register. If indeed our data is now ready, then the delay caused by the
Host/Beeb is a maximum of one 2MHz cycle; 0.5 us.

If this was not done then the software loops back with a branch and doing
the test again, something like (with cycles and times in us)

                        cycles     2 MHz    3 MHz    4 MHz 
   .test
       BIT  R3Stat        4          2        1.5      1
       BPL  test          2          1        0.75     0.5
                          6          3        2.25     1.5    [totals]
       
       LDA/STA R3Data etc

(not sure if these timings are correct)


At last I'm getting convinced that the TUBE chip is more than adequate
for its job! :-)
The extra circuitry seems to be an optimization for software loops!

Does that sound in anyway acceptable???


OK, the best thing is to build that 6809 thing, and see if it works!


Still a lot do:
    finilise the design with a few minor things
       leaving out the PIA
       start up with even the hardware I/O switch out!
       using a different scheme to switch out the EPROM,
         and switching in the I/O as well

    make a list of parts to order
    continue looking for a (proffessional) programmer
    etc



Greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place
 
Archimedes had no principles.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>