Want to learn to make fun flash!

[maca]

good question really!! but the answer is no!

the flash has to be changed, not by much but has to be!

the best thing to think about with this problem is:
why did the cards work ok on the 3.6 aqnd not the 3.7?
well the 3.6 software sent the card some info and waited for a responce, lets say (and this is not the real time) 40 cycles, if it did not get a responce from the card for some reason it would wait just a bit longer and then pop! the responce that the box was waiting for came..
but in the 3.7 software the box sends the card some info (same as 3.6) and waits for a responce lets just say 40 cycles again, and when it did not get the responce the box does a resend of the information again and then waits, it does not do what the 3.6 did and wait that bit longer, so the 3.7 would keep resending the command to the card and not getting the responce so in the end would just stop..(this is the easyest way i can put it)

so really you have to change the flash to make sure it responds to the box in the correct time. there are more than 1 ways to do this. some have done the ICP way, which i think is the hardest way but problery the best and then there are other ways..

also if you are doing it for the fun you are going to have to do the new keyroll as well as its not set up in prune.asm or grape.asm but its in the redneck.asm but thats for atmega cards, but can be used to do the prune/grape.asm.
i would say fix the fun or atmega first then try the keyroll 8 for the fun card after, if you do the atmega then the keyroll is already done so you dont have to do it!

you are going to need to learn some info on AVR source code, to get a better understanding but that is good as you have a project to do while reading so you can put what you read into practice.

here are some links i have collected see if they will help but google is good!

You don't have permission to view the code content. Log in or register now.

You don't have permission to view the code content. Log in or register now.

that is but a few thats out there i am sure people have others!
also AVR studio is a good thing to download and its free, then you can compile your own project with the files from the .asm, and look and make your flash with it.

hope that helps a bit

MB

i glad someone cleared up somethink that was bugging me after reading stuff and looking over files last nite and this morning.

i noticed that on the 3.7 update file, this is repeated

21 C1 01 ; FE 1F
12 E1 01 ; FE 0C

21 00 08 ; A0 CA 00 00 02 C0 00 06 87
12 00 08 ; B0 04 08 03 00 00 90 00 35

21 C1 01 ; FE 1F
12 E1 01 ; FE 0C

does it a few times, and from what i have read it's asking for info which makes sense as it does it a few times before failing as the information doesn't get sent. in the 3.6 it did send, so worked.
So im guessing if you had both files you could change them a bit and add the code that worked in 3.6 and included it within 3.7.
As i say im just skinning over stuff at the moment

thats right from the logs, and really thats all you need to know from the logs as well !
there is not 2 files thow, its just the 1 flash file, the same 1 as 3.6 it just has to be modded for the 3.7. this is because the 3.6 has a timing issue that was there before 3.7 was out but did not matter. they have just tighted up the timing thats all..

MB

yes, but not the so the respone goes back to the card, its so the responce goes back to the box, am sure u meant that just a typo error..lol

you will have to open the .asm in wordpad or notepad and look at it in there, look for were you could change things to get the correct or as near as timing right. have a read of some AVR source info also the stunt guys faq so you know what the timings should be and were, and also what they are doing. you will need to get some basic knoledge of the code so u know what your changing/looking at. but as you have the .asm open you can look between the info and the .asm so u can see what is what, this does help alot.

MB

thanks guys some good info

 

[cg010169]

yeah meant sending it back to the box lol
also downloaded AVR studio just looking over the files etc and having a read of the guides.
More or less worked out the the timing has to be the same as the box otherwise it will blackout.

still getting my brain into gear for it all tho, but the guides and files have been a great help.
I think once you get the correct timing on the file, then it's just changing the code to update it.
But it's try and error for me at the moment.

 

[cg010169]

I also think the timing has to be changed from to either 15 or 20. Might be completely wrong, might have read to much info and getting mixed up lol

 

[cg010169]

now think it's 32 cycles lol

 

[nozzer]

