dirty, old and rusty: a tale of a $600 meatball

[Swedbrick]

Awesome, thanks for the explanation, so you read out the memory of the processor and cut all you didn't need?

I was thinking of building my own data logger by exploiting the Bosch protocol mentioned on the wiki, but the bit format was a bit confusing. I was also thinking of maybe making some board to replace the white level translator somehow (two birds one stone)

 

[esmth]

I was originally dumping all the iram but I ran into a pseudo rev limiter at like 4000 ish rpm because it was too slow. I only go for 24+1 bytes for the checksum now and I haven't hit any issues tested now to 7100 RPM.

About the white hybrid, have you figured out what Pin 1 is used for? On my lh3.1 it seems to always output ~3.9v which goes to the ADC pin of the mcu, which is used as a multiplier of sorts for the maf translation logic inside the code. I cannot for the life of me figure out the point/reasoning for it. I am actually maxxing out the maf translation map past ~6700 ish RPM, and this multiplier actually puts me over the edge so I hardcoded it to a lesser multiplier. But I don't understand it

 

[bobxyz]

Cool project!

An 8051 is really slow at doing realtime multiplies with any sort of precision, and realtime divides are pretty much unusable. For a MAF based system, the MAF automatically compensates the Mass measurement for the air density, aka air temperature. The hybrid and/or code still needs to compensate for the engine temperature as it changes fuel volatility. Acceleration also needs enrichment somewhere.

There would need to be multipliers for:
- cranking enrichment based on coolant temperature
- warmup or after-start enrichment based on coolant temperature
- acceleration enrichment based on coolant temperature

Maybe pin 1 is related to one of these?

 

[Swedbrick]

About the white hybrid, have you figured out what Pin 1 is used for? On my lh3.1 it seems to always output ~3.9v which goes to the ADC pin of the mcu, which is used as a multiplier of sorts for the maf translation logic inside the code.

I still have a spare ecu I want to draw up in kicad after reverse engineering, but time is at a premium these days I contacted this company a year or so ago, but he refused to help: http://home.kpn.nl/mirjam_paul/928_lh_repair.html

Maybe getting a 928 ecu and getting it fixed is the quickest way to get some idea of what the hybrid is doing

 

[esmth]

Maybe pin 1 is related to one of these?

I have been logging the output of this pin for months and it is always at 3.9v under all my conditions. Or 195 out of 256 in the ADC pin an6. I haven't found/seen anything that changes the value at all. I show it in the bottom yellow graph I posted on the previous page, the yellow line that is straight across the page, never moving. It pretty much is a direct offset of the maf linearizer map access cell.

The access pattern is airflow_result = maf_linearization_map[ 0xC3 + ( 0xC3 * (( 0xC9 - 128 ) / 256 )) ]
where:
0xC3 is the MAF ADC input
0xC9 is the ~3.9v signal from hybrid ADC input

So like the stock value of 0xC9 (195 aka 3.9volts) effectively is a 1.25 multiplier on the 0xC3 (MAF ADC) result before being run into the MAF translation map. why, bosch, why. If you notice, it could also subtract an offset from the translation map with values of 0xC9 below 128.

note this is for LH3.1 (-572 box) and I haven't confirmed anything to be the same or similar on any 2.4 boxes.

I still have a spare ecu I want to draw up in kicad after reverse engineering, but time is at a premium these days I contacted this company a year or so ago, but he refused to help: http://home.kpn.nl/mirjam_paul/928_lh_repair.html

Maybe getting a 928 ecu and getting it fixed is the quickest way to get some idea of what the hybrid is doing

I hate how everything automotive is surrounded in secrecy, it almost seems like anyone who figures anything out inevitably goes dark Though I guess I am also a hypocrite because I have published nothing. I do have a partially labeled pinout of the hybrid ic and of the bosch 30047 ic.

 

[bobxyz]

