Programmer commented on Riviera touchscreen video

Does anyone know this person?

1987 Buick Riviera - YouTube

• Most fun I ever had developing code. I wrote the editing program in 1984 and I'm told it allowed the users to create/update the screens from months down to weeks of effort. Funny thing, IBM came in like 1985 and convinced Delco that they wanted to put 8088 processors in the cars instead of the existing procs.. IBM never did deliver the editing software to replace my stuff, but mine was mothballed. That was the end of the displays in the cars. It was ahead of it's time!!!
  lzgmyn 9 months ago 4
  <button type="button" class="start comment-action-vote-up comment-action yt-uix-button yt-uix-button-default yt-uix-tooltip yt-uix-button-empty" title="Vote Up" data-action="vote-up" data-tooltip-show-delay="300" role="button" style="margin: 0px -2px 0px 0px; padding: 0px 4px; border-width: 1px; border-style: solid; border-color: rgb(204, 204, 204) rgb(204, 204, 204) rgb(170, 170, 170); background-image: -webkit-linear-gradient(top, rgb(250, 250, 250) 0px, rgb(220, 220, 220) 100%); background-color: rgb(224, 224, 224); font-weight: bold; height: 21px; outline: 0px; word-wrap: normal; vertical-align: middle; cursor: pointer; border-top-left-radius: 3px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 3px; text-shadow: rgb(255, 255, 255) 0px 1px 0px; -webkit-box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; color: rgb(85, 85, 85); "></button><button type="button" class="end comment-action-vote-down comment-action yt-uix-button yt-uix-button-default yt-uix-tooltip yt-uix-button-empty" title="Vote Down" data-action="vote-down" data-tooltip-show-delay="300" role="button" style="margin: 0px; padding: 0px 4px; border-width: 1px; border-style: solid; border-color: rgb(204, 204, 204) rgb(204, 204, 204) rgb(170, 170, 170); background-image: -webkit-linear-gradient(top, rgb(250, 250, 250) 0px, rgb(220, 220, 220) 100%); background-color: rgb(224, 224, 224); font-weight: bold; height: 21px; outline: 0px; word-wrap: normal; vertical-align: middle; cursor: pointer; border-top-left-radius: 0px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 0px; text-shadow: rgb(255, 255, 255) 0px 1px 0px; -webkit-box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; color: rgb(85, 85, 85); "></button><button type="button" class="start comment-action link-gplus-lightbox yt-uix-button yt-uix-button-default" data-action="reply" data-upsell="comment" role="button" style="margin: 0px -2px 0px 0px; padding: 0px 4px; border-width: 1px; border-style: solid; border-color: rgb(204, 204, 204) rgb(204, 204, 204) rgb(170, 170, 170); background-image: -webkit-linear-gradient(top, rgb(250, 250, 250) 0px, rgb(220, 220, 220) 100%); background-color: rgb(224, 224, 224); font-weight: bold; height: 21px; outline: 0px; word-wrap: normal; vertical-align: middle; cursor: pointer; border-top-left-radius: 3px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 3px; text-shadow: rgb(255, 255, 255) 0px 1px 0px; -webkit-box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; color: rgb(85, 85, 85); ">Reply</button><button type="button" class="end flip yt-uix-button yt-uix-button-default yt-uix-button-empty" data-button-has-sibling-menu="true" role="button" aria-pressed="false" aria-expanded="false" aria-haspopup="true" aria-activedescendant="" style="margin: 0px; padding: 0px 4px; border-width: 1px; border-style: solid; border-color: rgb(204, 204, 204) rgb(204, 204, 204) rgb(170, 170, 170); background-image: -webkit-linear-gradient(top, rgb(250, 250, 250) 0px, rgb(220, 220, 220) 100%); background-color: rgb(224, 224, 224); font-weight: bold; height: 21px; outline: 0px; word-wrap: normal; vertical-align: middle; cursor: pointer; border-top-left-radius: 0px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 0px; text-shadow: rgb(255, 255, 255) 0px 1px 0px; -webkit-box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; box-shadow: rgb(255, 255, 255) 0px 0px 1px inset; color: rgb(85, 85, 85); "></button>
  
