IntegraB PAL Decoding

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

IntegraB PAL Decoding

Postby KenLowe » Thu Mar 15, 2018 12:40 pm

I've been working on a slow burning project to RE my IntegraB, and possibly re-implement with modern components. The PCB is pretty much traced out, and I now have a good general understanding of how it all hangs together. The are a couple of PAL devices on the board (PAL12L10 and PAL18L4), which I believe are mainly used for address decoding (&FE30 & &FE34), but there are some other signals going into these ICs and I'm less certain about their specific functions within the PALs.

I would therefore like to fully reverse the logic within these PALs so I can get a complete understanding of the board. Unfortunately, the PALs are soldered directly into the board, and I'm reluctant to try and remove them in case I damage them. A lot of the PAL inputs are address lines fed via a couple of 74HCT244 tri state buffers. Other inputs come via 74HCT174 data latches (which define which blocks of memory need to be accessed). These buffers and latches are also soldered directly into the board. I'm considering removing these from the board (destructively if necessary) and installing sockets, so I can then patch in some remote switching signals into these lines, to aid testing.

Is there an easier way to do this??? Hint's, tips, guidance & past experiences most welcome!

Thanks
Last edited by KenLowe on Sun Apr 15, 2018 5:43 am, edited 1 time in total.

Prime
Posts: 2466
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: PAL Decoding

Postby Prime » Thu Mar 15, 2018 2:12 pm

Do you have schematics even rough ones of how the PALs are connected into the rest of the circuit? From that we may well be able to infer their function. Especially since the 12L10 and 18L4 have fixed inputs and outputs so knowing where these go and how the machine operates would help with educated guesses as to the logic.

Datasheets available here if you don't have them : http://pdf1.alldatasheet.com/datasheet- ... L18L4.html

Does the machine work?

If it can wait till the June Acorn meetup I'll bring my de-solder station along and we can whip them out.

Cheers.

Phill.

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Thu Mar 15, 2018 3:44 pm

Prime wrote:Do you have schematics even rough ones of how the PALs are connected into the rest of the circuit? From that we may well be able to infer their function. Especially since the 12L10 and 18L4 have fixed inputs and outputs so knowing where these go and how the machine operates would help with educated guesses as to the logic.

I haven't produced an overall schematic yet. At this stage, all I've got is a bunch of scribbled drawings of the main ICs, identifying what each pin is connected to. I could tidy that up a bit and post it, if that would help.

Prime wrote:Datasheets available here if you don't have them : http://pdf1.alldatasheet.com/datasheet- ... L18L4.html

I've got those already, thanks.

Prime wrote:Does the machine work?

Yes, it works just fine. I don't want to break it, which is why I was reluctant to remove the soldered in PALs. I don't have the right tools.

Prime wrote:If it can wait till the June Acorn meetup I'll bring my de-solder station along and we can whip them out.

That sounds like it could be an option. Would be a bit of a journey for me, though - coming down from the north of Scotland! Appreciate the offer of help.

Thanks
Ken.

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

Re: PAL Decoding

Postby 1024MAK » Thu Mar 15, 2018 11:17 pm

If you can workout how to feed the PAL inputs (directly or indirectly via other chips), then it's not hard to use the printer and user ports on a Beeb to step through each combination of logic inputs while monitoring the outputs.

From this, it is possible to work out the internal logic.

This applies to a PAL that is just combinational logic. A slightly different method is needed if the PAL contains a latch or flip-flop.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Fri Mar 16, 2018 12:16 am

1024MAK wrote:If you can workout how to feed the PAL inputs (directly or indirectly via other chips), then it's not hard to use the printer and user ports on a Beeb to step through each combination of logic inputs while monitoring the outputs


Most of the PAL inputs are being fed from 74HCT244 & 74HCT174 ICs that are also soldered into the board. My plan was to remove the board from the Beeb, remove all ICs that are socketed, connect PAL inputs and outputs to an external system (using Beeb user port to drive the inputs sounds like a good idea!), power up the board (which will power up the PALs - and the 74HCT244 & 74HCT174 ICs that drive the PAL inputs) and run the tests.

