I checket the support site for winALDL and did not find a Type 253 ECM listed in the table of supported ECM'*
The software might still work, but it may be only partially functional.
If this sounds a little crazy, then a history lesson in GM car computers is in order.
General Motors refers to the connector under the dash as the ALDL connector. The anacronym stands for Assembly Line Data Link. It was never intended to be used as a diagnostic tool interface in the field. At the time it was created (Early 1980'*), home computers were a new concept and most car service techs, including dealerships, didn't have them or access to them. GM never released documentation on the actual data stream comming out of the ECM, as it was never intended to be used outside the factory doors. The only thing published was the flashing codes on the SES lamp.
It was only later that companies like OTC came up with a scanner that could read the data. I don't know if they bought the information from GM, or simply reverse engineered it by looking at the data from a live ECM. All of the home brew code readers that followed are the product of reverse engineering the data from looking at live ECM'* in use. (The Pontiac Fiero community were the pioneers of this, followed by the F-bodies and Y-body groups...my little contribution years ago was for the 87 MPFI V6 in the Camaro/Firebird)
The data comming out of the ALDL port is serial in nature, but it doesn't follow the RS232 standard. It is more like Teletype data. Originally it was very load speed..approx 148 baud, but has gotten faster over the years. It isn't a standard..there isn't a clock generator inside the ECM just for driving the ALDL port at a specific baud rate..GM is using simply using the ECM'* clock to drive the serial data, hence the strange non-standard baud rates. It is half-duplex..there'* no handshakes between the listening device and the ECM, it'* a one-way continous dump of data. The actual data bits are also different from RS232..the ALDL uses 0 VDC as the "0", where RS232 uses -12VDC as a "0". Hence the need for a conversion circuit if you want to use the serial port of an IBM PC to read the data. Because of the weird baud rates and framing, it'* a crap-shoot at best to get them to read it. The serial port chip in your PC will either read it, or it will not.
Last, comes the data itself. When you get your PC to see the data bits and store them in a file, you start looking at the file for a repeating pattern with a hex editor. IIRC every block of data comming from the ECM starts with a pair of bytes that are allways the same (Check sum of the EPROM) to identify the ECM'* PROM chip. What follows is a fixed number of data bytes with sensor data. Following that is a variable length block of data with the trouble codes in them. The pattern then repeats. (Forgive me, it'* been about 15 years since I last tried to pick apart ECM data...memory is a little fuzzy on it)
As a fun project for a few weeks, it can be ammusing. The drill to figuring it out is to test data capture with the engine off, then move/disconnect one sensor at a time to locate which byte in the data represents that sensor. You'll also be throwing trouble codes on the ECM so you'll see a new value pop up at the end of the variable length portion of the data block.
IIRC, you used to be able to modify the winALDL software'* supporting INI file and create tables for ECM'* that weren't supported. I don't know if that is still the case.
When I went to a Haltech ECM on the '87 Camaro, I really didn't need to figure out GM'* ALDL anymore. Then OBD-II came along and it is actually a "standard" with published codes and standardized communications.