I'd forgotten about this, but there was a relevant thread a few years ago:
https://www.turbobricks.com/forums/showthread.php?t=345641
(I never saw a followup from ipdown, and I haven't seem here on here recently)

This link would be good to print off before it disappears:
http://www.digital-kaos.co.uk/forums/showthread.php/111931-24c02-location-MA3-1

You might also try reverse engineering a LH2.2 box -- it's all discrete components on a single-sided PCB, but there are a bunch of small transistors on it, and some mystery analog chips with undecipherable bosch numbers.

--------------------

Edit: I think I know what pin 1 is, and shortly thereafter I found a Porsche LH2.3 ECU schematic in my piles of stuff.

The LH2.2 AMM includes a pot to adjust the idle mixture and an extra pin (6) on the AMM connector. I think that the pot is simply a variable resistor between the extra wire and ground -- it does nothing directly to the circuits in the AMM. Instead, the ECU makes a voltage divider and does an ADC conversion on the pot voltage to adjust the fueling up and down for idle. Even though the LH2.4 AMM doesn't have the pot and extra wire, it looks like LH2.4 ECU pin 23 is "CO2 adjusting potentiometer from AMM or unconnected."

Google "lh2.2 amm pot adjustment" for additional info. Would this match your observations?

You can find the Porsche LH2.3 [???] schematic, with the hybrid pins labeled, at:
http://www.928s4.com/lh/lh_homepage.htm

Edit2: Well, I tried the amm adjust on the bench, and everything else I could twiddle, but the pin 1 hybrid voltage stayed flatline at ~3.8volts. Looking at the LH2.3 schematics, the MAF stuff doesn't even go through the hybrid.

Maybe it's knock enrichment from the EZK (or Turbo+)?

 

[Swedbrick]

Alright, update the original thread with recent updates, to see if I can lure out ipdown, and to save this thread from going into the reverse engineering too deep

 

[esmth]

You might also try reverse engineering a LH2.2 box -- it's all discrete components on a single-sided PCB, but there are a bunch of small transistors on it, and some mystery analog chips with undecipherable bosch numbers.

I did look a little at a 544 box as well in the past. But the code on lh22 is significantly harder to read for me because the ADC and timer chips are discreet and I don't know where in the address space they are. Plus a bunch of weird boundary jumps/bank switches that make my head spin. Also not having a car running on one makes it harder, too

I'll reply to the hybrid stuff in the other thread.

 

[esmth]

the ultimate downgrade?

I swapped the car from LH3.1 (572 box) to LH2.2 (with a 554 box), but kept the EZ116K. I also kept the variable LH3.1 TPS and throttle body and created a circuit with a dual comparator and potentiometers to translate the throttle sensor voltage thresholds to the idle and wot wire signals. The idle output goes to both the lh2.2 box on pin 3 and the ez116k on pin 7. The wot wire goes to pin 12 of the LH2.2 box. It works on the LH side, the ecu correctly idles/coast-downs and enters decel fuel cutoff. On the ezk side it seems to not work for some reason. It never enters the idle timing mode and I don't get the hella fresh high rpm decel popcorn. I think i need pull ups on comparator outputs.

I had two 0 280 212 007 LH2.2 mafs on the shelf I needed to test. I wired one into my test battery and it immediately released a small amount of the magic smoke, but after that it seemed to work ok on the bench. The other seemed to work normally. Funnily enough, the one that did release the smoke works in the car well. The other wont even start the car. Both read about 1.27-1.3 volts with ignition on, engine off/stalled. I haven't yet investigated further but have ordered another used one.

I have a 0 280 140 501 LH2.2 idle valve which was pretty well locked up. The valve wouldn't even twitch with power supplied. I switched between filling it with carb cleaner and pbblaster and got a screwdriver in there and was able to work the valve loose. With about an hour of fiddling with it I got it to actuate fully and freely when supplying the power to the open and close pins. I then put a couple drops of engine oil in to lube it up.
<video width="560" height="315" src="https://esmth.com/f/221212/IMG_4134.mp4" controls preload="none"></video> (click play to load)

I didn't have the correct idle hoses for this style of valve so this is what I came up with on the spot. Yes that is heater hose. no, it doesn't leak or collapse shut. (yet.) Ignore the wiring, I will sheath it when I can confirm it is correct/reliable. Or I wont. Fight me about it


The load pulse signal from the new LH2.2 box to EZK was a little askew from what it wanted to be with the previous LH 3.1 setup. This caused at wide open throttle/full load to pull from the about 75% load area from the EZK map... too much timing. I fixed that and you can see the difference in the pulse length to load row. IME the stock load pulse translation maps are trash anyway. or my car is trash and the maps are ok. idk it could be either.
Old LH3.1 load translation map on:

New LH2.2 load translation map. It almost seems shifted/compressed vs the 2.4/3.1 signal:


Also I am still running the larger injectors (259cc ev14 4 holes from a ford mod motor) but the 2.2 ecu seemed to be able to find closed loop well enough. It is pig rich when cold though, will need to look into the bin and see if we can find any injector/fueling constants. Need to hook up the wideband to see how much fuel I am getting at WOT.

Oh I also got more of the idiot lights to work at key-on. Still need to get the OD/upshift light and the ABS light to work.


Some pix of my adapter harness connection.


This first video was just after the first start. The second was the first real "cold start" this morning at 24 degrees.
<video width="560" height="315" src="https://esmth.com/f/221212/IMG_4148.mp4" controls preload="none"></video> <video width="560" height="315" src="https://esmth.com/f/221212/IMG_4156.mp4" controls preload="none"></video>

And last, with the cold and winter gasoline and all, I have been averaging a little over 26mpg. Maybe 26.5. I wonder how 2.2 will change this, I guess i'll find out.

 

[bobxyz]

You shouldn't need external pullups since they should already exist inside the ECU/EZK (the original TPS was just 2 switches). I'd add a small cap to the TPS wiper signal so it doesn't move if the wiper chatters a bit (0.1uf or 1uf are fine). And your WOT schematic pins are backwards - I assume you fixed this in your wiring already.

I don't know what voltage level is needed for Idle/WOT into the ECU - have you probed it at the CPU chip to make sure the LM393 is driving low enough? (If it isn't, you could remove the LED to see if that helps.)

