In message <1090317397.28481.21.camel(a)weka.localdomain> Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> wrote: Get an oscilloscope and a logic probe out then :) One trick that should work on LS type logic chips is to bend the pins in so you end up with a chip that will sit on top of another one and make reasonable contact with the chip below. Bend the output pins up, then hook up a scope. Use one channel to check the chip that's in circuit, use another to check the known-good chip on top. Solder the chips together if you want (probably a good idea) but DO NOT connect the output pins together. Obviously, if the logic differs, then the chip on the board is suspect. I'd also be tempted to desolder the video RAM, fit some turned-pin sockets to the board (Augat sockets are fairly cheap if you buy them by the tube, they're also pretty good quality - Farnell sell them), then replace the RAM chips one by one (or two by two, whatever it takes to get a full byte). I don't know how the video generation in the Dragon works, but I'd check the video RAM, main RAM and character generator ROM first, then move onto the logic circuitry. Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpem(a)dsl.pipex.com | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.dsl.pipex.com/ | 48xCD, ARCINv6c IDE, SCSI ... "Bother", said Pooh, as the read/write heads flew across the room.

In message <1090322113.28481.37.camel(a)weka.localdomain> Jules Richardson <julesrichardsonuk(a)yahoo.co.uk> wrote: You have got a scope, haven't you? If not, I've got one I could let you borrow (or I could be tempted to part with it in exchange for a small donation to the "Philpem's Wallet" fund :P ) Clip the ground clip onto the nearest available ground and take the witch-hat (if your probe has one) off the probe. Make sure the needle tip is nice and sharp. Check the signal as near to the chip as you can. Ugh. Add "Solder sucker", "Desolder wick" and "RoadRunner wiring pen" to the "Tools Required" list too. I hope you've got a good soldering iron and a powerful light (60W or so). Watch out - the tracks to the RAM may be mixed up, i.e. A0 going to A8 and so forth. Check the schematics, then buzz out the board with a continuity tester. Shouldn't make much difference. If it looks like the 220n is a replacement, swap it for a 100n. :) Speaking of floppy drives, anyone got a spare CBM 1541 or similar drive? It would save me a few days' work sorting out a disc controller - the uPD765 is a total PITA, especially the external data separator that I need to sort out... Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpem(a)dsl.pipex.com | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.dsl.pipex.com/ | 48xCD, ARCINv6c IDE, SCSI ... Divers do it deeper.

HP actually made an instrument that worked like this. It was called a 'Logic Comparator' IiRC. You put a little PCB inside the instrument containing a chip identical to the one under test, said PCB also had links to define pins as inputs or outputs. There was a test clip that you fitted over the chip under test, and the instrument displayed any pins that were difference between that chip and the known-good one inside the instrument. I've never used one, but it seems to br rather lucky-dip servicing rather than actually undertanding the problem. I find it easier to look at signals and work out if they're incorrect and if so, why. Dragons have 8 DRAM chips (either 32K bit or 64K bit) which provide the main memory and video memory. It's one chip per bit, all 8 for the byte. The Dragon is based round 3 chips. The 6809E processor, the 6883 SAM, which handles address decoding, DRAM control, video address generation, etc, and the 6847 VDG which contains the character generator, video shift registers, etc. Since you're getting stable video, I guess the SAM and VDG are doing something (maybe not the right things, but let's assume they're OK for the moment). It sounds like the SAM and RAM are not being initialised properly, which sounds like a CPU, ROM, or RAM fault. Or PSU, reset circuit, or... -tony

Tony Duell wrote: i hear this is what made the old encryption / decryption method work for analogue SKY boxes....... one chip was in the card and the other 2 was in the box - apparently the same 3 chips as in the dragon (don't ask me how though - i don't know- i've never understood) DJ

In message <40FEF41E.8030804(a)soulwax.co.uk> Dennis Smith <m1dlg(a)soulwax.co.uk> wrote: No. What you had with the Sky (well, actually News Datacom, now NDS - both Sky and NDS are part of News Corp) cards was: - A data packet that was transmitted in the Vertical Blanking Interval of the video, i.e. the first 30 or so image lines. This contained control commands for the smartcard - "enable Sky Movies", "Enable SkySports", "Disable everything", ECMs (countermeasures against pirate cards), etc. The packet also contains the "seed" that decrypts the video. - A CPU in the smartcard (allegedly based on an 8051) that decodes the commands, executes them, generates the cut points and stuff like that. - A CPU and some video storage circuitry in the decoder Now, when the decoder powers up, it communicates with the card and asks it to prove that it is a real Sky smartcard - this is done with a Fiat-Shamir zero-knowledge proof. NDS didn't implement all of the algorithm - one of the hacks exploited that. If the card passes the initial check, the decoder starts feeding it data packets and asking it for encryption seeds. The seed is used to set the cutpoints for each video line. Basically, the box switches between two FIFOs once per line. For example: |-\ /-----\ /\ ---| \- X ||| |_|----- Let's assume the X represents a cutpoint. Next we take that video line and swap over the two segments: |---\ /\ |-\ /-- ---| ||| |_|-------| \- OK, this is the encrypted video. The decoder does the same thing again - it loads half of the video line (up to the cutpoint) into one FIFO buffer, then switches over to the other. Data is pumped out of the second FIFO at the end of the line, then the output is switched back to the first FIFO. This rotates the image line around the cutpoint - hence the name "cut and rotate". This happens every single line until the keys rotate - the decoder picks up a VideoCrypt packet that basically means "Rotate the keys - give this to the card, it'll give you the next key seed". If the card has disappeared, the box no longer has the keys, so it can't decode the video. IIRC NDS also used "Spectrum Inversion" audio scrambling, too. This was enabled and disabled by the card - the card sent a command to the decoder to switch the spectrum-inversion descrambler on or off. This is incredibly oversimplified. Markus Kuhn did a lot of work on breaking Videocrypt - IIRC his website is somewhere on cl.cam.ac.uk - a Google search will reveal its current location. Actually, the card chip was a secured 8051 derivative. The one in the decoder was a Motorola secure controller in most decoders. What surprises me is that I recited this lot from memory. I think I've got most of it right, but I'm not sure. There's bound to be an error somewhere :) Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpem(a)dsl.pipex.com | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.dsl.pipex.com/ | 48xCD, ARCINv6c IDE, SCSI ... Wanted a pair of watch dogs, named the pups Timex and Rolex.