<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Tue, 04 Mar 2008 13:49:38 +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-0303171427-b49xSBG@...>
> Johan Heuseveldt wrote:

> > I'm sort of 'designing' a CoProcessor with a 6809 - 2 MHz version (68B09).
> > I refound the schematics for the internal CoPro 80186, but couldn't find
> > anything else. With my own 6502 external 2ndProcessor, I've investigated a
>  
> http://mdfs.net/Tube and follow the link to Circuit Diagrams which
> will take you to http://mdfs.net/Info/Comp/BBC/Circuits You will
> also find the circuit diagram for the Acorn 6809 System CPU card.

The 'Z80copro/gif' and 6809cpu/gif' generate a 404-error.

I've found several - at least two - 6809 designs. But not for use with
the TUBE. The Acorn was a replacenent CPU board for the 'System' line.

> Note that the Tube connector pin numbers are the pin numbers of
> the ribbon cable header on the CoPro PCB, *NOT* the pin numbers of
> the plug at the host computer end. You have to rotate it to get
> the "correct" numbers, ie 1->40, 2->39, etc.

As I downloaded the 6502 2ndP schemetics yesterday, put it on two A4
sheets and cut and glue together, I immediately saw I had those pin
numbers in the wrong way, and thought my investigation starting from
the Beebs TUBE connector was wrong somehow. But indeed I was correct.
So, yes I noticed!

> At http://mdfs.net/Tube/6809 you will find information on other
> home-made 6809 CoPros. Particularly interesting is Graham Toal's
> at http://mdfs.net/Tube/6809/Toal which actually uses the Tube ULA
> and implements the Tube API. It is incredibly simple: 6809 CPU,
> 64K SRAM, Tube ULA and PAL to decode addresses.

My design was with 128K SRAM, all glue logic in a 74xx30 and two 20V8 GALs.
Also added was a PIA, just for testing purposes, and a hardware register for
RAM bank selections, and some specific vector RAM management of my own, to
keep to the MOS entry addresses the same as in the Beeb/6502 copro!

I deliberately left out FLEX for the moment, although the MMU design with
two HC219 is almost ready. Just a few minor things I can't find the details
for; the Elektor DataBook-2 is very unclear.

> I'd recommend a similar design, but also add a ROM

Yes of course.
That's how I started two months back. Familiar with the TUBE MOS, I started
to translate this 2K of code to 6809, just to get some idea. There are some
issues, as the typical 6502 approach is not available in the 6809.
And as said before, the interrupt latency is something I certainly don't
like.

> . Graham used a battery-backed SRAM, programmed it in a computer, unplugged
> it, and plugged it into the CoPro!

After more than 20 years of designing all kinds of stuuf on paper only, I
thought I really should /do/ something now. Mike Brantley (USA) from the
'fufu' mailinglist send me *fully* free of charge a 68B09 and two 68B21s!

> I'd recommend the following design, based on the 6502 CoPro which
> is a R/W memory-mapped CPU, instead of a RD/WR IO-mapped CPU:
>  
>  +--------+     +------+    +-----+            +------+
>  |      D0|=====| 64K  |====|  4K |============| Tube |
>  | 6809 ..|     | SRAM |    | ROM |            | ULA  |
>  |      D7|=====|      |====|     |============|      |
>  |        |     |      |    |     |            |      |
>  |      A0|=====|A0    |====|A0   |============|PA0   |
>  |      ..|     |      |    |..   |            |..    |
>  |     A15|=====|A15   |====|A11  |============|PA2   |
>  |        |     |      |    +-----+            |      |
>  |     W/R|-----|W/R   |-----+---------+---\   |      |
>  |        |     +------+     |         |NAND>--|PRD   |
>  |       E|--------------+---|---------+---/   |      |
>  |        |              |   |  +--\           |      |
>  |        |              |   +--|NOT>--+---\   |      |
>  |        |              |      +--/   |NAND>--|PWR   |
>  |        |              +-------------+---/   |      |
>  |     NMI|------------------------------------|PNMI  |
>  |     IRQ|------------------------------------|PIRQ  |
>  |     RST|------------------------------------|PRST  |
>                                                |      |
>                                                |      |
> A15---------+-----\                            |      |
>  ..         |      |                           |      |
>  A9---------+      |                           |      |
>  A7---------+      |                           |      |
>  ..         |13-NAND>----+---------------------|PCS   |
>  A3---------+      |     |  +--\   +------+    +------+
>      +--\   |      |     ---|NOT>--|RESET |--->RAM CS
>  A8--|NOT>--+-----/         +--/   |TOGGLE|--->ROM CS
>      +--/                          +------+
>  
> If you look at the 6502 circuit diagram, you'll see that:
>  
> All access to &FEE0-&FEFF goes to the Tube ULA
> All writes (other than the Tube ULA) goes to RAM
> After RESET, all reads (other than the Tube ULA) goes to ROM
> After a Tube ULA access, all reads (other than Tube) goes to RAM

The ROM code suggests that executing code with A15=0 does that. Some code
is copied to page &100, jumped to and back. But I can't find this concept
in the schematics. A15 /is/ used in some logic, but so far I don't see the
relevance of that. Indeed it looks as you describe.

