Date : Fri, 07 Mar 2008 23:22:06 +0100 (GMT)
From : johan@... (Johan Heuseveldt)
Subject: TUBE chip, accessing 'Parasite' side
Hi Jonathan,
On Thu 06 Mar, Jonathan Graham Harston wrote:
> > Message-ID: <Marcel-1.53-0304124938-0b0xSBG@...>
> Johan Heuseveldt wrote:
> > The 'Z80copro/gif' and 6809cpu/gif' generate a 404-error.
>
> Try z80 instead of Z80...
I just clicked the link provided.
But two days later - see other post - it was ok then.
> > 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.
Yes, I know. My design used the addresses up to &FFF9 for OSCLI at &FFF7,
still leaving the vectors intact. In fact leaving the 6 remaining bytes as
spare. It turned out to be easy, including the option to change whatever
vector, as is done in the TUBE OS for the NMI vector. The additional logic
is minor. All the glue logic is in two 20V8 GALs and one 74xx30.
I should probably properly document this first desgn and put it somewhere on
the net I suppose. :-)
> > 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.
I think my hardware is slightly different, so the code is fine tuned for
that. (Taking advantages of special treatment for 16 bytes of vector RAM)
> > > | NMI|------------------------------------|PNMI |
> > > | IRQ|------------------------------------|PIRQ |
>
> Of course, changing that in light of examination of Graham's code
> to NMI<-->+5v, IRQ<-->PNMI, FIRQ<--->PIRQ
I certainly need to look into that, as I'm not sure on what exactly the 6809
will react when it is waiting in the SYNC state.
(for co-readers; this has nothing to do with the 6502 SYNC!)
> > 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
But I can't see a reason for that. As the code in RAM is /exactly/ the same
as in the ROM, as it is just copied. Addressing the TUBE, and thereby
switching the ROM out, is totaly transparent, and absolutely no crash will
result. But perhaps a different switching scheme was in mind when the code
was written this way! (e.g. SYNC with A15; my initialy thought)
I intend /not/ to use it like that, although a FlipFlop will be used as
it is convenient to do, but probably handled differently.
> 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.
Correct.
> 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.
Probably. :-)
I think for static RAM this is not needed; I'll use something different.
> [...] When IC4p8 goes low, the IC6 toggle is reset, so forcing IC6p9 high,
???
I think it will go low, and can never be high again - until the next RESET -
as it locks up itself this way. Otherwise the ROM could still be enabled by
its nCE when A15=1. You're contradicting yourself I think, as this is the
mechanism that switches off the ROM once the TUBE is addressed, as you say so
yourself in a previous post! :-)
> so forcing IC10p11 high so preventing access to ROM.
Correct, but doesn't match your previous statement about IC6p9
> 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)
Correct again (i think), so the above mistake is most likely some kind of
slip of the mind I guess!?
> 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.
Exactly, see above (just below your code)
We certainly agree on that! :-)
> > 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),
No, it doesn't. It says so about VCC2, which is still very unclear,
suggesting only /two/ VCC connections. There are /two/ of them, with an
additional special third: Main, second and - my name of it - safety.
VCC1 and VCC2 are certainly without resistor, they are the normal VCC
connections: pin2 is the main VCC, normally external but can switched
to internal if external PSU is removed or the whole board is fully internal
and has no concept of an external PSU at all, while pin4 is always from
internal VCC, though there is a hard wired jumper option.
> but doesn't mention FVcc
which makes the description at least confusing.
Pin3 is an extra one and indeed called FVcc.
It is not used when a single VCC is present; that is an internal CoPro is
used, fully powered from the host system. If used as an external 2ndP with
external PSU, FVcc is used with a 12 Ohms resitor connected to main VCC
from the external PSU.
The Z80 has even a coil in series with that: L1, 2u2.
No doubt this has something to do with the two different power supplies
connected to a /single/ chip:
1 - both PSUs are active
2 - Beeb is switched on, while external PSU is switched off
3 - Beeb is switched off, while external PSU is switched on
perhaps to prevent undesireble current loops or leakages in
situations 2 or 3?
> . 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.
Exactly.
I'm even wondering of the layout of VCCs and GND are something specific to
take into account as well (screening). Will not copy that onto the test
board, but is something to think about for a real PCB.
> > 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.
If you are really sure about that, then my design - not having similar
circuitry as in the 6502 2ndP, can be considered as finished. But that means
Acorn has put a lot of extra chips for the clock and slow down or stretching
circuits. I find that hard to believe, although I like to be proven
otherwise! :-))
The hardware certaily suggests different. Although I've found several
interesting things, I need more to discover, and let you know when I'm ready.
I certainly will not grasp it all, but hopefully enough to translate and put
into my design.
So look very carefully at the NWRD signal (23) to the TUBE chip (and compare
it also with the NRDS (22)). NWRD can be HIGH, while the processor RnW is LOW
during the second half of the E clock cycle being stretched, until released
by the Host nCS! All slow down seems to be stretching the /second/ half of E,
never the first half!
An interseting racing issue is there when the Host is just a fraction too
late to trigger this, suggesting to me that a minimal speed of a synchronous
systems like 6500/6800 of 2 MHz is necessary!
(perhaps I'll explain later)
> > > 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.
Well, I seem to remember SWI2 is officially for Motorola use, and SWI3 should
never be claimed by whatever manufacturer, leaving it for the user.
> Twenty bytes stacked on interupts or SWIs! Sheesh!
Yeah! :-(((
13 cycles, and later again 13 cycles. Will be tricky to use floppy disc
under MFM, no wonder Sophie ditched it.
Blue fingered,
Johan
--
Johan Heuseveldt <johan@... >
aka waarland
The best place is a Riscy place
When people you greatly admire appear to be thinking deep
thoughts, they probably are thinking about lunch.