Is that a Yoshifab DSM CAS adapter hiding under all those extra hoses? Are you thinking of eventually going megasquirt, or similar?

 

[esmth]

I actually have the EZK idle problem reversed from what I stated, whoops! I think the lm393 can't pull the idle line of the EZ116K down far enough. I saw it had an open collector output and hail Mary'd it hoping it'd work connected straight to the input of the idle lines. In the non-idle state It correctly has the external idle input pin high ~4.8 volts but low (idle active) seems it can pull it down to 0.3ish volts. I am not sure if this is enough. I should measure it at the mcu pin like you say.

Thx for the tip on the capacitor on the wiper. I did notice when I had the throttle right at the threshold set by the pot the LED would flicker and maybe this would rectify that. I also should put a small cap across vcc/gnd of the lm393 just in case. and maybe a larger one in parallel on the input of the 7805.

I encountered the schematic WOT comparator issue you mention when I originally made the circuit on the perf board, and I think what is on the schematic is correct. The idle comparator needs a low threshold to set the idle out signal low, while the WOT comparator needs a high threshold to set the WOT out signal low. The input threshold logic is reversed between the two If that makes sense. This confused the hell out of me for hours.

About the CAS adapter, a couple months ago I ran it and the hyundai cas to an AVR chip and tried to write a decoder/translater to 60-2 for the ezk. I originally did this because I had ordered the wrong ttv flywheel and it did not have the 60-2 holes. I ended up just buying the correct flywheel instead and not cobbling more of the car with my shoddy electronics. I did actually get it to run the car though, with the stock low resolution trigger wheel and all, which I know wouldn't be optimal.

I do keep having a craving for trying something like megasquirt or more likely speeduino. Maybe I will at some point but I enjoy messing with/figuring out the stock computers for now.

#########################