> In other words, on RESET, the memory map is filled with
> reflections of the ROM. The startup code copies the ROM to RAM by
> effectively doing FOR A=&F000 TO &FFFF:?A=?A:NEXT.

Yes, ROM code is easy in that respect. In fact /all/ the ROM code is quite
clear to me, and learned from it as well. For example, both read and write
through R3Data-channel check on bit7 of R3Stat only! Both directions use the
same FIFO! Confimed both by the '004' document and Sprows ARM TUBE CoPro
manual. Something you can't find in all the adv. UGs!
  (They copy from each other about bit6,
   and are a bit vague to differentiate between the two TUBE sides!)

> Any access to the Tube ULA toggles off ROM access so all further reads come
> from RAM.
>  
> > few things. It appears that the power connections to the TUBE chip are more
> > advanced than I first assumed, which makes sense as this chip - besides the
>  
> The Tube ULA is always powers from the host (the Beeb) as a host
> peripheral. The parasite system has its own power supply which
> powers everything else, though all parasite systems have links to
> allow the parasite to be powered from the host instead. On the
> external 6502 you would unplug the power connectors and make LINK
> 1.
>  
> I've had a Z80 CoPro inside a Beeb for years like this.

But if you look more closely, you will see that with external power, the TUBE
has also VVC coming from the Beeb, plus an extra from the external PSU with a
12 Ohms resistor is serial. This last one is NF (not fitted) on internal
CoPro's, like the 80186; see its schematics. Then pins 2 and 4 are just
connected to each other. I feel this is a very important issue.

Therefor, having seen this precaution for VCC, I was a bit disappointed to
see some contention-logic for accessing the TUBE chip simultanously from both
sides! Although it confirmes to me that parasite Read and Write do /not/ need
a slow down, there is some clock stretching. Writing is also separately taken
into account, and for now it looks to me it is also tied to RAM cas/ras
and/or refresh timing. There are THREE bin counters to manage that; one 161A
and two 163A. Certainly I have to investigate this, and go back to the
drawing board.

So your drawing above uses the same method for creating PRD and PWR as I do.
Nothing clever from my side - but I do understand the timing issue, but
copied from the Beeb; see 8271 and 7002.

No doubt Acorn has fast processors (in future) in mind, so I wonder how fast
the TUBE can be accessed from the parasite side. No doubt the 4 MHz internal
65C102 CoPro for the Master has no slow down either, but have similar clock
stretching circuit as mentioned above.

During the years, and recently (last two months) I've seen a lot of 6809 info
again. It's overwhelming!

> Graham Toal also wrote some 6809 client code, but his only source
> is in a meta-language.

The assembler formats seen are not something to enjoy tbh, as I'm used
working with BASIC's way of doing that. Reading those assembler sources
are a nightmare to me, particular when are in upper case only.

> I am gradually translating this into 6809 assembler, and making the APIs
> available via defined calls. Do you have any preferences? The 6809 has
> three SWI entries, so I could use SWI 0-15, SWI2 0-15 or SWI3 0-15. Or any
> other block of sixteen entries (eg SWI2 &F0-&FF).

I've no idea wether I'll continue this after succeeding a real 6809 copro; I
haven't decided on that. Making it FLEX compatible is rather simple; my guess
so far. But actually being able to access the software is something else.

For a start - still on a low level - all hardware (I/O) drivers have to be
rewritten. And the memory map /is/ confusing in many respects seen so far.

I did give some thought about the three SWIs, and what I would like, but I
need to restrict myself to a first/test board first.
>  
> > doesn't have pin numbers
>  
> Crumbs, you're right. Anybody have a PDF-to-editable document
> convertor so App004.pdf can be edited and corrected?
>  
>      +------------+
>     1|GND1   ~PNMI|40
>     2|Vcc1   ~HIRQ|39
>     3|FVcc     DRQ|38
>     4|Vcc2   ~PRST|37
>     5|GND2   ~PIRQ|36
>     6|HD0      PD0|35
>     7|HD1      PD1|34
>     8|HD2      PD2|33
>     9|HD3      PD3|32
>    10|HD4      PD4|31
>    11|HD5      PD5|30
>    12|HD6      PD6|29
>    13|HD7      PD7|28
>    14|HA0      PA0|27
>    15|HA1      PA1|26
>    16|HA2      PA2|25
>    17|R/~W   ~DACK|24
>    18|~HCS    ~PWR|23
>    19|theta2  ~PRD|22
>    20|~HRST   ~PCS|21
>      +------------+
>         TUBE ULA

Note pins 2, 3 and 4!


I've seen the TUBEcompatible design recently, but couldn't find it again as I
did make a note of it. Thanks for the link. I certainly will visit again, and
look into it. Perhaps I can find the original site again too!

But the schematics found, defenitely shows to me I should investigate, and
PRD and PWR are not that simple as you suggest. Otherwise Acorn has put a lot
of not-needed hardware on the board!


Thanks Jonathan for your worthy input and thoughts.
(hope mine is of some use too???)


Greetings,
Johan

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

  The best place is a Riscy place
 
The people doing these murders are masquerading
openly in the streets. - Ian Paisley M.P.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>