Tube ULA Reverse Engineering

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dp11
Posts: 863
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Tube ULA Reverse Engineering

Post by dp11 » Wed Aug 20, 2014 2:26 pm

Been having a look in more detail.

This is probably a daft question but do you know if this was the production ULA?

I know that the early ones ( used for testing in acorn) had all sorts of corner case issues.

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Wed Aug 20, 2014 2:40 pm

dp11 wrote:Been having a look in more detail.

This is probably a daft question but do you know if this was the production ULA?

I know that the early ones ( used for testing in acorn) had all sorts of corner case issues.
Sorry dp11, I don't know much about the providence of the drawing, other than it came from Steve Furber, one of the original designers. Maybe BigEd knows a bit more.

Attached is a slightly improved drawing of the latch control logic for Register 3:
IMG_0682.JPG
I'm still finding it almost impossible to figure out the operation of this circuit. I can observe it working in a simulation, but I don't have an intuitive understanding of what's going on yet.

You can see I've annotated this in pencil to show the nodes that take defined values when Reset is asserted. The initialization problem is definitely the two SR latches.

Dave

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Wed Aug 20, 2014 5:25 pm

Finally some success :D

I've managed to simulate the whole design and pass data through all eight FIFOs.

In the end what made it work was the following:
- Switching to a behavioural model for the SR Latch that initializes to a define value
- Increasing the duration of the soft reset
- Remembering to read the dummy that is present (by design) in FIFO register 3

There are a couple of interesting things I discovered:

The design functions correctly regardless of whether the SR Latches are
initialized to 0 or 1, which is (I guess) how this is working in the real world.

There is some reset circuitry associated with the 24 byte FIFO that effectively uses HO2 to generate dummy read cycles. For this to propagate through the whole FIFO, soft reset needs so be asserted for > 24 cycles.

I need to do a bit more testing, then I'll tidy up the test harness and push the latest version to GitHub.

Off to the pub now to celebrate!!!

Dave

User avatar
oss003
Posts: 2825
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Tube ULA Reverse Engineering

Post by oss003 » Wed Aug 20, 2014 5:29 pm

Ok Dave,

it's a small step for a man but a giant leap for the acorn loving community ..

Well, actually it's a giant step for a man ..... respect !!!

=D> =D> =D> =D> =D>

Cheers!!
Kees

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Wed Aug 20, 2014 5:52 pm

Great work!

I wonder if it could be coincidence that Steve Furber had that (later?) interest in async design?

It would be awkward to discover that this was an early "idiosyncratic" version of the Tube - we'd really like it to be the gold standard.

Cheers
Ed

User avatar
MartinB
Posts: 5051
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Tube ULA Reverse Engineering

Post by MartinB » Wed Aug 20, 2014 6:00 pm

Nice one Dave, just blows my mind :shock: :D =D>

I've only really coded for the Tube once when I was working on my RAMagic! project and your last description referencing the 24 byte FIFO and 24 cycle reset triggered a memory that I had to use a 24uS delay during Tube access. I was really only following information in the App note but is the 24 a coincidence or does this delay figure of 24 relate to your 24 cycle reset? Just curious... :-k

A snip from RAMagic!....

Code: Select all

\..............................................................................
\Sets up Tube for multiple single byte transfers 2P<->I/O. If A=0 on entry
\configures for read (2P->I/O) and if A=1 configures for write (I/O->2P)
\The 4 byte parameter block is buf0-buf3 and the 2P source/destination address
\is always OSHWM @ $0800. The initial 24us delay after this call is included
\here (more than) but there must be a further 24us between subsequent
\read/writes to $FEE5 when collecting/sending bytes

rw2p      LDX       #0                  \prepare the 5 byte parameter block
          STX       buf0                \lo through hi
          LDX       #$08                \top 16 bits are $0000nnnn for 2P
          STX       buf1                \2P OSHWM is always $0800
          LDX       #0
          STX       buf2
          STX       buf3
          LDX       #>buf0              \x=lo of the block..
          LDY       #<buf0              \..and Y=hi
          JSR       &0406               \do the call to set up the tube

User avatar
jgharston
Posts: 3349
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Tube ULA Reverse Engineering

Post by jgharston » Wed Aug 20, 2014 6:27 pm

hoglet wrote:Finally some success :D
Hurray! Have a beer \:D/

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dp11
Posts: 863
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Tube ULA Reverse Engineering

Post by dp11 » Wed Aug 20, 2014 6:29 pm

Well done. This is a massive achievement.

I think the corner case would become apparent after a few hours of real operation judging from what I've heard while development was happening .

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Wed Aug 20, 2014 7:02 pm