why did the cards work ok on the 3.6 aqnd not the 3.7?
well the 3.6 software sent the card some info and waited for a responce, lets say (and this is not the real time) 40 cycles, if it did not get a responce from the card for some reason it would wait just a bit longer and then pop! the responce that the box was waiting for came..
but in the 3.7 software the box sends the card some info (same as 3.6) and waits for a responce lets just say 40 cycles again, and when it did not get the responce the box does a resend of the information again and then waits, it does not do what the 3.6 did and wait that bit longer, so the 3.7 would keep resending the command to the card and not getting the responce so in the end would just stop..(this is the easyest way i can put it)

The problem is really more to do with synchronisation of the incoming bitstream rather than command response times. Generally, the commands themselves respond well within the required timeframes (in most cases, the response is actually better than a real Mosc card due to the funcard doing far less checking and being a more efficient processor). The only real area where command timing is an issue is EMM processing where the funcard takes approx 8 secs to decrypt an Emm as opposed to 500mS for a Mosc card. The only reason this works is because the Emm processing is done in the background and the stb is generous enough to occasionally poll to see if the result is ready.

If the incoming bitstream isn't properly synched, then the card itself doesn't see a valid command..........

 

[nozzer]

now think it's 32 cycles lol

The bit timing has always been the Iso-defined standard bit time requested by the Nagra card. Thats 32 IsoClk cycles per bit !

If you work that out then, for the 3.68Mhz Xtal used in most phoenix devices you'll get -

( 1/(3680000) ) * 32 for a bit time of 8.6956 uS

or a baud rate of -

1 / 8.6956 uS = 115,000 baud (115Kbaud).

You could simplify the above and just do (3680000 / 32) if your not interested in the actual bit times.

This is why programs like NagraEdit connect to the card at 115Kbaud !!!

 

[cg010169]

well my head hurts now, worked more in the last 2 hours than it has in last month, but all good lol

You don't have permission to view the code content. Log in or register now.

will have a better look through it later, but i think this is what needs changing. not 100% I might add lol

 

[nozzer]

....i think this is what needs changing. not 100% I might add lol

Pretty warm but no cigar for you yet

Rather than trying to fix the problem straight off, why not try to understand how the system works first. Start by explaining exactly how serial data is captured by the funcard. Once you understand that then I think you'll be in a much better position to fix the problem.

 

[DodgyTech]

Thanks for clearing that up madBrummie and Nozzer.

What are the 3 files for? My guess is:

Prune/Grape for Fun
Redneck for Atmega
Chaos for ?

 

[maca]

Thanks for clearing that up madBrummie and Nozzer.

What are the 3 files for? My guess is:

Prune/Grape for Fun
Redneck for Atmega
Chaos for ?

wasn't the chaos file for 2110 issues ?

 

[madbrumie]

wasn't the chaos file for 2110 issues ?

thats right, choas was made for the problems that was with the 2110 boxes, the grape and prune is fun card and the redneck is atmega. you will see in the files how to make your own .HEX as well, but will have to do your fixes first.

thanks nozzer as well mate, was trying to put the problem in as simple form as possible (not because i think anyone is thick but to help people understand it) and sometimes its hard to explain.

there is alot of info within the last few pages in this thread that will help to fix the problem, buti would say dont try and guess your way there just try to understand some of the code and what it does as this will help alot!
then also when you have some understanding and get stuck you can post up the info that your having problems with, and i am sure there are a few people that will be happy to help

MB

 

[cg010169]

as i have before and im sure others would agree, the time, effort and information you and others have shared is very helpfull, as you didn't have to do anythink.


Had my little break now, while having a read over the guides again on how the card and box talk with each other.

I'm i right in thinking it's the Send ATR to IRD part of the code that needs to be changed.
Odds are it's wrong, butas im reading more, im seeing things a bit different each time lol

 

[neorage]

as i have before and im sure others would agree, the time, effort and information you and others have shared is very helpfull, as you didn't have to do anythink.


Had my little break now, while having a read over the guides again on how the card and box talk with each other.

