All JP1.3 extenders have a bug in them....
Posted: Tue Apr 14, 2009 11:00 pm
This may explain some random crashes. Thanks to AllanW who not only reported this but disassembled the code and chased down the bug in the 3039 extender. I used the same code in all of the remotes so this impacts all of the JP1.3 extenders.
I'm in the process of releasing new extenders for all of the JP1.3's anyway to support IR 8 and the setup code validation and a couple of new things, so this was good timing.
The details:
1: When adding a 16-bit number, you have to ADD the low byte and then ADD with Carry the high byte (ADC) so that any carry from the low add makes it into the high byte. unfortunately, I was ADDing the high byte first and then ADCing the low byte. oops. So this bug was data dependent. The code was in the part of the extender that loaded macros, so it could make some odd macros appear and things would go haywire.
2: In that same block, I was decrementing a 16-bit pointer (DECW) and then jumping based on that being zero. Allan found an errata in the S3F80 users manual that says that combination can result in strange behavior. I'm not sure we ever saw anything bad here, but it made sense to change the code to ensure that nothing bad happens.
Quite the sharp eye, credit goes out to Allan.
I'm going to China on Friday, some of my usual testers have the builds of the extenders now and have been testing. I've tried the Atlas OCAP and the Comcast DVR and all seems well. Hopefully by the time I return I'll have the results of the testing and I'll be able to release the new extender versions.
-bill
I'm in the process of releasing new extenders for all of the JP1.3's anyway to support IR 8 and the setup code validation and a couple of new things, so this was good timing.
The details:
1: When adding a 16-bit number, you have to ADD the low byte and then ADD with Carry the high byte (ADC) so that any carry from the low add makes it into the high byte. unfortunately, I was ADDing the high byte first and then ADCing the low byte. oops. So this bug was data dependent. The code was in the part of the extender that loaded macros, so it could make some odd macros appear and things would go haywire.
2: In that same block, I was decrementing a 16-bit pointer (DECW) and then jumping based on that being zero. Allan found an errata in the S3F80 users manual that says that combination can result in strange behavior. I'm not sure we ever saw anything bad here, but it made sense to change the code to ensure that nothing bad happens.
Quite the sharp eye, credit goes out to Allan.
I'm going to China on Friday, some of my usual testers have the builds of the extenders now and have been testing. I've tried the Atlas OCAP and the Comcast DVR and all seems well. Hopefully by the time I return I'll have the results of the testing and I'll be able to release the new extender versions.
-bill