The AMM I am currently running had the tamper deterrent plug pressed in the way of the CO adjust screw. It turns out this is designed really well and is very hard for a shade tree mechanic like me to actually get access to it. I tried to drill it but there is a ball bearing or some chunk of really hard metal in the middle my drill couldn't get through. I eventually just grabbed the whole surrounding plastic tube thing and broke it off with suggestion from people on the discord.



I'm thinking about just having an external pot inside the cabin instead.

#########################

Last night when I was leaving work, the car started fine. I adjusted the throttle screw for the idle a little bit and added a little LED to the pin 22 lambda test point to calibrate the AMM screw. I fiddled with that then decided it was good enough and went to leave. I had just barely made it out of the business complex onto the main road when the car suddenly died. I tried cranking it obviously but it was really dead and didn't even sputter. I got out and pushed it halfway into the ditch to get out of the road and inspect the wiring. I changed nothing and just let it sit for maybe 10 minutes and then it started fine again where I turned around and went back into my parking lot and it suddenly died again. I noticed this time the fuel or sys side of the main relay would spazz right before/as it happened. Cranking it, it wouldn't start again. I looked at the lh2.2 and lh2.4 schematics on Barton's site (https://www.prancingmoose.com/volvoharnesses.html) and noticed on lh2.2, all the high current/high interference things are supposed to be attached to the fuel pump side of the relay instead of the system side as on lh2.4. I swapped the injectors, coil power, iac power screw terminals to the fuel pump relay part of the terminal strip and the car started and I made it home the long way without a single complaint. This also solved a very rare/intermittent stumble the car had with the 2.2. I guess the box is just much more sensitive to interference than 2.4/3.1.

Another problem I realized I had was at full decel, the load pulse from the LH2.2 box is small enough to trigger the "load pulse too small" fault in the EZ116K where it will give you the full load/limp mode timing instead. NOP-ing two bytes in the interrupt handler fixed that

 

[esmth]

For posterity I am running bosch 0280158089 ev14 injectors from a ford mod motor, 4 hole, conical spray, 259cc@3bar.

I added an obnoxious blue led to the lambda test point "A" (pin 22) using this but with a 1k resistor. It is wayyyy too bright.

At first the lambda test point acted really strangely and didn't seem to correlate with what the wideband was reporting. Even with the way too large for NA injectors, the 554 box would find stoic and do the switch/sway thing around it. But the lambda test point (pin 22) would always remain lit, which would indicate rich as expected, but even as the box was commanding the switching around stoic.

To try to fix this, I first tried to bindiff different turbo vs NA lh2.2 bin files to try to find altered injector or fueling constants but that didn't lead me anywhere valuable. I then noticed the main large fuel or amm? maps were almost exactly proportional to the injector sizes paired with the boxes. (Meaning the turbo box with ~300cc injectors had numbers 0.7 times the NA box with ~200cc injectors.) I made a google sheets spreadsheet to compare, calculate, and back-calculate the weird 10 bit fuel maps so I could quickly proportionally alter the entire thing to make the fueling with my injectors work as expected.

https://docs.google.com/spreadsheets/d/1ILxCNXSj_Zz4HHUd2cQDyPZ8hLwUs5F1Q3CnH93ZMVU/edit?usp=sharing

I first tried to multiply the entire AMM map by 0.8 because 0.8*259cc is 207cc which is close to the stock injectors. I burned that chip and the test point LED now always was off, indicating being lean, but still the box would still find stoic and switch around 1.0 lambda as indicated by the wideband.

This morning I made a new map by multiplying the stock one by 0.88 which seemed really close on my drive this morning. This map made the lambda test point blink at idle (after an AMM screw diddling) and during cruise. Then at wide open throttle it would drop to 0.89ish lambda or 13.1 AFR so I think I am good there for now.

Stock 554 AMM map vs mine scaled for injectors:

Then this is what the modified map looks like inside tunerpro:

And a clip of the test point LED happily switching away at cruise:
<video width="560" height="315" src="https://esmth.com/f/221214/IMG_4178.mp4" controls preload="none"></video>

 