I'm guessing that would be a bad plan - trying to drive the PAL inputs from an external source, when the 74HCT244 & 74HCT174 ICs are also trying to drive the inputs? This is why I thought of removing the driving ICs, and socketing them. This would also then allow me to make an easier connection to the PAL inputs, as I can plug wires into the sockets easier than I can apply clips onto the various pins of the PAL inputs.

However, it might just be easier to remove the PALs using the correct soldering station as Phill has offered.

Thanks

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

Re: PAL Decoding

Postby 1024MAK » Fri Mar 16, 2018 12:37 am

I think you misunderstood what I mean...

If the 74HCT244 and 74HCT174 ICs are soldered, if it is possible to feed outputs from either the printer port, or the user port to the inputs of these ICs, then do that. They will then control the PALs.

As long as you know what the inputs are doing, and what the ICs between the printer port/user port lines and the PAL input pins are doing, it's still possible to work out the internal logic of the PAL chips.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Fri Mar 16, 2018 1:38 am

1024MAK wrote:I think you misunderstood what I mean...

If the 74HCT244 and 74HCT174 ICs are soldered, if it is possible to feed outputs from either the printer port, or the user port to the inputs of these ICs, then do that. They will then control the PALs.

As long as you know what the inputs are doing, and what the ICs between the printer port/user port lines and the PAL input pins are doing, it's still possible to work out the internal logic of the PAL chips.
Mark

Understood. That should be ok for the 74HCT244s buffers. The nOE for these are tied to 0v, and I can easily tie in upstream, so I should be able to drive through these buffers without any problem.
Not so sure about the 74HCT174 flip flops, though. The inputs are fed from an octal bus transceiver (74LS245) which is socketed, so I should be able to remove that and drive the flip flop inputs directly. However, the flip flop CLK is actually fed from one of the PALs :-k #-o

I need to get some decent schematics drawn up!

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sat Mar 17, 2018 1:28 pm

Prime wrote:Do you have schematics even rough ones of how the PALs are connected into the rest of the circuit? From that we may well be able to infer their function. Especially since the 12L10 and 18L4 have fixed inputs and outputs so knowing where these go and how the machine operates would help with educated guesses as to the logic.


So I've tidied up my scribbles, and attached a wiring / IC pin schedule showing how all the ICs are interconnected. Probably not all that easy to read if you're not already familiar with the board layout. It's also possibly still got a few errors as I've not done any QC on it yet.

Next step for me is to create a PCB layout using this information. What's the best free PCB design software for doing this? DesignSpark seems to get some good write ups?
Attachments
IntegraB Wiring Schedule.pdf
(365.16 KiB) Downloaded 19 times

cmorley
Posts: 426
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: PAL Decoding

Postby cmorley » Sat Mar 17, 2018 1:34 pm

KenLowe wrote:What's the best free PCB design software for doing this? DesignSpark seems to get some good write ups?

I like diptrace. It is free for non-commercial use up to 300 pads limit which is fine for many hobby PCBs. I found it quick and easy to get going. Others use KiCAD but I couldn't get on with it.

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sat Mar 17, 2018 6:59 pm

cmorley wrote:
KenLowe wrote:What's the best free PCB design software for doing this? DesignSpark seems to get some good write ups?

I like diptrace. It is free for non-commercial use up to 300 pads limit which is fine for many hobby PCBs. I found it quick and easy to get going. Others use KiCAD but I couldn't get on with it.

Thanks. I gave DesignSpark a go, but really struggled with it, so I'm now trying KiCAD. Just installing now. It seems to be more like Eagle, which I've used in the past.

Edit: It's a start!

Capture.JPG

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sun Mar 18, 2018 12:19 pm

