Tube Detect code

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Tube Detect code

Postby dominicbeesley » Fri Dec 01, 2017 3:06 pm

Hello, as part of the blitter project (and in Hoglet's cpu debugger plug in) there needs to be a way to defeat the OS 1.20 way of detecting TUBE's presence:

Code: Select all

        lda     #$81                            ; DB38 A9 81                    ..
        sta     LFEE0                           ; DB3A 8D E0 FE                 ...
        lda     LFEE0                           ; DB3D AD E0 FE                 ...
        ror     a                               ; DB40 6A                       j
        bcc     LDB4D                           ; DB41 90 0A                    ..
        ldx     #$FF                            ; DB43 A2 FF                    ..
        jsr     mos_Pass_service_commands_to_sideways_Roms; DB45 20 68 F1        h.
        bne     LDB4D                           ; DB48 D0 03                    ..
        dec     sysvar_TUBE_PRESENT             ; DB4A CE 7A 02                 .z.
LDB4D:  ldy     #$0E                            ; DB4D A0 0E                    ..


This asks the TUBE to set the register at FEE0 to have bit 0 set then queries the result. If the bit returned is not set then the tube is not present. This works by relying on the databus holding the value &FE (the last byte of the instruction lda &FEE0) during the load by capacitance.

Unfortunately this is problematic as I will be attaching the cpu via a cpld and a level shifter chip the bus will not float in this (rather horrible) way.

So, I need to come up with a way to defeat this on the Model A/B (not sure about B+) my initial tests on the master seem to indicate that the master bus is pulled up to FF anyway?

In Hoglet's AtomBusMon there is a setting to fake $FE whenever tube is read and this must be turned on / off when compiling the vhdl. I could do this with a jumper on the board but this would require a chunk of CPLD space which is becoming a limited resource. That would mean changing the jumper depending on whether you want the tube to run or not - not great, though maybe an external switch?

I could include a patched OS1.20 with a different test: i.e. set the bit to 0 to indicate presence!

Use a 74LVC4245 buffer instead of a 74CB3T2611 - that would push up cost and board size as I'd need more chips and also take more CPLD space as the 2611 doesn't require extra signalling for directionality

So, questions are:
- is this limited to Model A/B or does it happen on Elk, B+, Master/Compact etc?
- what is the preferred method
- what have I missed?

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

Re: Tube Detect code

Postby hoglet » Fri Dec 01, 2017 3:42 pm

Hi Dominic,
dominicbeesley wrote:my initial tests on the master seem to indicate that the master bus is pulled up to FF anyway?

FYI, the master MOS does a more comprehensive test:

Code: Select all

E375  A2 01              ..      LDX #&01
E377  8E E0 FE           ...     STX &FEE0
E37A  AD E0 FE           ...     LDA &FEE0
E37D  49 01              I.      EOR #&01
E37F  A2 81              ..      LDX #&81
E381  8E E0 FE           ...     STX &FEE0
E384  2D E0 FE           -..     AND &FEE0
E387  6A                 j       ROR A
E388  60                 `       RTS

dominicbeesley wrote:In Hoglet's AtomBusMon there is a setting to fake $FE whenever tube is read and this must be turned on / off when compiling the vhdl.

It's actually driven from a jumper:
https://github.com/hoglet67/AtomBusMon/ ... on.vhd#L57
so you shouldn't need to recompile to enable/disable it.
dominicbeesley wrote:So, questions are:
- is this limited to Model A/B or does it happen on Elk, B+, Master/Compact etc?
- what is the preferred method
- what have I missed?

The original issue that necessitated the FakeTube jumper was the GODIL uses strong 1.5K pull-ups, and I didn't want to remove these. The Beeb itself contains 6.8K pulldown resistors on all the data bus lines (RP1). When combined, the GODIL pull wins and the data bus reads back as FF when no tube devices is present.

I couldn't find your level shifter: 74CB3T2611, is there typo in the part number?

What size pull up resistors are you using?

The pull up resistors may not actually be needed at all, as I think all the devices in the Beeb will treat 3.3V (from your level-shifted blitter 6502) as a high.

Dave

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

Re: Tube Detect code

Postby hoglet » Fri Dec 01, 2017 3:47 pm

Another solution, all in the FPGA, is to add a small state machine that runs when reset is released, prior to allowing the 6502 core to start. This could do a more comprehensive write-read-write-read style Tube detection (like the Master does), and based on the result you overlay a register at FEE0 that returns FE.

Dave

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

Re: Tube Detect code

Postby hoglet » Fri Dec 01, 2017 3:58 pm

http://mdfs.net/Info/Comp/Acorn/Source/

Electron Tube Detection:

Code: Select all

LDA #&81:STA LFCE0     :\ Write &81 to Tube control
LDA LFCE0              :\ Read back from Tube control
ROR A:BCC LDA16        :\ Bit 0 didn't remain set, no Tube
LDA #&01:STA LFCE0     :\ Write &01 to Tube control
LDA LFCE0              :\ Read back from Tube control
ROR A:BCS LDA16        :\ Bit 0 didn't remain clear, no Tube


BBC B+ OS 2.00 Tube Detection:

Code: Select all

LDX #&01        :\ DABA= A2 01       ".
STX LFEE0       :\ DABC= 8E E0 FE    .`~
LDA LFEE0       :\ DABF= AD E0 FE    -`~
EOR #&01        :\ DAC2= 49 01       I.
LDX #&81        :\ DAC4= A2 81       ".
STX LFEE0       :\ DAC6= 8E E0 FE    .`~
AND LFEE0       :\ DAC9= 2D E0 FE    -`~
ROR A           :\ DACC= 6A          j
BCC LDAD9       :\ DACD= 90 0A       ..

So I think it's just the OS 1.20 that has the weaker test.

Dave

crj
Posts: 328
Joined: Thu May 02, 2013 4:58 pm

Re: Tube Detect code

Postby crj » Fri Dec 01, 2017 4:32 pm

hoglet wrote:Another solution, all in the FPGA

Unfortunately, he said CPLD, not FPGA. So divide your expectations of what's possible by 25 or so. )-8

crj
Posts: 328
Joined: Thu May 02, 2013 4:58 pm

Re: Tube Detect code

Postby crj » Fri Dec 01, 2017 5:01 pm

I'm wanting to interface a modern FPGA to 8-bit voltage levels, and am cost-sensitive. However, since I want the result to be widely deployable, I'm taking an attitude of better safe than sorry.

As a disclaimer, although I've spent decades around electronics and understand many of the principles, my practical experience is approximately zero. While not trying to run before I can crawl, I at least seem to be jogging before I can walk. (-8

Anyway, unless and until prototyping shows me the error of of my ways, the parts I've identified for robustly putting a 3.3V part in a 5V mixed CMOS and TTL circuit are:
  • Input: 220Ω series resistor and rely on the FPGA's protection diodes (0.2p/signal)
  • 8-bit bidirectional bus: TI SN74LVC8T245 (8p/signal)
  • 16-bit bidirectional bus: TI 74LVCH16T245 (7.2p/signal; can safely reading undriven lines)
  • Individual open-drain output: Transistor (2p/signal)
  • Independently tri-stateable signals: 220Ω series resistor for input; TI SN74LV4T125 quad buffer for output (13.7p/bit)
(Prices exclude VAT, assume quantities in the hundreds and assume the professionals/robots will be doing the soldering.)

I'm aware that the SN74LVCH245 bus transceiver is 30% the price of a SN74LVC8T245 voltage translator and is 5V-tolerant. But I'm very nervous about the idea of trusting it to drive a bus in a way 5V CMOS will accept. Googling suggests people have found it very marginal. Similarly, if I could trust an SN74LVCH245, I could also trust a Lattice 4032ZE CPLD which has 32GPIOs, so could mediate 16 signals very flexibly at 5.2p each.

The TI automatic bus transceivers simply don't work in the presence of weakly pulled signals. I decided that meant I couldn't use them in a BBC Micro, and this thread is convincing me I was right. )-8

The 220Ω series resistors scare me, but were recommended by a very experienced friend whom I trust. The chief downsides are that you have to be sure they'll interact properly with the input protection network of the chip you've chosen, and that they're slow. However, slow is a relative term, and it looks like they're fine for 4MHz. In an Archimedes, plan B might be needed.

Those thoughts might be helpful. Equally, if any of you know of any better alternatives I'm all ears. Bear in mind, I'd quite like my circuit to be reliable in a variety of old 8-bit kit, not just Acorn stuff, so things that would also work in the land of Sinclair, Commodore, Apple, TRS, Atari, etc. win considerable bonus marks!

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

Re: Tube Detect code

Postby hoglet » Fri Dec 01, 2017 5:23 pm

PiTubeDirect and the Matchbox Co Pro use the 74LVC4245. These work out at 2.3p per signal (quantity 100, ex VAT).

I would not choose to use the passive bidirectional level shifters (like the GODIL uses) for this kind of application. Also, regarding just using 220/330 R resistors. This used to be OK with some FPGA families (e.g. Xilinx Spartan 3E), but newer parts (e.g. Xilinx Spartan 6) don't have clamping diodes.

Dave

crj
Posts: 328
Joined: Thu May 02, 2013 4:58 pm

Re: Tube Detect code

Postby crj » Fri Dec 01, 2017 5:42 pm

hoglet wrote:newer parts (e.g. Xilinx Spartan 6) don't have clamping diodes

The Max 10 has "PCI clamping diodes", which are enabled by default. I think we're good. Though I'm acutely aware that I've got a £40 dev board at stake if I'm wrong, and there's no cheaper sacrificial alternative I could use to test this.

(The Max 10 also has integrated flash, which means it can be up and running before a BBC Micro starts interacting meaningfully with the bus.)

crj
Posts: 328
Joined: Thu May 02, 2013 4:58 pm

Re: Tube Detect code

Postby crj » Fri Dec 01, 2017 5:50 pm

hoglet wrote:PiTubeDirect and the Matchbox Co Pro use the 74LVC4245

Gosh. Those are usefully cheaper, thanks.

Alas, I think the reason I didn't spot them sooner is that the QFN variant is out of stock at Mouser. Delivery expected in April 2018, woo yay!

I wonder if they can be got from anywhere else...

User avatar
myelin
Posts: 204
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

Re: Tube Detect code

Postby myelin » Fri Dec 01, 2017 6:54 pm

crj wrote:
hoglet wrote:PiTubeDirect and the Matchbox Co Pro use the 74LVC4245

Gosh. Those are usefully cheaper, thanks.


... and also TTL compatible. The 74LVC*T245 chips have Vih=0.7*VCC for the 4.5-5.5V range, so they won't work with TTL signal levels (they'll output 5V but won't register a 2.5V input level as high). The 74LVC4245 has Vih=2V across the board.

I can confirm that both the Electron and BBC Micro are happy to talk to 3.3V LVTTL logic (i.e. Voh>2.6V, Vih=2V). I haven't tried anything in a Master board yet -- I designed the updateable megarom to output CMOS levels, just in case the Master's memory controller (IC20) requires them. It looks like the 65SC12 can take TTL levels on all its pins except PHI2.
SW/EE from New Zealand, now in San Francisco, making BBC/Electron hardware projects for fun.
So far: fast serial port, 32k flash cart, USB cart interface, 3-cart expansion, Elk PiTubeDirect.

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: Tube Detect code

Postby dominicbeesley » Fri Dec 01, 2017 9:43 pm

Sorry all, I tried to reply to this earlier but my post got lost somewhere.

Thanks to everyone for the interesting replies.

Dave, thanks they're all really helpful suggestions. I like the state machine idea, though that would push the gate count up a bit. As far CPLD/SPLD/FPGA I may go for a MAX V (or MAX 10) but nothing too fancy. I could save on a couple of external components...I don't mind going a bit over the "authenticity" threshold on gate count if that is just extras to combat a problem that would not have existed in an all 5V system...

Thanks also for confirming what I suspected, Acorn saw the error of their ways and its just OS1.20 with the duff detection code.

Here's a rough sketch of what I was intending.

20171201_163655-s.jpg

Still very rough yet, I've still to finalise anything...

I went for the 74cb3t16211 for shifting (sorry for earlier typo) for ease of use: there's no need to include directional or enable signals and they are _very_ fast so from a timing/control point of view it is as if they are not there. However, they _do_ weakly pull up both sides...leading to the original question

The 16211s seemed a good fit (24 lines in a single chip) and about right on cost, especially as I will be hand building these reducing the number of components saves time. I will though need to feed a few other signals across voltage domains so maybe an extra 4245 (I have a stock of them) might be in order just for the mainboard to CPLD data lines, that would maybe solve all the problems. I could disable a 12-bit bank of these with a /OE signal but that would take out some address lines.

These _do_ seem to work for everything _other_ than the flakey tube detect code, Jason's (Xeropage) cpu level shifter uses these and they're what is being used in the PoC so far.

So, I'll either go with Dave's suggestion of a state machine (if I got for a larger CPLD like a MAX V or MAX 10) or I'll use two 16211's and a single 4245 for the system bus data lines

I'm not really interested in passive ideas, I thought about it but I don't fancy soldering up tens of resistors when I can just splodge on a couple of chips, I will be no doubt skiving off from doing my real work to get the time to make these if I do produce any and so time really is money and a couple of hours saved on soldering pays for a lot of silicon these days!

myelin wrote:It looks like the 65SC12 can take TTL levels on all its pins except PHI2.


Good shout - I didn't know that - I'd read that the SC was all TTL somewhere but possibly not. I'm working away next week but when I get back I will be taking the master down to my other house to desolder the CPU, I will see if the 74cb3txxx will drive phi2. If not that will be another thing to consider for a Master version...though I've not really thought through the Master implementation details at all.

PS: Sorry Dave, I'd forgotten that your original tube fake thing was jumpered, I removed that part when I dragged it across to the de0 nano and I ran out of test signal ports...

D

User avatar
myelin
Posts: 204
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

Re: Tube Detect code

Postby myelin » Fri Dec 01, 2017 10:32 pm

dominicbeesley wrote:
myelin wrote:It looks like the 65SC12 can take TTL levels on all its pins except PHI2.


Good shout - I didn't know that - I'd read that the SC was all TTL somewhere but possibly not. I'm working away next week but when I get back I will be taking the master down to my other house to desolder the CPU, I will see if the 74cb3txxx will drive phi2. If not that will be another thing to consider for a Master version...though I've not really thought through the Master implementation details at all.


Some more detail, seeing as this is something of interest -- I'm reading the G65SCXX / G65SC1XX datasheet from California Micro Devices, which includes the G65SC12. Under DC Characteristics, it has:

- Vih>2.4V for PHI0(in) (65SC0X only) and CLK(in) (65SC10X only)
- Vih>Vdd-0.2V for PHI2(in), which is a lot tighter than normal CMOS levels, so you might need a special buffer
- Vih>2.0V for all other inputs.
- Voh>2.4V for all outputs

It looks like the 65SC1X's clocking works like the modern W65C02 -- instead of PHI0(in) on pin 37, PHI1(out) on pin 3, and PHI2(out) on pin 39, it has PHI2(in) on pin 37 and PHI2(out) on pin 39, and pin 3 is a no-connect.
SW/EE from New Zealand, now in San Francisco, making BBC/Electron hardware projects for fun.
So far: fast serial port, 32k flash cart, USB cart interface, 3-cart expansion, Elk PiTubeDirect.

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: Tube Detect code

Postby dominicbeesley » Sat Dec 02, 2017 12:13 am

Interesting, I'm hoping I can pass phi2 straight in on the Master then - that is quite a tight. Do you have a copy of the datasheet you can share? I couldn't find anything the other day.

D

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

Re: Tube Detect code

Postby hoglet » Sat Dec 02, 2017 7:32 am

dominicbeesley wrote:Do you have a copy of the datasheet you can share? I couldn't find anything the other day.

This is the copy I've been referring to:
http://archive.6502.org/datasheets/cmd_ ... family.pdf

Dave

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: Tube Detect code

Postby dominicbeesley » Sat Dec 02, 2017 1:23 pm

Thanks Dave, that's filled in the gaps on some stuff...I need to print out a large scale schematic of the master and pin it up and start some measuring of signals. I notice the master seems to use phi2(in) for some things (TUBE) and phi2(out) for others (cartridge) will have to ponder that one.

D


Return to “hardware”

Who is online

Users browsing this forum: Bing [Bot] and 9 guests