• I was the programmer at Delco Electronics (part of a group with the cool name "Computer Techniques") that created the program that did all the graphics for the touch screen. This was a VSFortran program that would display the screens on an IBM 3279 computer terminal so that the user could add the buttons, lines, etc.. I added the ability to "reverse engineer" existing eprom code so that you could read prior model years displays in, modify them, and then generate new "cross-assembler" code
  lzgmyn 9 months ago 4
  

wish I did because I would love some help with a project.

I had read those comments before, quite some time ago. Really wish I know how to track this guy down and see if he could offer any insight on reverse engineering the code in the PROMS of the CRTC. I have dumped these and have made some small mods, but have much more ambitious changes I'd like to make if I could ever get a good handle on how it works. 8088 machine code is not my strong point. I never bothered to learn it as I could do most anything I wanted on PC platforms with various high level languages (Pascal and C mostly) so looking at a raw hex dump of 64K of ROM is kind of tough.

KDirk

Have you tried contacting the youtube user account through Youtubes messaging feature?

I have always wondered if there are any "hidden screens" in the software somewhere. Like on some video games if you hit a combination of buttons something unexpected happens or there are cheats or something. I bet the programmers hid something in there that only a few people know about.

I always thought it would be cool to do a code dump and flash a new EPROM and add some new features such as a screen saver or even a game of tic-tac-toe that could be played when the car was in park. I don't have the skills to do this, heck I had a hard time learning BASIC, but I am sure it could be done.

Easter Eggs are fun. I snuck some in some Delphi code back in the 90's for some on line screens we used back then. Nothing fancy. Just the names of everyone who worked on the project scrolling across the screen..

I've dumped the CRTC ROMs so I can tell you there are no easter eggs. The only screens in there that would not been seen in a Reatta (save for a few custom modified cars) are the cell phone control and setup displays. Since the cell phone was an option offered only on the Riviera (but apparently a few well funded Reatta owners got them installed special) these screens would normally have never been seen in a Reatta. No matter now anyway, as the integrated factory cell phone was strictly analog and would no longer work due to lack of analog cell service anywhere in North America.

The text portions of the various screens are easily discernible, once dumped the ROMS can be viewed in HEX or ASCII. I have also mapped out most of the small bitmap graphics (icons and buttons) and the character set bitmaps as well so I am at a point where I can modify these things. Larger bitmaps like the splash screen and the compass display (only available with the optional compass module from a Rivi or a Toronado) that shows during the light show are still buried somewhere in the code that I have not fully documented.

I have not figured out the touch handler code, so cannot move or re-map buttons on the screen at this point as the touch intercept and subroutine handlers need to be modified separately from the screen display. I really wish I could scrub the cell phone screens as they are pretty well useless and reuse that portion of the memory for other new screens I'd like to create. Problem is, I cannot figure out how the program flow is controlled and I suspect there is more ROM hidden in one of the other co-processors within the CRTC. Since most MCU's with inboard ROM are one time programmable (not erasable like EPROMS) I might be able to read the code from these IC's but cannot change it.

I know there is an Intel 8051/8052 MCU in the CRTC and it has integral program ROM of it's own. I am thinking that portions of the program that seem to be missing from the 2 EPROMS are hidden there. There is also a "system control" (as it is referred to in the IBM patent for the CRTC design) CMOS IC that apparently contains some low level code (boot loader?) and I suspect is the equivalent of a ROM BIOS in typical PC parlance.

So, right now I am stuck with only being able to do the most basic modifications. I doubt there would be anything gained by contacting Delphi (successor to Delco Electronics) to see if they might have any documentation buried on this setup. Even if they did, it would doubtlessly be protected by corporate confidentiality rules so they would never supply a copy. There was a former forum member that tried that route a couple of years or so ago, and apparently never got anywhere despite claiming to have found a contact at Delphi who was trying to get some helpful docs together.

KDirk

I suspect the calls for the screens and the button processing is handled by the BCM and not the CRTC.

Well, the BCM option programming does dovetail with the CRTC at least to the extent that it "informs" the CRTC of which model car it is in. Thus, the different splash screens depending on the Riviera or Reatta being the host vehicle. As well, the odometer VIN and reminder memos are stored in the 16K EEPROM within the BCM. I'm pretty sure that is the extent of the BCM's direct involvement in storing/sending data to the CRTC for display. Option programming also determines the support for the cell phone and compass.