[bobxyz]

I'm not sure how to go about adjusting the AMM pot while also adjusting the injector tables. I think the AMM pot (?1K to ground, 15 turn, ~380ohms default setting?) is used mostly for warmup and idle fueling, but I'm not sure.

You might try disconnecting the O2 sensor after it's warmed up, and then adjust the WB02 to ~14.3 at idle using the pot. This should give you a slightly rich open-loop AFR.

On other stuff, I checked my notes and the LH2.4 ECU+EZK combined have the equivalent of a ~2K pullup to +12v on the Idle and WOT TPS pins. I'd think a LM393 could pull this down far enough to be seen at the CPU.

When the TPS is right at the Idle or WOT threshold, it's very noise sensitive and will flicker the signal. Since the original TPS uses switches that bounce when open/closed, I think you'll be OK with the extra flicker. To properly fix it, you need to add a little hysteresis to the comparator circuit - see: Old TI App Note

And I'm impressed that you were able to convert the stock DSM CAS disk signals into a 60-2 signal and get it to run at all. That's a difficult problem to do accurately and right. If you like 8051 reverse engineering and figuring out how unknown code works, there's a huge lack of talent in the infosec space, and some good extra $$$ if you're really talented.

 

[esmth]

I'm not sure how to go about adjusting the AMM pot while also adjusting the injector tables. I think the AMM pot (?1K to ground, 15 turn, ~380ohms default setting?) is used mostly for warmup and idle fueling, but I'm not sure.

You might try disconnecting the O2 sensor after it's warmed up, and then adjust the WB02 to ~14.3 at idle using the pot. This should give you a slightly rich open-loop AFR.

Messing around with the AMM pot, it looks like it is really only used at very low airflow and tapers very fast in effectiveness as the airflow goes up. Though I haven't tried disconnecting the O2 sensor, that might give a better incite about what it does without the closed loop mucking it up. I have also realized the 'speed' at which the o2 switches increases a ton above idle so that could be what I was seeing.

On other stuff, I checked my notes and the LH2.4 ECU+EZK combined have the equivalent of a ~2K pullup to +12v on the Idle and WOT TPS pins. I'd think a LM393 could pull this down far enough to be seen at the CPU.

When the TPS is right at the Idle or WOT threshold, it's very noise sensitive and will flicker the signal. Since the original TPS uses switches that bounce when open/closed, I think you'll be OK with the extra flicker. To properly fix it, you need to add a little hysteresis to the comparator circuit - see: Old TI App Note

YEah neither computer seems bothered by it really, just something i noticed even before I installed the device. That hysteresis circuit is surprisingly simple and effective, thx again for the info. I am an analog circuits novice.

And I'm impressed that you were able to convert the stock DSM CAS disk signals into a 60-2 signal and get it to run at all. That's a difficult problem to do accurately and right. If you like 8051 reverse engineering and figuring out how unknown code works, there's a huge lack of talent in the infosec space, and some good extra $$$ if you're really talented.

To be fair I think the "accurately and right" bar is the one I didn't quite make. There were a couple ways I cheated, one being injecting the signal post VR conditioning circuit, and also only doing the math for the falling edge timing, as that is the edge the ezk mcu looked for. The stock hyundai dsm cas trigger wheel has a couple of key timing edge combinations which make it extremely easy to write a decoder for, I think I looked for the falling edge of the cam trigger while the crank trigger is high would only happen once in 720 degree. Then use the previous and current 180degree crank trigger falling edge to calculate rpm, divide by 60 (to account for both rising and falling edges), and load that time into a timer output compare unit to toggle an output pin on a match. (while also counting match's and at the right number, disable the output for 2 times for the 60-2 missing holes.) This had the problem of large changes in engine speed would clip the last few edges cauing the ezk to lose sync. The next step would be some way to somehow blend the output compare value between the current speed and last speed and somehow have this occur between the cas crank triggers. It gets really hairy to do correctly.