dp11 wrote:Well done. This is a massive achievement.

I think the corner case would become apparent after a few hours of real operation judging from what I've heard while development was happening .
Thanks Dominic.

Did you work at Acorn then in the early 90's?

What sort of corner cases do you remember?

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Wed Aug 20, 2014 8:03 pm

hoglet wrote:I went back to the link you posted earlier:
viewtopic.php?p=81490#p81490
and it sounds like Richard's design plus flynnjs's updates were close to working.

Wouldn't it be better to build on this work, and focus in on the specific bits that aren't working correctly?
I've been digging through our code repo, and email trails from 2010, and discover that we did make changes subsequent to the release we made in June of that year, as published on the beeb816 website.

So, I've uploaded a "new" "release" which corresponds to the most recent code we mentioned in mail, and which certainly has one or two fixes. As it turns out, it looks like there's at least one subsequent further fix in our repo - we will probably upload another new release when we understand what we were doing. These updated releases, unlike the original, have not necessarily been tested in hardware, because our Master and copro broke. But we do thank Mark (retroclinic) for various experiments and comments during the second part of 2010. It seems so long ago!

What's in this new release? A couple of configuration options, corrections to the parasite-side interrupt generation, some fix to operation when reg 3 is just two bytes. But we suspect that file I/O still doesn't work. (Sorry for the vagueness: time has passed.)

Cheers
Ed

dp11
Posts: 863
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Tube ULA Reverse Engineering

Post by dp11 » Wed Aug 20, 2014 8:08 pm

I haven't worked at acorn , but know a number of people who have worked at acorn who used early ULAs

User avatar
1024MAK
Posts: 8202
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Tube ULA Reverse Engineering

Post by 1024MAK » Wed Aug 20, 2014 10:38 pm

All I can say is that I register my glee at the good work being done here :mrgreen:

I'm sure that everyone will be as happy as a flip-flop when you have a modern replacement fully functional.

Yes, I know the jokes puns are bad, it’s something to do with my bi-stable personality #-o :roll: :lol:

Mark

poink
Posts: 963
Joined: Tue Mar 01, 2011 10:27 am
Contact:

Re: Tube ULA Reverse Engineering

Post by poink » Thu Aug 21, 2014 12:07 am

BigEd wrote:I wonder if it could be coincidence that Steve Furber had that (later?) interest in async design?
Links nicely to his work on Amulet (asynchronous ARM processor) which I remember cropping up in Acorn User eg., http://www.eetimes.com/document.asp?doc_id=1137901

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 3:48 pm

Hi all,

I've done a bit of tidying up, and checked the latest verilog bits into Git:
https://github.com/hoglet67/TubeULA/tre ... simulation

Dave

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 6:05 pm

OK, so maybe yesterdays celebratory beer was a tad premature. I added some status flag testing to the simulation, and there seems to be a slight problem/bug with the FIFO register 3 in the host to parasite direction.

The problem is with one of the status flags for this FIFO, called the N bit in the Tube Application Note.

It's likely I'm just not understanding how this flag is meant to work, but it seems to always be '1' indicating action required, even if the FIFO has been emptied.

It's not clear from the Tube Application Note whether this is meant to be different that the other "Available" flags, and what actions should result in this being cleared.

Ed, any thoughts on this?

Dave
Last edited by hoglet on Thu Aug 21, 2014 6:14 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 6:12 pm

hoglet wrote:It's likely I'm just not understanding how this flag is meant to work, but it seems to always be '1' indicating action required, even if the FIFO has been emptied.
Ah, I think I understand now....

From page 12 of Tube Application Note:

Code: Select all

PNMI either: M = 1 V = 0 1 or 2 bytes in host to parasite register 3 FIFO or 0 bytes in parasite
 to host register 3 FIFO (this allows single byte transfers across register 3)
or: M = 1 V = 1 2 bytes in host to parasite register 3 FIFO or 0 bytes in parasite to host
 register 3 FIFO. (this allows two byte transfers across register 3)
(or both)
This bit is stuck at one because there are zero bytes in the parasite to host register. How confusing!

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Thu Aug 21, 2014 6:24 pm

Hmm. There's some talk in the app note about the V bit which determines whether reg3 is used in single-byte mode or two-byte mode. If you're in two-byte mode, you need to read two bytes to empty the FIFO. Which means two should have been written. Could that be it?

For more info on Tube operation see Yellow Pig's page:
http://www.cowsarenotpurple.co.uk/bbcco ... /tube.html