The real time clock, trip data and radio station presets are held in workspace RAM within the CRTC. The button press decoding and response program is within the CRTC but have not nailed down just where. Per my previous post, in addition to the two 32K (27C256) UV EPROMS, there is EPROM memory within the 8051/8052 co-processor in addition to at least two serial ports (one is a UART, the other a "random access bus" which is setup for PWM I/O as the E&C bus to interface with the radio module and climate control).

Actually, this co-proc also handles the touch screen decoding so as to take that load off the main CPU (8088). It then sends the coded output back to the 8088 (which is running the main program) over a serial bus to act on according to the program instructions. This series (8051/52) of Intel MCU's has long been a staple of embedded system designs due to it's versatility and relative ease of development, much more so than the 8088 ever was. And of course, the 8088 is the main CPU used in the CRTC which is contrary to everything else GM was doing at the time, the Motorola 68K series chips being the preferred platform for all other engine and body control modules. IBM had designed the system (and they were in tight with Intel at the time) on which the CRTC and monitor were based, so their basic hardware design became the finished product in the few GM E platform vehicles that used a touch screen.

There seems to be a dearth of useful information on i8088 machine code programming around the net (have searched and found lots on assembly, but I need straight down and dirty native machine code as that is what is dumped from the ROMS, not an assembly language source code) so I am at a disadvantage trying to unlock the secrets of what is now 25+ year old code that probably no one besides myself is much interested in tweaking to such a large extent. Many of the guys who were experts 8088 programming back in the day are now retired or have let these skills lapse as they are no longer needed.

Virtually no one now is developing programs in machine code as the availability of cheap and vast amounts of RAM and mass storage have made the need for really tight coding (making every bit really count) has made the practice unnecessary. In the mid-80's this was still an issue due to the cost of RAM and fixed disks that were still rather limited in capacity. There were some true coding artists who knew how to squeeze a lot of functionality into 32 or 64K. My first computer had a whopping 16K and some really smart guys figured out how to do machine code programming on it that made it competitive in performance and functionality with systems having 4 times that memory. I used to look at the demo programs and read articles in magazines that went over my head on this stuff, always being amazed at what could be done with this "magic knowledge". Regrettably, those days are over and the skill set to do it has been fading into obscurity along with the once prolific coders who knew how to do it.

KDirk

Have a lot of early 8088 tools around here somewhere if it will help, think I am one of the few BIOS level programmers left. Pretty sure I have a copy of DASM somewhere which can make a binary dump readable.

Saw your questions.. Doubt I would be of any help. My IBM mainframe program only reversed the hex bit maps for all the eprom display objects.. Not reverse the actual display or control code.. The eproms were not 8088, but rather proprietary 8 bit DELCO processors. IBM "sold" moving to 8088 or 8086 processors, but could not deliver. My 3270 GDDM/VSFortran programming took them from using graph paper and counting pixels to reading in last models eprom maps, updating and regenerating new hex map representations. Not the cool stuff you are all doing

Wow, an old thread resurrected by none other than the erstwhile myster commenter. Nice to hear from you! I still have plans for further mods to this setup, bue they have been mothballed while I do more pressing restoration work on two of my four Reattae. I kind of got overzealous and bought a '91 convertible last March (what can I say, the opportunity presented itself) when I already had a slightly rough 88 coupe to do major work on. So, progress on both has been crawling along especially once winter arrived. Of course, I need to work tofund my projects so free time is limited anyway.

At any rate, I find your input interesting. There is a published US patent for a "GDS" or graphics development system from IBM that was apparently intended to interface the actual production touchscreen hardware to a specially fitted PC with custom software. This (per the patent documents) allowed the development of screen layouts, icons, animations and such for testing. Finished code was then burned to PROMs for production vehicles. By the sound of what you posted, this system never came to fruition, or GM opted not to buy it from IBM and do things the hard way. I wonder if proof of concept hardware was ever even built for this.

The hardware is strange compared to any other GM module of the era. What puzzles me is that the two CPUS do seem to be an 80C88 and 80C51 or closely related variant. The machine code in the two main PROMs is 8088 code, as most of it disassembles correctly. Further, the actual hardware in the CRTC looks to follow the conceptual design presented in the patent filing almost exactly. So, maybe the first generation design used in the 86/87 Riviera was different and the second gen used in 88/89 was in fact based on Intel CPUs.