another reason i scrapped the project is getting the cas or the rebuild parts for it seem to be getting sparse and prohibitively expensive. I realized a replacement CAS would be 60% the cost of just using the correct flywheel anyway. Plus the fact that no "big name" manufacturers actually make the part or the wheels (that I wanted to use) anymore.

I do have already have a job in embedded systems but nothing in RE, really. I also feel non MMU systems like our fuel injection are completely different animals to RE vs more modern stuff but I guess I haven't tried hard enough, or even looked into it

 

[esmth]

Here's my shadetree lh2.2 tuning kit I used a 0-2.5k ohm pot to replace the one built into the 007 AMM. It is connected between pin 14 on the Lh2.2 box and a signal ground point. Unfortunately the low end ohm-wise of this pot is extremely touchy and I think it might be inducing noise into the input to the ecu when I move it because the test point goes absolutely haywire when I adjust it.


The bar LED thing on the right in the above pic is connected to the narrow O2 sensor input with the ECU. I made a lm3914 based circuit (the DIP is crammed between the legs of the LED bar. ) I wanted to be able to see both the LH2.2 lambda test point LED output along with what the O2 sensor is actually reporting. It seemed to me with a slow multi-meter that the test point is not directly attached with the O2 processing circuit like the lore suggests. And I will use this to confirm my suspicions.


