Date : Thu, 06 Mar 2008 16:30:06 +0000
From : jgh@... (Jonathan Graham Harston)
Subject: TUBE chip, accessing 'Parasite' side
Johan Heuseveldt wrote:
> The 'Z80copro/gif' and 6809cpu/gif' generate a 404-error.
Try z80 instead of Z80...
> 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!
That bit is one really fiddly bit trying to dump straight across
to the 6809. There are hardware vectors from FFF2 to FFFF, right
on top of OSBYTE, OSWORD and OSCLI.
> 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.
http://mdfs.net/Software/Tube/6809/Toal/kernel.src is my
translation of Graham's Skimp code into 6809 assembler, but
translating from the 6502 is probably a better bet. (I've done
hand assembly before, but this is the first time I've done hand
compilation!) Somewhere I've got a sort-of 6502->6809 translation
of the Tube client MOS. I'll have to track it down.
> > | NMI|------------------------------------|PNMI |
> > | IRQ|------------------------------------|PIRQ |
Of course, changing that in light of examination of Graham's code
to NMI<-->+5v, IRQ<-->PNMI, FIRQ<--->PIRQ
> 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.
After examining the circuit diagram I commented the code as
follows:
LDX #&10
.LF83B
LDA LF859,X:STA &0100,X :\ Copy jump code to &100
DEX:BPL LF83B
LDA &EE:STA &F6 :\ Copy &EE/F to &F6/7
LDA &EF:STA &F7
LDA #&00:STA &FF :\ Clear Escape flag
STA &F2:LDA #&F8:STA &F3 :\ Set memtop to start of ROM at &F800
JMP &0100 :\ Jump via low memory to page ROM out
\ Executed in low memory to page ROM out
\ --------------------------------------
.LF859
LDA TubeS1:CLI :\ Check Tube R1 status to page ROM out
.LF85D
JMP LF860 :\ Jump to initilise I/O with banner
.LF860
JSR PrText :\ Display startup banner
EQUB 10:EQUS "Acorn TUBE 6502 64K"
EQUB 10:EQUB 10:EQUB 13:EQUB 0
NOP
A Reset signal from the Tube ULA on pin 37 sends a pulse from p6
of IC26. This resets the CPU and sets the flip flop IC 6.
When IC 6 p9 is high (ie, just after RESET) and A15 is high
(>32K), then IC10 p11 is forced low, selecting the ROM. The low
input to IC10 p1 forces the output at p3 high, so deselecting the
RAM.
When the CPU reads, the ROM OutputEnable is driven low, so ROM is
read if IC6p9 is high and A15 is high - ie a read >32K just after
RESET.
When the CPU writes, the output from IC10p3 is overridden by the
R/W signal through IC10p4/5/6, so writing to RAM.
When Tube addresses are selected, IC4p8 goes low, so preventing
IC10p3 from low, so preventing RAM from being accessed. When IC4p8
goes low, the IC6 toggle is reset, so forcing IC6p9 high, so
forcing IC10p11 high so preventing access to ROM.
Ah ha. Reads from <32K come from RAM, reads from >32K come from
ROM until the flip flop is reset. Writes always go to RAM. (Except
the Tube registers)
I'm not sure why it needed to jump via low memory (other than the
hardware design), as if it continues executing in high memory and
accessed the Tube registers, the ROM would still be paged out and
the CPU would continue executing the same code "underneath" in
RAM.
> 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.
AppNote004 mentions Vcc1 and Vcc2 (must be fed from +5v through
resistor), but doesn't mention FVcc. All the CoPro circuit
diagrams I've got use the same arrangement of +5v links and
connections, so it's probable wise to copy them.
> 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
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.
> > 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.
Having quickly looked through some FLEX code, it uses SWI3 for its
own puposes and IRQ for background timing/scheduling. I seem to
remember reading somewhere a recommendation to use SWI3 for low
level stuff, SWI1 for user/application programs, so I'll use SWI2
for the I/O API.
Twenty bytes stacked on interupts or SWIs! Sheesh!
--
J.G.Harston - jgh@... - mdfs.net/User/JGH
The most perfect world is an imperfect world as the imperfections
give people a reason to strive to change it.