Ground Glitching

[TBC]

i been looking at building a plugin for our powersyncs to enable dual vcc and ground gltiching as well as ground or vcc glitching - preliminary tests show that it may have merit but i havn't had a lot of time in all honesty.

i am not so sure that we need it for n1 but i have seen it mentioned a few times on us boards with reference to n2 cards as well as others.

if anyone has any information or useful testing results ect i would appreciate them being posted here, in the meantime over the next few weeks i will be making a prototype baord to try and test the effectiveness of this method on n1 cards. If it should prove worthwhile we can see about getting a manufactured plugin board for the tmc powersync.


tbc

 

[calhordas]

TBC


put it this ways as this was my testing area........ all r110 that i have tested for some reason do not work weel on anything lower then 2k so if you set your pot between 1.8k - 2k you have the so called sweet spot.

VCC wise if u run it vcc start 10 and vcc limit 02 you will certainly get some crap out.

As for the AT90S2313 well that's a whole diff story......tink something bigger not in size but in speed.

Cheers
Calhordas

 

[TBC]

well we certainly have a faster chip in the attiny but i have yet to see any real evidence in all honesty that we need to get a glitch resolution below that which we currently have.

i need some of these cards to test lol, the powersync probably wouldn't even run with a pot as high as 1.8k-2k but in a lot of cases the pot setting is subjective since the timing on the glitcher and the clock selected would affect this greatly i am sure.

having read a little about the prospect of ground glitching as apposed to vcc glitching i thought i would have a bit of testing and see what happens lol. i would appear initially i might add that ground glitching is not as effective as vcc glitching - not at all infact (testing on n1 cards)

obviously you have been glitching 110 with normal 4053 multiplexers, interesting the settings you mention in your post also. i would suggest maybe a little added resistance in the vcc line to the card and see how that affects the glitching.

tbc

 

[nozzer]

Dunno if it would help any but a fairly simple mod would be to use one of the very cheap clock multipliers.

With this you could multiply the clock by 4 quite easily and then divide by four again for the system clock BUT you also now have 8 possible phases of that clock instead of just 2. That means you can move the clock glitch position by multiples of 12.5% rather than just selecting a 50% move.

 

[TBC]

Dunno if it would help any but a fairly simple mod would be to use one of the very cheap clock multipliers.

With this you could multiply the clock by 4 quite easily and then divide by four again for the system clock BUT you also now have 8 possible phases of that clock instead of just 2. That means you can move the clock glitch position by multiples of 12.5% rather than just selecting a 50% move.

i expect the problem with clockmultipliers would be 2 fold, firstly we would probably be out of phase with the base clock - this would cause the vcc to fluctuate in waves loads of ++ then --- and then a smal area where it seemed fine.
secondly it would be likely the cam would not at like single clock taps below 25n/s duration (not sure of the exact time but from memory it is something around that area) i expect a true clock glitching hardware would be a very serious piece of kit lol something that could time a clock pulse in single n/s intervals from about 54n/s down to about 10n/s this being the method of searching for a suitable glitching function much like vcc levels fluctuate.
at present we using the clock line to enhance the vcc effectiveness we not really actually clock glitching the cam. just vcc glitch!

i expect that we could clock glitch with a very very fast processor with a simple setup something like the vcc setup on the atmel, the length of the clock pulse set in firmware by external atmel request counting down and keeping a pin high for a specified duration. that pin being the clock pin we could have this talking to the atmel infact by the same token we could introduce by the same method some really fine vcc glitch control. again using a vastly greater clock speed processor as an add on to the atmel. (just random thoughts lol)


7400 truth table;

1-1 = 1 ' clock pulse control 9mhz atmel/18mhz clock = single 18mhz clock at each atmel cycle high assuming perfect clock phase
0-1 = 0
1-0 = 0
0-0 = 0

if we raise the clock glitch speed then we would get shadow pulse, unless we use 2 stage dividers to increase resolution of atmel to enable the clock line glitch. but much less than 25n/s physical duration on the card clock line and we probably get a very bad reaction i.e card crashing all time.

my experiments with ground glitching are not going right well either tbh lol, they seem very much less efective on n1 cams than i hoped - i save some data ect and hopefully have a play with some n2 cards since they are vastly different requirements to n1 in glitching terms. (it seems they glitch with greater ease lol)


tbc

 

[calhordas]

TBC



Good point with the attiny roud: nothing that i have not tested b4re, nevertheless the problem you will encounter is RAM is to small not enough for the needs.

That is the problem to make it work in the unlooper, it is very good to work in a season logger like my universal season logger in which i use the attiny programmed in order to work, AU clock speeds from IRD to IRD's.


For the Unlooper think of something like the Atmega88:Clap:



As for the time beeing i had a chance to grab something interesting sucha as this init log from the UPC box and card, which was a generous gift from one of our members.

Some pics will be uploaded here for insight later.

A good log for the EMM cmd$04 and ECM cmd$07 is still required as i do not live in that area and would love to know theri keysets used in them.



I have also managed to get a script running on these cards as the normal rom110 scripts will not run properly

P.S - The problem with the AT2313 is that anything over 8mhz on speed it starts to crap out information, making it very very unstable.
In other hand with atmega88 that does not happen with higher speeds


Cheers
Calhordas/ Sempre O Mesmo

 

[calhordas]

Hi guys


As i could not help it and we have been discussing interesting info here i decided to share some photos of maybe a soon release from me still have to think better about it.

It uses a AT88 normal AT2313 and a xilin 100mhz for future natures oc:

 

[TBC]

i should point out that the above truth table is not for the chip itself it is for the logically configuration of the glitcher when it is fitted obviously thus the ouput is essentially inverted lol.

tbc

 

[JimmyP]

time to post some pics please pedro lol