In any case, my determination to tweak this system remains even if I am at a distinct disadvantage in lacking documentation and pointers. Just going to take a lot of time, trial and error.

If you have any other insights or memories to share on this hardware, it would be great to hear it.

KDirk

I am sure glad I found this post.. Pure dumb luck.. I don't know why I thought of that project from so many years ago.

I was a contract programmer in 1984 when I first started working on this program. The next year 1985, I hired into EDS as part of the GM/Delco Electronics Account.

Another fellow had started it, had a heart attack (not because of the project), and was fine, but retired. I was given that project/program as my first effort with them as I had just arrived and had quite a bit of IBM Mainframe Fortran/GDDM programming experience (worked at an imaging lab at Purdue and down in Tulsa at the Standard Oil company during Oil research graphical scientific programming).

The program was pretty well started, I added a lot of functionality so that you could create new icons and images. My code would create the screen maps and then generated related cross assembler hex maps that could then be burned into the related screen eProms. I think the mindset was that the images were in separate PROMS from the code/functionality so that they could be referenced and updated each "model year" separate from the code base. I then added functionality where I could read previous screen maps (once dumped to a text file from the Eproms) and would do manual character scrubbing and conversions to get into my internal screen/image format and load back into the editor. That allowed for easy resuse of prior maps, even from test batches from prior versions. The Engineers loved it. Funny thing is, I they run their old maps through my program, because even without changes, my regeneration of the maps had much better alignment and documentation/comments so they could more easily interface the screen maps with their code base.

I am REALLY fascinated by what you are saying about IBM having a patent on the "GDS", would you happen to have a copy or reference number? I would LOVE to see it. That makes perfect sense to me. I wondered why Delco Management insisted that I "destroy" my programs. Must have been because IBM was given the "rights" to what I did and put in a patent for the concepts. Used my frickin working system as their "proof of concept" and requirements.

I am not sure if they ever got their GDS working, I left Delco in 1989 to go help sell a deal and then go manage in a new / large account at EDS down in Houston. A little place called "Enron", ever hear of it? In 1984-85 when GM acquired EDS and all systems folks were transitioned to EDS, I hired into EDS in March of 85. I moved up in position to a Systems Manager role over Engineering and Manufacturing programming and was not down into the details of many systems. So, my programs were developed in 1984-early 1985.

Now, after my version of the program was moth-balled, I know IBM had a person picking my brain who showed me a MSBasic program he was writing to replace it. He did mention they were going with 8088 processors. I lost touch (they froze me out) of any subsequent involvement. The next year, 1985-86 model year development time - which would have been for the first generation/release, The Delco Plant Manager came to me asking what it would take for me to resurrect my program and update it for the current model year work. After looking at it for a bit, we agreed too much time had passed, processors had changed (not that I remember what they were now going with in 86) and it would take too much updates for me to get it done in a timely manner. So, it was back to graph paper to get 1986 model year updates done (I am told they minimized changes because of that).

I would imagine IBM eventually got something working as you describe, but I never saw it.

I do know that 1986 the displays were in Buick Rivieras and Cadillac Seville's.. Reatta's in 89? - Those were probably the "second generation" - but, I don't know if the 1986 Model year items had the 8088 type processors or not.

What you are doing is really fantastic!!!!

(Name is) Dave S. Great to talk about this after so many years.. I guess right at 30 now

Dave,

Thank you for that run down of the history, very interesting stuff to hear about (to me at least). There are three seperate patent documents I have downloaded pdf's of related to this system. One is for the actual in-vehicle hardware (touchscreen unit and seperate computer module referred to as CRTC), another is for the development system proposed by IBM. I Think the third one was related to an expanded version of the GDS that involved maniframes and a WAN so that the code base would reside at IBM (presumably) and the customer (GM/Delco) would use remote terminals on a dial in time share system to develop screens and program code for eventual comittment to ROMs. Seems needlessly complex to me, but IBM had a tendency to over think things in that era. Perhaps their were intellectual property angles involved that caused them to pursue this approach.

One of the other things addressed in the patents is a program called CXEDRAW. This, by my reading, was almost like an graphics handling operating system that rendered the graphic primitives (their term used in the patent) into finished screen output and also handled animated icons (like the rotating fan on the climate control screen among others). I don't know if that sounds familiar to you or if it was something IBM planned to produce as a software component of this system that never materialized.