Possibly "The New Advanced User Guide" will have some unique information - see Chapter 18 on p327. John K has a copy on his website.
http://web.inter.nl.net/users/J.Kortink/home/documents/
(Edit: also a copy at http://www.msknight.com/bbc/manuals/new ... -guide.pdf)

This might be relevant:
PH3 This operates (in a rather untidy way) as a 1-byte or 2-byte register. It can always accept two bytes, but the "space available" status bit (on the parasite side) is cleared as soon as one byte is written to the register. In other words, the register is able to accept a second byte even though the status bit suggests that it cannot.

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 7:23 pm

Ed,

At the moment, none of my tests distinguish between 1 byte and 2 byte modes, because they only check the status bits when the FIFOs are empty or full.

But I'm now pretty convinced now this is working as intended.

It seems that bit 7 of address 4 on the parasite side (the N bit for register 3) is active when HP3 has data available, but also when PH3 is empty. It's this second part that makes it different from the other available bits.

Looking at your's and Richard's RTL Verilog, I don't think it accurately represents this behaviour:

Code: Select all

        case ( p_addr )
          3'h0: p_data_r = { p_data_available_w[0], !p_full_w[0], p_reg0_q_r[5:0]};
          3'h1: p_data_r = p_data_w;          
          3'h2: p_data_r = { p_data_available_w[1], !p_full_w[1], 6'b1};
          3'h3: p_data_r = p_data_w;
          3'h4: p_data_r = { p_data_available_w[2], !p_full_w[2], 6'b1};
          3'h5: p_data_r = p_data_w;          
          3'h6: p_data_r = { p_data_available_w[3], !p_full_w[3], 6'b1};
          3'h7: p_data_r = p_data_w;          
          // default: p_data_r = p_data_w;
        endcase // case ( p_addr )  
If you look at the above, bit 7 of address 4 is p_data_available_w[2].

I think it should actually be p_data_available_w[2] | ph_zero_r3_bytes_avail_w.

See the table on page 14 of the Tube Application Note.

I wonder if this is the reason that file system transfers were not working correctly?

Dave

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 7:42 pm

Actually, I think the N flag probably should just mirror the PNMI logic:

Code: Select all

  if ( h_reg0_q_r[`V_IDX] == 1'b0 )
    n_flag = ( p_data_available_w[2] | ph_zero_r3_bytes_avail_w  ) ;
  else
    n_flag = ( p_r3_two_bytes_available_w |  ph_zero_r3_bytes_avail_w  ) ; 
Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Thu Aug 21, 2014 8:17 pm

Sounds plausible that N behaves like PNMI (when PNMI is enabled) - is that borne out by the circuit?

This would need a correction in our code, as you say.

Cheers
Ed

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 9:16 pm

BigEd wrote:Sounds plausible that N behaves like PNMI (when PNMI is enabled) - is that borne out by the circuit?
I think so. I haven't fully traced the circuit, but this net connects connects to the FIFO control of both PH3 and HP FIFOs.

I'm wondering whether to "borrow" my Atom GODIL, reconfigure it with your design, and try it in my old BBC B Second Processor. What could possibly go wrong :lol:

Out of interest, what killed your master second processor?

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Thu Aug 21, 2014 9:23 pm

Sounds good to me, if you have a GODIL and a Tube socket!

Our internal copro most likely has a RAM fault, so nothing Tubey about the failure. I think it might be terribly unreliable rather than completely not working.

We had the best results from the GODIL connecting to the internal copro interface in the master. I think electrically the external tube connecter is different, and perhaps different again in a model B. So there are three cases to get right, and I'm not sure if we had any success with the external interfaces. But then again, we didn't have any scope or logic analyser to find out what was wrong, so it might be easy to get over that.

Cheers
Ed

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Thu Aug 21, 2014 9:27 pm

The main worry I have is that the Model B databus has (I think) 6K8 pulldown resistors, and the GODIL has 1K5 pullup resistors. Although no damage is likely to occur, it would surprise me if this stopped the Model B from working.

I do have a Master 128 though. I need to check what it's tube circuit was like.

Dave

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Fri Aug 22, 2014 8:26 am

hoglet wrote:I'm wondering whether to "borrow" my Atom GODIL, reconfigure it with your design, and try it in my old BBC B Second Processor. What could possibly go wrong :lol:
Actually, I'm going to be a little careful about this. The Tube ULA contains two separate VCC power supply rails, one powered by the parasite and the other by the host. These are actually completely isolated on the ULA. So, if I just plonk in a GODIL, it's not clear whether it's best to power it off the host side or the parasite side.

Looking carefully at ReTuLa, I can see that pin 2 is connected (Parasite VCC), but I can't make out whether pin 4 is also connected. It's important to avoid bridging the two VCC power rails.

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Fri Aug 22, 2014 8:55 am

Hmm. We used a GODIL too. But I can't remember what we did about powering it. From the UCF file it seems we just ignored the 5 power/ground pins, so the question is which jumpers did we set on the GODIL to pick up power and ground.

I have found some notes we made. It looks like we plugged the GODIL directly into the Tube socket, and that worked in the internal copro, when we set the Xilinx I/Os to LVTTL mode with no internal pullup or pulldown.

When we tried in a (kindly donated) Z80 cheese wedge connected to a model B, we had limited success - we did get a * prompt but ctrl-break didn't prompt to insert a disk, so possibly we were seeing the reg3 bug.

We did some subsequent experiments using a daughterboard with three 74HCT245 to buffer the host side connections. It worked with a Tube ULA, but not with the GODIL - so that turned out to be a step backwards.

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Fri Aug 22, 2014 9:00 am

Ed,

Looking at the jumpers on this photo:
eds_godil.JPG
It looks like pin 2 (parasite VCC) and pin 4 (host VCC) are both jumpered to the GODIL's VCC rail.

This will be fine in an internal co-processor, but a bit dodgy in an external one, unless you change the jumpers on the co-processor so it is powered of the host.

Still pondering about how best to proceed with my old external 6502 cheese wedge.

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Fri Aug 22, 2014 9:42 am

Well spotted. As you say, that looks like dubious tactics for a cheese wedge, which means there's still a question of which way to go: power from the host or from the parasite. Does the checkplot shed any light on what the real ULA does?

BTW I've just uploaded a third release to the beeb816 site - it's again from 2010, and brings us up to date with the state of the source in our repo. I've also updated the README in that release with some notes from our changelogs. It would be best, I think, to use and to make patches to this latest code rather than an earlier snapshot.

Here's the relevant part of the README:
20100606T1943 (r433) First public release, tested in an OHO
Electronics module (GODIL) using a Xilinx Spartan FPGA and plugged
into the 40 pin Tube ULA socket on a Master Turbo (128) internal
65C102 Coprocessor card. Some benchmark programs (including the
Sphere demo) have been run and serial IO has been exercised, but
nothing more extensive than that. File I/O did not work.

20101023T2045-r491 Second public release, not well tested in
hardware.
Fixes polarity of PNMI, PIRQ
Fix two byte mode trigger of PNMI
Fix 2 byte mode in reg3
Fix a sensitivity list
Updated UCF file
Added clocked/RNW interface option
Added option for separate parasite databusses (for HDL CPU)

20101027T2256-r495 Third public release, not well tested in
hardware.
Replace reg select FFs with latches, add latch for rdnw
Fix race condition in reg3 select (breaks dual 6502 type interface?)
Cheers
Ed

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Fri Aug 22, 2014 12:01 pm

BigEd wrote:Well spotted. As you say, that looks like dubious tactics for a cheese wedge, which means there's still a question of which way to go: power from the host or from the parasite. Does the checkplot shed any light on what the real ULA does?
The real ULA has a split VCC rail, with the left half of the IO ring powered from the host (via pin 4), and the right half powered from the parasite (via pin 2).

The core is powered from parasite as well, via pin 3 and some on chip regulators to generate 0.95V VS rail on chip.

So, it's going to be tricky to replicate this, which is why I was interested in what John K had done with ReTuLa.

Dave

User avatar
BigEd
Posts: 2266
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube ULA Reverse Engineering

Post by BigEd » Fri Aug 22, 2014 12:53 pm

Here's an idea:
- power GODIL from the parasite side (it's more local)
- take the host-side power pin as an input, with a pulldown
- use that pin to tristate the host-side outputs if it's low

User avatar
hoglet
Posts: 7756
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Tube ULA Reverse Engineering

Post by hoglet » Fri Aug 22, 2014 1:14 pm

BigEd wrote:Here's an idea:
- power GODIL from the parasite side (it's more local)
- take the host-side power pin as an input, with a pulldown
- use that pin to tristate the host-side outputs if it's low
That would go some what towards protecting the beeb when it was powered off.

I was also concerned about the other case, i.e. the host powered, but the parasite powered off, whether there is any risk of damage to the GODIL. It may be the level shifters provide some protection.

It seems the Altera MAX device used on ReTuLa actually supports multiple independent power rails, just like the Tube ULA does. I found an application note here:
http://www.altera.co.uk/literature/an/an490.pdf
That's a nice feature, I wonder if John K made use of this?

Dave

Post Reply