Date   : Tue, 04 Mar 2008 14:33:11 +0100 (GMT)
From   : johan@... (Johan Heuseveldt)
Subject: TUBE chip, accessing 'Parasite' side

Hi Jonathan,

On Tue 04 Mar, Jonathan Graham Harston wrote:
> > Message-ID: <Marcel-1.53-0303231745-bc8xSBG@...>
> Johan Heuseveldt wrote:

> > As I'm not /too/ familiar with machine cycles of 80186 - or Z80 - and
> > internals, I can't interpret or understand not seeing a slow down in
> > hardware, while I /do/ expect something like that. Could be done by the
> > 80186 internally, or is it still within speed limits?
>  
> The transfers happen as fast as the host computer. If the parasite
> is too fast, it will spend time waiting to be interupted by the
> host, or will spend time polling status registers waiting for an
> "ok" signal.

This is not what I meant. It is the actual /single/ access-cycle the
coprocessor is doing to the TUBE chip, not the number of cycles (plural) the
software takes to process things.


> > BTW, I'm expecting problems with the 6809 NMIs: all registers
> > are pushed onto the stack, taken much more time than the 6502.
>  
> One of the reasons Sophie speedily dumped the 6809.

Confirms my 15+ years old thoughts/suspicions on that! :-)


> > I'll have to investigate this further, but the design has a
> > 3-pole jumper to connect TUBE NMIs to the FIRQ input as an
> > alternative to the NMI input.
>  
> Graham Toal's design uses FIRQ as the service interupt instead of
> IRQ, and IRQs to synchronise, instead of NMIs. NMI is not used.
> (ie TubeIRQ-->6809FIRQ, TubeNMI-->6809IRQ, +5v-->6809NMI)

As you can see from my previous post(s), I see it coming and provided an
alternative; FIRQ (higher priority than IRQ) instead of NMI, but would stick
to IRQ for IRQ. These IRQ protocols are always polling, so should give no
problems, although a bit slower of course. But the following...

> FIRQ:
> If R4status -> DataTransfer
> Get R1data
> If b7=1, set escape flag
> If b7=0, read Event Y,X,A
> Return
>  
> DataTransfer:
> Get R4data
> If b7=1 -> Read error message
> Get R4data, claim type
> If Claim=5, return
> Get R4data, four byte address
> Switch to appropriate transfer routine
>  
> The transfer routines then use SYNC to /wait for/ an IRQ, but with
> IRQs disabled, so no IRQ routine is called.

... is much nicer! Something I haven't thought about.

I'll look into that.
(I do use BS to switch RAM for vector access)

My main concern now is the clock stretching issues. I really hope I can
figure this out. For me, this is defenitely a university level of digital
knowledge.

So, I need to use a lot of paper etc. to work things out. Hope I'll get to
the end of the tunnel. Also hope Toal's design is eye-opening.


Thanks,
Johan

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

  The best place is a Riscy place
 
It is much easier to suggest solutions
when you know nothing about the problem.