Carpokes Porsche Forum

This KLR sequence is also stumping me.

// Thus the ret statement at 0x2B0 will use whatever we put on the stack // in this routine below.
0x2a3 mov r1,#$17
0x2a5 mov @r1,#$8 // 17h <- 8 (locations will be 8xxh)
0x2a7 dec r1
0x2a8 clr a
0x2a9 xch a,@r1 // a <- 16h and 16h <- 0
0x2aa jb0 $02AF // call the first function 0x800?
0x2ac dec a
0x2ad dec a
0x2ae xchd a,@r1
0x2af sel mb1
0x2b0 ret

I can't understand why it's doing the sel mb1 here. All other pairs of mb1/mb0 make sense for jumping/calling the other ROM section, but this just sets mb1 and returns. It leads to a later call that should be address 325, but ends up going to a bogus B25 location.

whalenlg wrote: Tue Mar 03, 2026 10:40 pm I can't understand why it's doing the sel mb1 here. All other pairs of mb1/mb0 make sense for jumping/calling the other ROM section, but this just sets mb1 and returns. It leads to a later call that should be address 325, but ends up going to a bogus B25 location.

I haven't understood that section yet either. I just ran my simulator and put a breakpoint at 0x2a3. Here's how it got there:

1. Quickly after reset we go to 0x77 and then execute a load of code up to 0x1a3
2. 0x1a3 call $0336
3. Run a load of code until we get to 0x352
4. 0x352 ret
5. That ret jumps us to 0x2a3

Then if we keep stepping, we do the sel mb1 and and ret at 0x2b0. That ret jumps us to 0x80e leads to 0x812 which is a jump-to-self.

I still don't understand what the purpose is. I can't afford to spend a day thinking about it now because my employer has found me something to do. I'll be back as soon as I've figured out how to make a Raspberry Pi Pico work as a 5.1 channel USB sound card.

The idea of this section is that we have a list of functions we want to call at the end of the program, but there isn't time to call all of them between trigger events. Instead, the program calls one of them, but a different one each time. So on each trigger event, we do all the knock control, ignition signal, boost control etc. and then call function n. Then the program just sits and waits for the next trigger event, and next time it does all the same stuff but calls function n+1 at the end.

There's no way to call functions indirectly via a variable - you can only pass literal values to the call instruction. But the ret instruction works like an indirect function call, because it always pops the stack into the program counter, and the stack is just a pair of RAM locations that can be manipulated like variables.

The list of functions is at 0x800, and the call targets are relative to mb1, so the first one "call 020F" actually calls 0xA0F (throttle angle routine).

I'll have to revise the comments when I get time, I might not have made it very clear, but that's definitely what's happening here.

andyb wrote: Wed Mar 04, 2026 1:39 am

whalenlg wrote: Tue Mar 03, 2026 10:40 pm I can't understand why it's doing the sel mb1 here. All other pairs of mb1/mb0 make sense for jumping/calling the other ROM section, but this just sets mb1 and returns. It leads to a later call that should be address 325, but ends up going to a bogus B25 location.

I haven't understood that section yet either. I just ran my simulator and put a breakpoint at 0x2a3. Here's how it got there:

1. Quickly after reset we go to 0x77 and then execute a load of code up to 0x1a3
2. 0x1a3 call $0336
3. Run a load of code until we get to 0x352
4. 0x352 ret
5. That ret jumps us to 0x2a3

Then if we keep stepping, we do the sel mb1 and and ret at 0x2b0. That ret jumps us to 0x80e leads to 0x812 which is a jump-to-self.

I still don't understand what the purpose is. I can't afford to spend a day thinking about it now because my employer has found me something to do. I'll be back as soon as I've figured out how to make a Raspberry Pi Pico work as a 5.1 channel USB sound card.

Thanks Andy - I see the same thing, but my #5 return goes to 008e for some reason. I'll study John's reply and see what's going on with the stack before and after.

I've gone back to my DME simulator work and it looks functional at 825RPM.

Does anyone know what a "reasonable" injector pulse width is at that RPM (or in fact ANY RPM!).

Also - should I be seeing 1 or 2 injector pulses per rotation (ie per ref sensor pulse)?
I see 2 Ignition pulses which I think is correct.

Thanks!

whalenlg wrote: Mon Mar 16, 2026 11:17 pm I've gone back to my DME simulator work and it looks functional at 825RPM.

Does anyone know what a "reasonable" injector pulse width is at that RPM (or in fact ANY RPM!).

Also - should I be seeing 1 or 2 injector pulses per rotation (ie per ref sensor pulse)?
I see 2 Ignition pulses which I think is correct.

Thanks!

I show an example at the end of this: https://jhnbyrn.github.io/951-KLR-PAGES ... rough.html. It comes out to around 1.9ms for a warmed up 840rpm idle.

There are 2 injector pulses per rotation, fired just after the spark. Of course since all 4 injectors are fired at once, that means that each pulse only injects half of the fuel for each cylinder.

Hi John - still scratching my head on this. Here's what I got from frwilk (via wayback machine):
https://web.archive.org/web/20131210020 ... firing.htm
All 4 fuel injectors fire at one time.
They fire once every crank rotation.
They fire twice every cam rotation.

My simulation is still at 1 fire per crank. Thoughts?

whalenlg wrote: Thu Mar 19, 2026 2:27 pm Hi John - still scratching my head on this. Here's what I got from frwilk (via wayback machine):
https://web.archive.org/web/20131210020 ... firing.htm
All 4 fuel injectors fire at one time.
They fire once every crank rotation.
They fire twice every cam rotation.

My simulation is still at 1 fire per crank. Thoughts?

My mistake, it's once per crank rotation, sorry! I actually have a scope trace of it at the end of this: https://jhnbyrn.github.io/951-KLR-PAGES ... dware.html

johnb wrote: Thu Mar 19, 2026 3:10 pm

whalenlg wrote: Thu Mar 19, 2026 2:27 pm Hi John - still scratching my head on this. Here's what I got from frwilk (via wayback machine):
https://web.archive.org/web/20131210020 ... firing.htm
All 4 fuel injectors fire at one time.
They fire once every crank rotation.
They fire twice every cam rotation.

My simulation is still at 1 fire per crank. Thoughts?

My mistake, it's once per crank rotation, sorry! I actually have a scope trace of it at the end of this: https://jhnbyrn.github.io/951-KLR-PAGES ... dware.html

That's the primarily reason I'd try a stand-alone, to get a smoother/cleaner running engine with sequential injection -- but for California's ironic smog law that prevents it. Any idea where in the cycle the injectors fire? No matter where, seems like one cylinder is always going to get older less atomized fuel than the other. I wonder if that contributes to wear patterns over time or even #2 bearing failures, somehow...

Tom wrote: Fri Mar 20, 2026 7:41 am

johnb wrote: Thu Mar 19, 2026 3:10 pm

whalenlg wrote: Thu Mar 19, 2026 2:27 pm Hi John - still scratching my head on this. Here's what I got from frwilk (via wayback machine):
https://web.archive.org/web/20131210020 ... firing.htm
All 4 fuel injectors fire at one time.
They fire once every crank rotation.
They fire twice every cam rotation.

My simulation is still at 1 fire per crank. Thoughts?

My mistake, it's once per crank rotation, sorry! I actually have a scope trace of it at the end of this: https://jhnbyrn.github.io/951-KLR-PAGES ... dware.html

... Any idea where in the cycle the injectors fire? ...

Yeah just after the second ignition event - here's the image I mentioned in my last post:


The green trace is the digitized reference sensor pulse (falling edge). Blue is the ignition events and red is the injector pulse.