3_7 funcard fix here

[PaddyBhoy]

Ok back to the problem in hand, was i right in assuming that the issue is caused by the time it takes the Fun to respond
the card is inserted

21 C1 01 ; FE 1F the box sends a request to the card to change the size of ifs
12 E1 01 ; FE 0C card receives the request and responds

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

there is something wrong with the previous instruction which forces the card to then again retry to send the reset

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

Does the IFS command clear a section of the card so that new data can be written to it? could it be that the IFS in the source is not where the box is looking to write the info? and that is why it is having the timing issues?

Once again your help in understanding would be much gratefully received


Edit:

I'm starting to steer away from IFS for the simple reason that the card responds to the request

[Tesla]

I will repeat the problem has nothing to do with commands or how commands are processed or what response to a command is sent. The problem is more basic than that, there is a fundamental difference between the way the cards that you know work handle communications and how a funcard processes the comms. What is the difference????????????????

[TheCoder]

Assuming that all the Funcard command responses are valid (which we know is true because it works on 3_6) then ask yourself what it is that would cause the box to decide that it has a bad card and attempt to reset the slot !

The box has decided something is very, very wrong. Its not attempting the usual resends or resynchronisation. So, what could cause the box to act that way ?

Think about the way card communication works. All I/O is down one single wire !

[elli5on]

Originally Posted by TheCoder

Assuming that all the Funcard command responses are valid (which we know is true because it works on 3_6) then ask yourself what it is that would cause the box to decide that it has a bad card and attempt to reset the slot !

The box has decided something is very, very wrong. Its not attempting the usual resends or resynchronisation. So, what could cause the box to act that way ?

Think about the way card communication works. All I/O is down one single wire !

Anything to do with the amount of time the box waits for the card to send information regarding a BK or IRD?? I have been reading through this post and its probably one of the best read's i have been through on this forum. Makes really interesting reading.

Craig

[timetrex]

Originally Posted by TheCoder

Assuming that all the Funcard command responses are valid (which we know is true because it works on 3_6) then ask yourself what it is that would cause the box to decide that it has a bad card and attempt to reset the slot !

The box has decided something is very, very wrong. Its not attempting the usual resends or resynchronisation. So, what could cause the box to act that way ?

Think about the way card communication works. All I/O is down one single wire !

Ok doh, if all input/output are going down one single wire then you could assume that perhaps both could be trying to communicate @ the same time.

As we know its something to do with timeing

IRD sends command
Card should respond

but if the card has been programmed to respond at a certain rate,
the box is waiting for a response doesnt get one effectively a timeout of some sort and rensends another/same command.

[PaddyBhoy]

Originally Posted by timetrex

Ok doh, if all input/output are going down one single wire then you could assume that perhaps both could be trying to communicate @ the same time.

As we know its something to do with timeing

IRD sends command
Card should respond

but if the card has been programmed to respond at a certain rate,
the box is waiting for a response doesnt get one effectively a timeout of some sort and rensends another/same command.

do you mean it could be bottlenecking

[PaddyBhoy]

Originally Posted by timetrex

Ok doh, if all input/output are going down one single wire then you could assume that perhaps both could be trying to communicate @ the same time.

As we know its something to do with timeing

IRD sends command
Card should respond

but if the card has been programmed to respond at a certain rate,
the box is waiting for a response doesnt get one effectively a timeout of some sort and rensends another/same command.

the card does respond though

21 is the request from the box,
12 is the reponse from the card

As Tesla and TheCoder have mentioned we have to look at how the card deals with the requests that others that are not effected do different,something has changed but it's not the IFS because the card responds.Something in the source is putting the card out of sync

[PaddyBhoy]

Originally Posted by G77

well i have a full set of logs if needed. done my myself and are genuine.

i also have stuntguys faq'd and a ebook called 'the art of assembly language'

would be happy to pass these on to anyone interested.

any chance you can send me 'the art of assembly language?

i've just been going through the thread again to see if i have missed something

[timetrex]

Originally Posted by PaddyBhoy

the card does respond though

21 is the request from the box,
12 is the reponse from the card

As Tesla and TheCoder have mentioned we have to look at how the card deals with the requests that others that are not effected do different,something has changed but it's not the IFS because the card responds.Something in the source is putting the card out of sync

By the face of things the card does respond but it aint responding with the right info.

Been looking at the hex files and as the coder suggested the rst as well since its working.

THe rst hex file seems a lot cleaner than the last fixes...

+00000000: C007 RJMP PC+0x0008 Relative jump
+00000001: 9518 RETI Interrupt return
+00000002: 9518 RETI Interrupt return
+00000003: FFFF ??? Data or unknown opcode
+00000004: FFFF ??? Data or unknown opcode
+00000005: FFFF ??? Data or unknown opcode
+00000006: FFFF ??? Data or unknown opcode
+00000007: C0D8 RJMP PC+0x00D9 Relative jump
+00000008: 9A47 SBI 0x08,7 Set bit in I/O register
+00000009: 94F8 CLI Global Interrupt Disable
+0000000A: 2700 CLR R16 Clear Register
+0000000B: BF0B OUT 0x3B,R16 Out to I/O location
+0000000C: BF09 OUT 0x39,R16 Out to I/O location
+0000000D: BF05 OUT 0x35,R16 Out to I/O location
+0000000E: B90D OUT 0x0D,R16 Out to I/O location
+0000000F: BB05 OUT 0x15,R16 Out to I/O location
+00000010: BF0E OUT 0x3E,R16 Out to I/O location
+00000011: BB01 OUT 0x11,R16 Out to I/O location

where as compared to this

00000000: C010 RJMP PC+0x0011 Relative jump
+00000001: 9518 RETI Interrupt return
+00000002: 9518 RETI Interrupt return
+00000003: FFFF ??? Data or unknown opcode
+00000004: FFFF ??? Data or unknown opcode
+00000005: FFFF ??? Data or unknown opcode
+00000006: FFFF ??? Data or unknown opcode
+00000007: 930F PUSH R16 Push register on stack
+00000008: 9BB6 SBIS 0x16,6 Skip if bit in I/O register set
+00000009: C004 RJMP PC+0x0005 Relative jump
+0000000A: EE0F LDI R16,0xEF Load immediate
+0000000B: BF02 OUT 0x32,R16 Out to I/O location
+0000000C: 910F POP R16 Pop register from stack
+0000000D: 9518 RETI Interrupt return
+0000000E: E000 LDI R16,0x00 Load immediate
+0000000F: BF03 OUT 0x33,R16 Out to I/O location
+00000010: C07A RJMP PC+0x007B Relative jump
+00000011: 9A47 SBI 0x08,7 Set bit in I/O register
+00000012: 2700 CLR R16 Clear Register
+00000013: BF0B OUT 0x3B,R16 Out to I/O location
+00000014: BF05 OUT 0x35,R16 Out to I/O location
+00000015: E000 LDI R16,0x00 Load immediate
+00000016: BF09 OUT 0x39,R16 Out to I/O location
+00000017: 9AC2 SBI 0x18,2 Set bit in I/O register
+00000018: 9ABA SBI 0x17,2 Set bit in I/O register
+00000019: E0D0 LDI R29,0x00 Load immediate
+0000001A: E6C0 LDI R28,0x60 Load immediate

spot the difference?

[G77]

yeah mate, pm me your email address