I took this video of the LED light show party (feat. differential whine) the other day. I like how you can see the acceleration enrichment in closed loop when I mash the throttle, and see it then enter open loop at about 3200 RPM. Then both lights go out in decel fuel cutoff. (The yellow bar is the narrowband O2 output voltage and blue is the lambda test point in case it isn't clear.)
<video width="315" height="560" src="https://esmth.com/f/221217/IMG_4186.mp4" controls preload="none"></video>


And here is a video in neutral/idle. (feat. m46 gear rollover noise) You can quite clearly see here how the test point is not directly an output of the O2, but there is some logic between the two.
<video width="560" height="315" src="https://esmth.com/f/221217/IMG_4191.mp4" controls preload="none"></video>

I also created a DIP28 to DIP24 adapter socket to be able to use my ostrich and my stash of 27c256 eproms I already have instead of the comparatively scarce 2732As. One change I would make instead of tieing the unused address pins to VCC, is to tie them to GND instead as setting up an XDF in tunerpro with the correct bin offset to upload and trace this was hell. Using the mentioned ostrich trace feature, I was able to confirm that in the fuel/AMM maps I edited and posted above, the X axis is RPM and the Y axis is AMM derived load.

 

[esmth]

I did some sleuthing in the LH2.2 code and figured out the reasoning behind the pin 22 lambda test point behavior. It is actually the 'sign' bit of the 16 bit short term fuel trim. It isn't connected directly to the O2 circuit.

        mov     r1,#3ah         ; 00f2 - b9 3a  9:
        mov     a,@r1           ; 00f4 - f1     q                                                     
        rlc     a               ; 00f5 - f7     w
; restore p2 from 0x16
        mov     r1,#16h         ; 00f6 - b9 16  9.

...

; restore p1 from 0x17, also toggle p1.7 for lambda
        inc     r1              ; 00fe - 19     .
        mov     a,@r1           ; 00ff - f1     q
        orl     a,#0feh         ; 0100 - 43 fe  C~
        jnc     skip            ; 0102 - e6 06  f.
        anl     a,#7fh          ; 0104 - 53 7f  S.
skip:   outl    p1,a            ; 0106 - 39     9

Basically the if the high bit (bit 15) of data at 0x3a and 0x3b (the address of 16bit data of short term fuel trim) is set, that sets the 'carry' bit in the status register, which then clears bit 7 of port 1 (p1.7) which is connected to the base of a transistor with the collector fed to the external pin 22 of the box.

Ergo if the short term fuel trim is less than the center point (0x8000), the carry is unset, which puts the output pin high, which turns on the transistor and lights the LED. Else if stft is greater than or equal to 0x8000, it turns off the transistor and the LED. neat.

 

[bobxyz]

^^^ Nice detective work, and that makes that LH2.2 test pin pretty nice compared to looking at a sweeping noisy O2 sensor voltage.

"One change I would make instead of tieing the unused address pins to VCC, is to tie them to GND instead as setting up an XDF in tunerpro with the correct bin offset to upload and trace this was hell."

You could just save 4 copies of the program to the PROM. When you load the .bin file into your PROM programmer, you can specify an offset. If you load your .bin to 0x0000, 0x1000, 0x2000, and 0x3000, it will work regardless of what the upper 2 addr bits are jumpered to. You could also use a PC utility program like HxD.exe to pack the 4 images together into a single programming .bin file.

Even better, add pullup resistors (10K, or so, to +5v) and switches to ground on the upper 2 addr bits. You can then load 4 different .bins, and select which one is used with the switches.

 

[esmth]

You could just save 4 copies of the program to the PROM. When you load the .bin file into your PROM programmer, you can specify an offset. If you load your .bin to 0x0000, 0x1000, 0x2000, and 0x3000, it will work regardless of what the upper 2 addr bits are jumpered to. You could also use a PC utility program like HxD.exe to pack the 4 images together into a single programming .bin file.

Even better, add pullup resistors (10K, or so, to +5v) and switches to ground on the upper 2 addr bits. You can then load 4 different .bins, and select which one is used with the switches.

This is pretty much what I am doing now RE the stacking the bins. It does work well when using actual eprom chips. I was trying to avoid it because when using the ostrich, the "Base Offset" in tunerpro comes into effect where the bin needs to be positioned in the right offset in the address window (for lack of better words) in the emulator AND the same offset in the bin file for the trace/auto upload to work. I'm not sure why there can't be a "Bin/File offset" separate from "base (loader) offset" So I can continue using normal (non stacked) bins, but upload/flash eproms to the right bank when I do that.

I made this little adapter the other day hoping just tying address pins A15, A14, A13, A12 to GND while moving the VCC pin over two pins for the 24-28 adapter. The car doesn't run nor the relays click with this. What I didn't think about is the ostrich either emulates a 4mbit window or 8 banks of 512kbit which I cannot figure out how to set something up so the bin file, the eprom, and load address into the ostrich starts at 0x0000 and ends at 0x1000. I want this because it is just easier to read the disassebly/hex dump and directly add maps/constants of interest into the xdf without thinking about the offsets. Especially on the side of the road.



I feel like I am overcomplicating this.

(Edit, I accidentally hit submit before I finished the poast.)

https://web.archive.org/web/20190315230422/http://support.moates.net/ostrich-20-overview/ at the section "About Emulation Bank Setting" I have it set at Bank0 / 28 pin

https://web.archive.org/web/20201128155757/http://support.moates.net/data-trace-emulators/ at the section "What can go wrong with Trace? / Limitations" point 4. I think is the problem I am encountering.

It is a shame Moates decided not to keep their product info/support site up.

 

[esmth]

edit: didnt mean to post, cant delete, edit again for content

I replaced the pulley and belt on my alternator drive as I think the overdrive pulley + revs are shredding the belt. The belt size is 15270 for posterity.



sneak peak for lh2.2 modification


I also made my spare LH2.2 boxes chippable. One thing to point out is you need 74HCT373 or 74LS373 chips for it to work correctly. I had originally gotten 74HC373 chips and they did not work at all, which was frustrating. I should have known, I have run into similar issues in the past with EZK modding. HC based chips do not work!

 

[esmth]

Took advantage of the unseasonably warm weather yesterday to install some teeth rattlers. I cleaned up the spare set of engine mount brackets I had on standby and installed the "soft" poly engine and trans mount from classicswede. when the car is moving the vibration is barely more perceptible than the old (clapped) diesel mounts, but at idle it is bad. I am going to take advantage of the vibrator mode and try to nip every interior rattle in the bud before I remove them. I am also hoping they "break in" a little bit but i'm not holding my breath.