I'm i right in thinking it's the Send ATR to IRD part of the code that needs to be changed.
Odds are it's wrong, butas im reading more, im seeing things a bit different each time lol

might i suggest reading here:
3_7 funcard fix here

i know its outside dw but theres a hell of a lot of in depth discussion there..

as far as im aware its nothing to do with the atr or the ird.. but the time in which it takes the card to respond..

similar to how the 2110 didnt work wit the net id setter

3.6 over looked these time problems and waited where as 3.7 is sticking to correct responce times

 

[nozzer]

Ok, as I suggested above, your going to have to investigate this problem by understanding how the system works and knowning what can go wrong. Pointing out relatively randon pieces of code and hoping thats whats wrong isn't going to work.

So, lets start right from the beginning !

Initially the processor is reset. This causes the processor to stop everything its doing, reset all its registers to a known state and then start executing from the reset vector location (Reset vector is at Address $0000).

In the assembly, you will find the reset vector easily enough as its the first real instruction. It may be proceeded by an assembler pseudo-op which tells the assembler to start producing code from address $0000

So, you have something like -

You don't have permission to view the code content. Log in or register now.

Now, as reset vector exists as the first entry within a table of vectors the instruction itself is usually only a jump instruction to real code. Notice that there may be other vectors defined within the table that give the addresses of routines that are called when certain hardware events occur.

So, lets look at Ext_RST

Here we have a few things happening. Various hardware registers are set up to the conditions we need them to be in, RAM is cleared to a zero state, I/O pins are setup, Stack is setup etc.....

After this you start to get to some real work. The ATR loop outputs the ATR on the cards ISO-I/O line at the predefined rate of 372 clks/bit. After that there's a little bit more initialisation of various values, specifically CmdC0/C1 response bytes. After that theres a little bit of initialisation for a timer. After that, your finally into the main loop, often called something like "Roll". After that, you basically just sit going round that loop waiting for something to happen.

Trace it through, make sure you can follow what i've described.

Now, from what i've described above, can somebody move forward and describe how serial Input is detected and captured ?

nb. I may not be working from the same source as you so what i've described above may have minor variations.

 

[madbrumie]

Nozzer beat me to it...lol

 

[DodgyTech]

Cool another learning thread.

Which source and which file should I be looking at nozzer? I had a look at autoroll.asm from Redneck, but that's just for rolling of keys.

 

[nozzer]

Which source and which file should I be looking at nozzer? I had a look at autoroll.asm from Redneck, but that's just for rolling of keys.

I think I was looking at an older version of the Prune stuff but tbh, it really doesn't matter as they are all pretty much the same general layout. If you want to suggest a particular source so everybody stays on the same page then go ahead.

Dont think i've got any source for the latest Fun/Mega AU methods so if anybody does then that would be the version to use.

Alternatively, just run the latest hex through a disassembler to give you something to work with. Not as pretty as the source code but if you work with both then you'll see what your doing easily enough

 

[DodgyTech]

I think I was looking at an older version of the Prune stuff but tbh, it really doesn't matter as they are all pretty much the same general layout. If you want to suggest a particular source so everybody stays on the same page then go ahead.

Dont think i've got any source for the latest Fun/Mega AU methods so if anybody does then that would be the version to use.

Alternatively, just run the latest hex through a disassembler to give you something to work with. Not as pretty as the source code but if you work with both then you'll see what your doing easily enough

I just opened up what madbrummie attached a few posts up. I would like to go for RedNeck as that was the choice in the Atmega Challenge thread, I'm reading up on StuntGuy's faq at the moment, so I doubt I'll be a model student at the mo. I'll be following things closely though

 

[jasperconran]

Alternatively, just run the latest hex through a disassembler to give you something to work with. Not as pretty as the source code but if you work with both then you'll see what your doing easily enough

what could i use to do that with, And where is it found pls.

 

[nozzer]

what could i use to do that with, And where is it found pls.

IDApro is complex but it does a nice job of disassembling for just about any processor you would ever come across. You can usually find a version on newsgroups etc.