Nate S2 said "There are maps that relate to battery voltage, again not sure what this does" My bet it is injection time compensation for injectors due to battery voltage change. Does the table the code references look something like this: $FF $FF $FF $FF $FF $FF $80 $48 $32 $20 $15 $0C $05 $00 $00 $00 $00 if so, the code might return a value from the table, multiply by a constant and then add an offset and then finally add to the fuel value.
Good shout but wouldn't the injectors be pretty much voltage independent, as they're just solenoids? Thats the map, it might be a bit larger, but 5 bytes at most. I've not touched this for ages as life got in the way, but I think I derived the "volts" from comparisons that were done in code. That's also how I came to the assumption it was only used in startup as the voltages are so low
@digimatrix are you the same digimatrix from "thesamba" forum? If so you seem to know a lot more about this than me so feel free to let me know I'm wrong Interested in your work with getting RAM output from digi 1
All injectors response time changes with voltage so you have to compensate for it. For example Bosch M-9593-B302 30# injectors have a voltage compensation that looks like this: V Bat Voltage Offset (volts) (ms) 6 3.253 8 1.669 10 1.057 11 0.872 12 0.730 13 0.627 14 0.519 15 0.441 As you can see, it is a significant change as voltage changes. Yes I am the same guy on the Samba forum. Working on adding cylinder selective knock control to the Vanagon ECU right now for a 2.5L engine I'm building for the Van that will have 10:1 compression. May not need it, but I'd rather be safe than sorry.
Thank you! I'll have another look at the tables tonight and see if I can find anything. Didn't expect the change to be that drastic, although I suppose it does tighten up a little over the "normal" operating range. I've not touched this for a while to be honest but I hope to get back into it, spent a while trying to contact "set" "setGti" who was an Australian guy who disassembled Digi 2 10+ years ago. Managed to find he's still active on a pro-audio forum but seemingly doesn't want anything to do with VW or cars anymore. Do you a link to your thread, would be interested to have a read Apologies for my naivety but what does that ECU roughly translate to in the Europe/UK world? Is it similar to Digi 1 or Digi 2? Or is like Digijet?
Had a couple of hours on this tonight, aiming to disassemble and re-assemble the entire code, and have the ECU still work. I'm using Ghidra for my disassembly as mentioned and while powerful (and free!) it does has some shortfalls compared to IDA. The main issue for me is when I try to export an assembly file it has a huge amount of additional info added it/changed by Ghidra so there is no chance of it being re-assembled. I also have a Python dissembler which is very good, but still uses the wrong syntax in places. I have the Python source so it should hopefully be a pretty simple task to change it to give an output that will work with ASM48.
Two successes, modified the python disassembler to have an output suitable for use with ASM48. So now I can take a bin file from the EEPROM, disassemble it, re-assemble it, paste the data areas back in and I get this magical message I'm going to write another script that will do this for me, saves about 10 minutes of faffing copying the data across. Next step is to change something in the code and check it still runs correctly on the ECU. I'm thinking probably make the fuel pump prime for longer, or not switch off, just as a test. I also had another look at the assembly itself. Managed to answer some questions and raise more. I was approaching it the wrong was simply thing the values in the table were directly and the ECU just accessed each address depending on its sensor inputs, and then interpolated elsewhere. This lead me down a path which meant I could only ever have a table that was 6 bytes long (for a sensible range of temperatures). This was obviously wrong. When looking at the code where the ECU access the tables, there were always a couple that confused me, shown below. I dubbed this one "RegCleanup" because its just zeroing things, buts its called every time an ECT table is reset Then there's this function that's called after the above, and after reading the table value into A. After actually thinking about this, R2 and R3 form a 16-bit number that is initially 0. The ECT ADC is used to address the first table location and that is added to the R2:R3 number. 1 is then added to the ADC number and the code runs again, adding the new table value (if there is one) to R2:R3. This code runs 16 times. After all that, this runs Ghidra has added too many functions here, its actually just one. If you put any 16-bit number into R2:R3 and work this through, its basically saying +8 to that number, then divide by 16. There is also checking to ensure there is no overflow. Combine that with what is written above and you have linear interpolation! This would be far easier if the CPU had hardware divide. So in principle what this does is that if your ECT is just at the very bottom of one of the table locations, that location will be added to itself 16 times, then divided by 16, effectively leaving you with the table value again (+8 is in there still). But, if your ECT was halfway between two table values, it would add 8 of the lower value, and then add 8 of the upper one, averaging in the middle. Knowing all this, and having a graph from VW about the temperature to resistance values you can get... There are lots of these maps, and they overlap somewhat, so I'm now working on how the ECU selects which map to look at. The extreme temperatures are theoretically accessible, but with the sensor either shorted or unplugged
I realise this probably isn't normal ClubGTi content but I can't think of anywhere more relevant to put it Not many people in the electronics community are interested in a late 70's processor anymore unfortunately, especially one that was mainly used in Keyboards and such, not the most intriguing device
It absolutely is the sort of content we appreciate here. These are the building blocks to the processing power seen in the latest Bosch MG and Simos 19 ECUs, found in modern GTI/R cars
Nothing useful to add except I echo Toyotec completely. There's still a huge amount of Digis out there!
Thanks both! In some ways I find these more impressive and interesting than modern ECU's. Today, the ECU's are obviously at lot more complex, but the processors are far more powerful and, in many ways, far easier to develop for. But the fact the Digifant engineers managed to get a fully working engine management system, with such a limited and old processor and tools, old even at the time, blows my mind. Some incredibly intelligent people worked on it and I think it’s interesting to see how hard it was for them to do things that take 2 lines of code and no effort today
Compared to carburettors, points and condensers, Digifant AFM or D tronic was game changer for torque and response consistency, even over K Jet, with the option to include closed loop control for markets that required a 3 way catalyst. Compared to today, it is crude and many SEMS offer more content and refinement for the combustion engine. Regardless. When I chipped tuned the few Digifant 2 cars, it was not a lot ot play with from the calibration and the fuel side, but better than just shifting the dizzy or tweaking the AFM spring. Wished I could command the ignition side. So good you are revisiting it from the programming side and using a disassembly to define the actual maps I could not see I the time. So yes I am happy for the effort.
When you were tuning them did you just have access to the fuel table? Its quite hard to find out what people used to change when these were more current
Thanks all, and will do! Hopefully as I piece more bits together it should get easier. Going to have a play with writing my own function at the end of memory, and accessing the spare AC pin to hopefully add some more functionality. Maybe switching between the fuel maps on the fly or something like that, just to test that I can write 8048 assembly correctly
Having a browse of some forums and I found this thread from a while ago https://www.clubgti.com/forums/inde...gi-blitz-chips-may-not-work-sometimes.150219/ by @wcrado. Does anyone else have any experience with these "Digifant" chips, @rubjonny did you ever get them? I'm interested in the "second chip" really as and its ability to convert a "single letter ECU into a tuneable 2 letter ECU". I know his chips claim to be able to adjust timing, which is very cool if that's possible, but from my research so far I cannot see how it is, especially with only changing a single chip
man that was a while ago I recall buying a cheapy chip and also imported one from the guy mentioned in that thread, but dont recall them making a massive difference? can see by my post here dated from before the thread above that I found a stock ecu worked better than the chipped one I had https://www.clubgti.com/forums/inde...-the-end-of-an-era.136370/page-2#post-1293910 there is this thread where I claim the dual chip work well mind, so who knows https://www.clubgti.com/forums/index.php?threads/remapping-an-8v-2-0-conversion.189562
Ahh interesting read, cheers! vw_pilot seems to have dropped off the face of the earth, think he was banned from vortex? or at least lots of post are removed. Mystery lost to time I've just confirmed there is no way the main "easy to chip" processor could talk to the timing controller. So no idea what the difference between "single letter" and "double letter" ECU's actually is. Less aggressive knock control or something maybe? no idea
was a tidbit in there that early ecu have the map spread across 2 chips, which is potentially why just doing one on these causes it to mess up and you need a 'double chip special' on those. but yeah, you'll know more than most