2 seperate related questions...

On the 7749 schematic, the processor has several outputs, labeled:

PWM3FD2
PWM3FD4
PWM3FD6
PWM3FD8
PWM3FDA
PWM3FCC
PWM3FEA

Now, I assume these are PWM outputs? F1 is used in the $8D code as a shift light output. The code used to turn on the shift light is this:

This bit location, bit 7, follows no logic compared to the pin it's using (PWM3FD8), or at least that I can tell?? It's not the 8th pin in a group of 8...

Anyways, F5 is an unused input.

Q1) How would I find the "location" bit of this one, which presumably uses the same address, L0040?

Q2) Is there a subroutine/built in feature that allows me to send a 0-100% DC PWM signal through that pin, with minimal computational time?

 

There's a "bit" less to it
After doing a bunch of research on the 749/730 I/O, I have come to believe that "F5" is operated directly from the "duty cycle" register 3FCC.
Duty Cycle values found from code checking
$7000 = OFF
$D000 = 0% DC
$DFFF = 100% DC

We (Z69 & I) have been working on a knock indicator light that uses "F5" but the initial testing did not turn it off. I have rewritten a routine to make it fully adjustable for brightness and duration.

If you want to test out some "F5" code on an $8D setup to see if the new version works, that would be cool.
you'll need to rig up a powered LED on the output with a resistor so as not to flow more than 400-500 mA (or less). The "F5" is a path to ground, not a powered output.
I can't make the "patch method" work with the additional "EQU" statements that are needed so it will need to be done in code and assembled. My car is all in pieces and I don't even have a battery to confirm it.
That will prove the operation of "F5" for sure anyway.
Once the routine is checked out, I'll go after the patch again and try to figure out how to make it go into bins correctly.
I know Vern is still anxious to try it again too once it works

 

Send me a binary, and I'll test it tomorrow

As long as it does something noticeable, like sweeps through the duty cycle... I won't go so far as wiring a light, but I can scope it.

 

Its not a binary, its source code only.
Needs to be run to indicate from the knock flag that is set.
I didn't put any other test routines in there.
Do you have AUJP?
Send me your current bin and I'll try to make one in the next day or so with all of your settings intact.

 

Well I can't test it without it being compiled...

read your edit - ahh, okay... probably won't work with my stuff then... I can't run the engine. Although, I could trick it into thinking it's running by sending a 60hz signal to the reference...

 

I was editing when you replied... see above
Jp

 

You have mail If you didn't know yet. Its just a stock AUJP with the code in it. I don't think you'll need any input like that. Maybe just run a ground from the knock sensor threads to the chassis and tap the sensor on the block or something.
Try hitting it with a hammer...
That sounds like knocking

 

Haven't received anything yet, but my email has been slow lately... Although I did receive the reply notification email to this thread..........

How possible would it be to just change one of the first few initialization subroutine calls to the address of your little blinky light routine? There's no guarantee that my old knock sensor even works

I'd rather have it start blinking when I power it up vs hitting things with hammers while trying to see if my meter changes...

 

Is your e-mail address on this site correct?

Made simulated knock signal connection for you to try it with.

 

yep got it, or one of the FW's... don't know why it kicked it back so many times?

 

Hey Jon - want a copy of my BIN to insert it into?

 

Your cal changes are alot of work from what Scott said. Don't know if he's already put the new KL in his fixed code yet. He was still tinkering with the original light code to see why it wasn't working last message I got.
Might be easier for you to test with instead of the base assembled version. Could give it a try, I know where it all goes now.
Kinda risky in that I can't tell if the code will execute right because I will need to add a bunch of new code.
Assembling from a base file at least would tell me that the file "assembled" properly. Hex editing can't give any indication until you try to run it.
I'll see if SL can send me over the base file and I can go at it both ways.

 

Hey, whatever you guys think is best. I'm fine with what I've got for a while if necessary (now that I can data log my WB)