Getting the hang of KiCAD. Quite liking it, but looking for some tips from the experts out there:

  • Can I use the same data & address labels on the unbuffered side as I'm using on the buffered side?
  • Do I really need the two connectors that I've added on my unbuffered address bus?
  • Is it bad practice to combine the address and data buses into a single bus (I'd like to keep the upper area of the schematic free for joining the uP control lines)?
  • Is there a better way to show the 40 pin connection between the Beeb and this board (I'm currently showing it as a 2nd 6502 labelled mb6502)?
  • Probably going to add a second sheet to cover the address decoding / data latching & chip select fan out, and third sheet with all the ROMS / RAM. Is that a fairly logical split?

Capture2.JPG

Nothing too earth shattering in the schematic yet, and still very much a WIP!

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

Re: PAL Decoding

Postby 1024MAK » Sun Mar 18, 2018 1:44 pm

KenLowe wrote:Can I use the same data & address labels on the unbuffered side as I'm using on the buffered side?
As long as the net identities (used by the router) are different, the human readable labels can be the same. Although the normal practice is to use a prefix or suffix on buffered signals, typically a 'b'. This saves any confusion as to which signal is which elsewhere on the schematics.

KenLowe wrote:Do I really need the two connectors that I've added on my unbuffered address bus?
Confused :?

KenLowe wrote:Is it bad practice to combine the address and data buses into a single bus (I'd like to keep the upper area of the schematic free for joining the uP control lines)?
Yes. It's normally best practice to have separate address, data and control busses. But if you think you can make it work and each and every signal is clearly labelled, you can give it a go.

KenLowe wrote:Is there a better way to show the 40 pin connection between the Beeb and this board (I'm currently showing it as a 2nd 6502 labelled mb6502)?
If the physical connection is a DIL type, keep it as it is.

KenLowe wrote:Probably going to add a second sheet to cover the address decoding / data latching & chip select fan out, and third sheet with all the ROMS / RAM. Is that a fairly logical split?
Sounds reasonable.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
daveejhitchins
Posts: 4070
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: PAL Decoding

Postby daveejhitchins » Sun Mar 18, 2018 1:51 pm

Can I use the same data & address labels on the unbuffered side as I'm using on the buffered side?
No . . . All NetNames MUST be unique!

Do I really need the two connectors that I've added on my unbuffered address bus?
Not sure which connectors you're referring to.

Is it bad practice to combine the address and data buses into a single bus (I'd like to keep the upper area of the schematic free for joining the uP control lines)?
Not a problem - It's really just to eliminate multiple connections that can get 'cluttered'. It can make reading the schematics a little easier. Some CAD packages allow BUS Naming which would require a seperate BUS - This method allows different properties to be allocated to the different BUSes.

Is there a better way to show the 40 pin connection between the Beeb and this board (I'm currently showing it as a 2nd 6502 labelled mb6502)?
What you've done is OK as long as you can allocate different footprints to the same schematic symbol.

Probably going to add a second sheet to cover the address decoding / data latching & chip select fan out, and third sheet with all the ROMS / RAM. Is that a fairly logical split?
Shouldn't really matter - I try and get everything on one sheet - makes reading and understanding a lot easier.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sun Mar 18, 2018 3:49 pm

Thanks for the feedback, guys. I'm making progress - albeit a bit slower than I had hoped - but I'm learning along the way! These were the connectors I was talking about, which are connecting bus lines together (actually, I think they might be called junctions, which is perhaps how I've manged to confuse people!):

Capture3.JPG


...but I'm not sure they're strictly necessary?

User avatar
daveejhitchins
Posts: 4070
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: PAL Decoding

Postby daveejhitchins » Sun Mar 18, 2018 8:53 pm

KenLowe wrote:...but I'm not sure they're strictly necessary?

They are just junctions - they 'join' one part of the BUS to another - otherwise you have 2 x BUS - similar normal nets - You'll have 'junctions' in those too.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sun Mar 18, 2018 10:07 pm

daveejhitchins wrote:
KenLowe wrote:...but I'm not sure they're strictly necessary?

They are just junctions - they 'join' one part of the BUS to another - otherwise you have 2 x BUS - similar normal nets - You'll have 'junctions' in those too.

Dave H :D

Thanks Dave. I just wasn't sure if the software was creating these junctions without me having to physically specify them. Just to be safe, I think I'll add them. Here's the latest. Still to add in the ROMS and the RTC, but both PALs are now there with all the connections - so if anyone want's to make an educated guess at the logic by inspection????

All labels that start with 'z' originate or end at the 6502 socket on the main BBC board. I've still to connect power yet (IC8 pin 19 also connects direct to 5V):

Capture4.JPG

Capture6.JPG

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Sun Apr 08, 2018 6:02 pm

Set up my board today to decode the first of the two PALs - IC9 (oh, and the purple wire - used to power up my gotek - was moved away from the PSU before I powered it up!):

20180408_101436.jpg

20180408_110727.jpg


Turns out that I'll need to get some pull up resistors for the 74HCT244 address buffers, as they didn't like floating inputs. What's the best value to go for?

My new logic analyser was hooked up to monitor the 4 outputs. It's a pity the Saleae logic software doesn't have the facility to report live status. I'll probably just drive some LEDs next time I set up the test - the board is now safely tucked away back in my beeb :).

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

Re: PAL Decoding

Postby 1024MAK » Sun Apr 08, 2018 10:29 pm

KenLowe wrote:Turns out that I'll need to get some pull up resistors for the 74HCT244 address buffers, as they didn't like floating inputs. What's the best value to go for?

Any value between 2.2k to 10k ohms should be fine. You can use 1k ohm if any other device driving the inputs has outputs that can sink 5mA or more.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Mon Apr 09, 2018 5:18 am

When it's disconnected from the beeb, this is the only thing driving the inputs, so I'll go for a couple of 4k7 resistor networks.

Thanks.

RobC
Posts: 2141
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: PAL Decoding

Postby RobC » Mon Apr 09, 2018 7:36 am

I built one of these to help reverse engineer PALs. You just read the PAL as a 27C020 in an EPROM programmer and run the software.

Once you've run the software, you then minimise the equations using something like Logic Friday.

cmorley
Posts: 426
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: PAL Decoding

Postby cmorley » Mon Apr 09, 2018 9:44 am

RobC wrote:I built one of these to help reverse engineer PALs. You just read the PAL as a 27C020 in an EPROM programmer and run the software.

Once you've run the software, you then minimise the equations using something like Logic Friday.


Can it infer registers, latches & state machines?

RobC
Posts: 2141
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: PAL Decoding

Postby RobC » Mon Apr 09, 2018 12:07 pm

cmorley wrote:Can it infer registers, latches & state machines?

The software reports all outputs that it believes to be registered but doesn't go further than that.

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Tue Apr 10, 2018 8:56 am

RobC wrote:I built one of these to help reverse engineer PALs. You just read the PAL as a 27C020 in an EPROM programmer and run the software.

Once you've run the software, you then minimise the equations using something like Logic Friday.

That would work really well. I never really considered reading them as EPROMs. Both PALs are fairly basic and only have combinational outputs, so should be fairly straight forward to read once I can get direct control of all the inputs.

The logical thing to do here is to remove the two PALs from the board so I can read them directly in the programmer, but I really don't want to damage them and lose the ability to read their contents, so I'd much rather leave them in the board and try to read them in situ. That, however, brings its own challenges:

For the PAL18L4 the only challenge I will have is that some of the 18 inputs are driven via latches. I think the easiest thing to do would be to (almost certainly destructively) remove the two 74HCT174 hex flip flops that drive these inputs so I can connect directly to the input pins on the PAL. I can replace these flip flops quite easily.

For the PAL12L10, I guess I will need to read the PAL as a 2732 EPROM, but run it twice, first to get the lower 8 output bits and then again to get the upper 2 output bits. Again I've got a couple of small challenge on this PAL. Firstly, one output of this PAL is fed directly back to one of its inputs. I presume it's performing a latch function. I probably need to break this connection somehow. Secondly, the four outputs from the PAL18L4 are wired directly into four of the inputs on this PAL, so it will be a bit more challenging to get these programmer to directly control these inputs - unless I break those connections as well. I did consider trying to manipulate the PAL18L4 to drive these 4 lines, but I'm not convinced I would be able to get all 16 combinations by doing this. I can control all other inputs directly.

@Prime has already offered to remove the two PALs from my board. Would that ultimately be the better way to go here??? I don't have the tools to do that without potentially damaging the PALs.

User avatar
daveejhitchins
Posts: 4070
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: PAL Decoding

Postby daveejhitchins » Tue Apr 10, 2018 10:37 am

KenLowe wrote:@Prime has already offered to remove the two PALs from my board. Would that ultimately be the better way to go here??? I don't have the tools to do that without potentially damaging the PALs.


Open the box . . . Sorry, meant to say 'take the offer' - So much easier . . .

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

RobC
Posts: 2141
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: PAL Decoding

Postby RobC » Tue Apr 10, 2018 11:36 am

I have a non-working Integra board here - I could remove the PALs and try to read them. Might be a week or so before I get round to it though as I've got some other things lined up :)

jimnagel
Posts: 4
Joined: Tue Nov 26, 2013 1:25 pm
Contact:

Re: PAL Decoding

Postby jimnagel » Tue Apr 10, 2018 12:24 pm

[[ to RobC -- Sorry for this method of contacting you, but I can't find any other. Could you please send me an email so that we can talk direct? I'm finishing the Archive news pages today and would like to include something in the magazine about your exhibit at the Wakefield show. Thanks. --Jim Nagel <18bweb at archivemag dot co dot uk> ]]
Last edited by 1024MAK on Tue Apr 10, 2018 2:02 pm, edited 1 time in total.
Reason: Edited to make the email less easy to be machine readable

RobC
Posts: 2141
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: PAL Decoding

Postby RobC » Tue Apr 10, 2018 12:28 pm

jimnagel wrote:[[ to RobC -- Sorry for this method of contacting you, but I can't find any other.

E-mail sent.

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Tue Apr 10, 2018 2:39 pm

daveejhitchins wrote:Open the box . . . Sorry, meant to say 'take the offer' - So much easier . . .

Unfortunately, it involves a trip to the 'June Acorn meetup' (Wakefield?), which is probably quite a distance away from me - otherwise I would jump at the chance! Will look at my options.

RobC wrote:I have a non-working Integra board here - I could remove the PALs and try to read them. Might be a week or so before I get round to it though as I've got some other things lined up :)

That would be tremendous, although I wouldn't want you to damage the board any further than it already is. They're one of the best (and extremely rare) expansion boards I've ever seen for the beeb, and the PALs are probably the most complex part of the board.

Also, I've got a pretty good handle on how the board works, and would be happy to try and get it functional again. There's not really too much to go wrong with them, assuming of course that it's not a fault with the PALs. I managed to breath life back into mine recently after a Varta battery leak damaged one of the tracks (it wasn't obvious!).

RobC
Posts: 2141
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: PAL Decoding

Postby RobC » Tue Apr 10, 2018 3:23 pm

I'm happy to give it a go - I've got pretty good at removing chips without damaging them.

There's always the issue that the PALs might be the reason the board isn't working but that'll hopefully show up when I get some equations out of them. I also think it's more likely that the fault is down to battery damage (although it's not obviously visible).

User avatar
KenLowe
Posts: 260
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: PAL Decoding

Postby KenLowe » Tue Apr 10, 2018 8:37 pm

That's me removed the two 74HCT174s and cleaned up the thru holes. There's no way I would have been able to remove those non destructively without causing damage to the board! Just waiting for some 16pin turned pin sockets to arrive and I'll get those soldered in. That should allow me to connect up an eprom programmer to read the PAL18L4. Once I'm finished that, I'll get a couple of new 74HCT174s plugged into the sockets and hopefully get the board working again. Will be interesting to see if I get the same result as RobC!

I'm going to struggle to decode the other PAL without removing it, thought, so hopefully RobC will manage to get the one removed from his board and decoded [-o<.