There is also a schematic of a special dual output ISA based video adapter card for a PC (likely an IBM AT 5170) that had one output for a standard PC display and a second for the CRT unit used in the car. This facilitated development work on the main display while rendering a live preview of the screen output at the vehicle display without having to burn ROMs and test the code on the production hardware. Fairly primitive by current standards, but would have been quite the setup in the mid 1980's.

If you can PM me here on the forum with an email address I will gladly send you the PDFs I have. The one regarding the in-vehicle hardware design has helped me a lot in understanding the system architecture and how the various components within the CRTC interact to make the system work.

KDirk

Kevin: What are the three patent numbers?

Ok, I have the two .pdfs attached (assuming that it works, don't know if this forum allows non-image attachments or not).

The patent numbers are:

4787040

4811240

These are both US patent numbers, issued to IBM for the in vehicle display/control system and it's related development system. Note that I was mistaken about there being three relevant patents. I had downloaded a third patent number referenced in the other two but it was a very general patent regarding VGA display technology for placement of text on an all-points addressable display, and was not specific to the CRT system developed for use in the Riviera, Reatta, and Toronado. So, I am not including it here as it is not particularly interesting or useful to the subject at hand.

These are interesting reading if you are technically minded as I am, and give some insight to how the system was implemented. Also shows just how complex it really is from the standpoint of the number of components involved and the effort to make the design vehicle independent so that it could be utilized by almost any manufacturer in any model with changes only to the firmware rather than requiring major redesigns for each new application.

KDirk

US4787040A.pdf

US4811240A.pdf

Were you Delco guys working in Kokomo or Michigan?

Steer and Stump, and or Hugger for me. Kokomo

Being raised in Frankfort, about 25 miles from Kokomo, I had several HS friends that worked a Delco Kokomo. My older half sister worked on the assembly line for 25+ years.

Last, I got a call from Don Almquist (CEO and plant manager) back in Aug 2011 when he was looking to sell his 1990 Red Reatta convertible.

Is anyone still working on hacking this?

I wrote some microcontroller tools to play on the E&C bus.  demo at

The microcontroller board I'm using costs $12 to get started, and the E&C bus interface is about $1 worth of breadboard components.

I would like to find out more about the traffic between the control screen and the radio.  In return I can help anyone monitor the bus and send arbitrary messages on it to observe what they do, and write an application to participate in the bus like this cd changer emulator.

My radio has a TMS370 cpu.  TMS370 is not supported by idapro even if it were easy to get the code out of the processor which is not the case.  But I have experience and tools for other platforms such as 8088, 8031/8051, and more.  I would really like to get into firmware of a device to learn what messages can be sent by the device and what messages it will respond to.

Still on my back burner. My intent was to use a logic analyzer to intercept the data stream and document each command at packet level to replicate on a new microcontroller. Bus spec for E&C is 1Kbps pulse width modulated, high level is 12v. Completely proprietary and difficult to interface with any common modern "hobbyist" MCU due to the voltage level. Pretty well stuck using voltage shifters for I/O level translation unless you use an 8051 or similar.

If you have the chops to put together some hardware that can speak the language (so to speak) I'm game to help out. I would heavily recommend you download and read the patent PDF's up thread as there is some good info there amd it covers the system architecture of the touchscreen system in the Reatta and Riviera almost exactly as built so is useful as a hardware reference.

Unfortunately there is ZERO documentation in the wild (that I've found) on E&C bus so we are stuck rolling our own. Luckily the older (pre-OnStar) iterations of E&C are somewhat less complicated having a slightly smaller command set.

I'm interested in the details of the hardware you are looking at using to interface with it. You are correct in seeing the oddball TI MCU in your radio. Delco did this in most (all?] integrated radios of the era as it was just a control panel built to slap onto the common ETR CDM (GM speak for remote radio module) where the Reatta used a touchscreen and intermediate computer module to do the same job.

KDirk

Hi Kevin,

Photos of the hardware setup I am using are here http://imgur.com/a/ESqoI . I just use an NPN and PNP transistor for level shifting to 3.3v.  The microcontroller board is an old version of TI EK-TM4C123GXL which currently costs $13.  The processor is an 80 MHz, 32-bit ARM.  I only used it because it was immediately available, and I am familiar with the Keil development kit.  The Launchpad board features a full debugger.

I have discovered that in the car E&C bus idles at 12v, so I am using ground as a mark on the bus.  I have separated the messages into: 3 bits for priority, 8 bits for address, remainder is data, mandatory parity bit at the end.  Message should have an even number of bits total and the number of ones should be odd.  Data is LSB first and extra zeros at the end are not transmitted.  A 1 is a long pulse.

To receive and transmit I am using program loops that read the value of a hardware timer that I set up to 1 usec resolution.

I have several hardware logic analyzers but none of them support serial protocols.  Instead I have a monitor application that prints messages that appear on the bus along with an rtc timestamp.  To send arbitrary messages I used a line of code at the beginning of the monitor app so that a programmed message would be transmitted when the reset button is pressed.  With these tools, I could observe traffic between the radio and cd player, and isolate one member of the bus and replay a message at it.  I have seen and am working with both bitmapped commands/responses and messages that contain numerical data.

Cheers! Ken

Interesting. I got pretty deep into the BCM etc in the first part of this century but have not done much recently. Just retired so may have some more time. Still have all of my stuff from the early days of the IBM PC when I used to write BIOS code.

Ken, you have made more progress than I thus far. If your "rig" can capture and replay commands, that is key to interfacing with it as we can figure out which commands are for which functions and then program an MCU to transmit those commands desired from any programmed trigger event desired. I'd like to get more information about what you are using - both hardware and software - as it sounds like I'd benefit from assembling an identical rig. Once the command set is documented and we have a solid hardware spec to use, the rest should be straightforward.

I know there are also status commands utilized to determine what devices are present (tape deck, cd, etc.) In addition there are bus arbitration commands to determine when clear to transmit so as to avoid collisions from multiple devices transmitting concurrently. These need to be documented for the proper implementation of third party devices interfacing with the OEM hardware reliably.

KDirk

Is anyone still working on hacking this?

 

I wrote some microcontroller tools to play on the E&C bus.  demo at

 

The microcontroller board I'm using costs $12 to get started, and the E&C bus interface is about $1 worth of breadboard components.

 

I would like to find out more about the traffic between the control screen and the radio.  In return I can help anyone monitor the bus and send arbitrary messages on it to observe what they do, and write an application to participate in the bus like this cd changer emulator.

 

My radio has a TMS370 cpu.  TMS370 is not supported by idapro even if it were easy to get the code out of the processor which is not the case.  But I have experience and tools for other platforms such as 8088, 8031/8051, and more.  I would really like to get into firmware of a device to learn what messages can be sent by the device and what messages it will respond to.

The stereo in your photo is identical to the one in my '96 Suburban.  It represents the next generation of Delco stereos after the ones that came in our Reattas - circa 1995-early 2000s.  It will be very interesting to many of us to know how compatible the E&C protocol in your stereo vs our earlier models.

I'm bringing back an old thread here but I've searched from one end of the internet to the other and this is one of the few posts where people are discussing the E&C protocol and someone in here has actually communicated over it.

I'm curious, has anyone made any progress on this recently? I'm trying to figure out a way to build an arduino interface to the e&c bus.

No real progress to report. I can tell you that E&C is a pulse width modulated signal at 1kbps, 12 volt DC signal level. There is no publicly available documented command set available and so it needs to be reverse engineered from scratch. There are many commands, not all of which are implemented in all applications. It is a poll/response bus types and apparently utilizes a "clear to send" of some sort to verify the bus is free before a command is sent by a node on the bus.

My interest in this has waned since I discovered the CRT system in the Reatta doesn't follow E&C commands sent on the bus by other devices and update the screen display accordingly. In other words, an external device like a scan tool that can trasmit E&C signals will change the status (volume, preset station, temperature, what have you) of the intended receiving device but those changes are not reflected in the screen display on the CRT. Rather, the CRT simply shows the last status it commanded and not any of the changes sent by the scan tool. This causes the screen display to get out of sync with the actual status of the radio or HVAC system. Therefore, being able to directly send E&C in the Reatta has very limited usefulness. I am looking at a different way around this that entails directly writing the RAM in the CRTC but not sure that would yield the results Im looking for either.

KDirk