[ « back to ricapar.net | @Ricapar on Twitter ]
Wang Writer 5503 Restoration Project
2022-11-12 Final Update
It’s been a while since I’ve updated this worklog. After a handful of failed attempts at cleaning pins, testing some RAM chips, and a handful of other things - I had felt that I had exhausted the limits of my electronics skills. At this point, any more “creative” attempts by my hands were likely to cause more damage to the machine rather than helping.
I’ve long been a fan of the Vintage Computer Federation. I’ve attended VCF East, their Vintage Computer Festival, a number of times and I’m always blown away by their collection. If you’re reading this and are a fan of vintage computers (if you’re not.. then what are you doing here?!), I highly encourage you to give them a vist. They’re located in Wall, NJ and are part of the InfoAge Science and History Museums. Anywho, I knew if I wanted to find a new home for this place where it had a chance at being fixed or made useful, it was there.
In Janurary of 2021 I reached out to Tony Bogan at VCF and they accepted the donation. I drove down to InfoAge and dropped it off in their warehouse. I figured that would be the last I hear about the machine.
Fast-forward to September 2022, almost two full years later: A friend of mine messages me that a YouTuber he follows has acquired the same machine! The YouTuber in question was Usagi Electric (Twitter: @UsagiElectric).
After all the frustration I had with this machine trying to find any information about it - suddenly there’s someone else who managed to acquire the same model! For a brief moment I thought he somehow came across the one I had donated to VCF, but nope - it was his own find. Out of excitement I went to DM him on Twitter, only to find he had already beaten me to it! I had a DM from him reaching out, in hope that I had the system disks.
Turns out, the machine can’t do much without any software! There’s no hard drive in this thing, so it relies on an operating system off of one of the provided system disks to basically do anything. The machine he had found came with some floppies but none were the system disks. But… mine did!
After a few emails back and forth, I got in contact with Jeff Brace at VCF and decided to make a vist down to InfoAge again for one of their repair workshops. One of their members, Sark/@crtdude, was there ready with a luggable PC that he uses for imaging floppies.
After finding the right floppies in the warehouse, imaging them, and emailing them over to UsagiElectric, we had a winner!
I’m just super happy that my efforts in documenting this strange machine were useful to someone. Feel free to read through the work log I have on this page, but at this time I don’t foresee myself continuing to update this page any longer.
I encourage you to follow Usagi Electric on YouTube. He’s working on getting the Wang Writer back in working order and maybe even getting CP/M running on it too. He’s also got a handful of other amazing vintage computing content on his channel.
If you’re local or within reasonable driving distance of Wall, NJ, please consider giving InfoAage and the Vintage Computer Federation a visit. It’s an amazing place filled with millitary, radio, and computing history. There’s something for everyone there.
This is my adventure in trying to restore a word processor from 1981 to working condition. At this time, it is not currently working. It powers on, but it does not pass its power-on tests and does not currently get far enough to even attempt to load its system software from the floppy disks.
Acquisition and a Mission
In early September 2020 I stumbled across a Facebook Marketplace post titled: “Old computer setup processor monitor wang 40 dollars estate find”. I love old hardware, and already own a few other vintage systems, so I wasn’t going to pass this one up. I’ve heard of the Wang company in the past, but I’ve never actually gotten my hands on one. (The “wang” jokes just write themselves, don’t they?)
I messaged the guy on Facebook Marketplace, and later that night I met him at his storage unit to pick it up. It was in serious need of a cleaning and smelled like it spent the last 30 years in a basement. But it came with everything. Cables, system disks, user and technical service manuals, etc.
What I couldn’t find was any information about this on the internet. Searching Google for “Wang Writer 5503” returned nothing. (That search now returns my own Reddit and VCF posts)
Given the lack of information about this machine I’ll be doing my best to document as much as I can about it as I can and hopefully get it working in the process. I’ll be periodically updating the work log below as best I can. If I fall out of touch with this repo feel free to reach out to me on Twitter, Reddit, or where ever else you can find me.
Contact Me, Please!
I can’t seem to find any information about this machine on the internet beyond a single line-item in a PDF of a parts catalog.
If you’ve used this model of word processor, know anything about it, or have any suggestions on how I can better diagnose what may be wrong with it, I’d love to hear from you.
You can reach out to me via any of the accounts used in the posts under the Links section below or via Twitter.
Links
- Photo Album (Google Photos)
- My post on /r/retrocomputing
- My post on Vintage Computer Federation forums
- @Ricapar on Twitter
Work Log
2020-09-29
A little help from the NSA?
I had run the boot ROM through a disassembler when I first extracted it, and was able to get some brief insights into what it was doing just by manually tracing through the instructions. I originally had unsuccessfully tried to run it through Ghidra, the NSA’s open-source software reverse engineering suite, to get a better picture of ROM’s code. I’ve seen tools like IDA Pro used professionally, but I’ve never had a legitimate way to acquire it nor a use case that would warrant me purchasing a license. Ghidra, while seemingly rough around the edges, seems to have a decent community building around it, is free and open-source, and not all that difficult to get a feel for.
I didn’t get it working the first time around, but I went for a second round today after some encouragement. Turns out all I was missing was a right click > decompile on the imported ROM! The resulting output was much more useful.
With the ROM dump successfully loaded into Ghidra I was able to get a decent picture of the execution tree. I also went a bit further and drew up the I/O Address Table into the memory map (see: PDF page 236 on the maintenance manual, Appendix F-1) and mapped a few other addresses.
I’ve added the Ghidra project into the repo under roms/ghidra/.
I’m still working through the function execution, but the decompiled output is immensely helpful in at least visually mapping out what what’s going on. Based on function execution, there seems to be a pattern of blasting out a series of commands to certain pieces of hardware (or perhaps just initializing all of it?) then followed by reading some data back and comparing against certain expected values.
On other fronts, I’m still waiting on my additional EPROM and EEPROM chips so I can maybe bypass some of the hardware checks. At this point I don’t really care if it can’t initialize the printer, I’d just like to get something to show up on the screen!
2020-09-23
Preserving the Sacred Texts
When I acquired this computer, it came with a pile of books and binders. One of those books was the “Product Maintenance Manual” from “Customer Engineering”. It’s safe to say that without this manual I’d have close to zero chance of getting this machine working again.
As with most cases related to this machine, I have not found a single trace of the contents of this manual online. I wanted to make sure this had a chance at preservation though. I wanted a PDF copy of this book.
I vaguely remember the last time I used a scanner, and it wasn’t a particularly great experience. I had inquired around locally for a service that can do bulk scanning, but it was either more money than I wanted to spend or way too far away. I bit the bullet and pulled out our old printer/fax/scanner/copier machine from the closet.
I’ll give a huge credit to the developers of NAPS2 (Not Another PDF Scanner 2). I originally thought “maybe I’ll just do one chapter a day”, assuming that this was going to be along and drawn out process. With NAPS2 I was able to control the scanner, set it to duplex scanning from the feed tray, and let it go. I did batches of 20-30 pages at a time. I had to fix a paper jam every now and then, but other than that the entire scanning process was a breeze. What I thought was going to take me a few weeks I did in about two hours. The PDF output even has OCR enabled.
The scan is not complete yet. It’s probably missing one of the most important components: the system schematics. Unfortunately those are in double-wide fold-out pages that don’t physically fit into the feed tray nor the flat-bed of the scanner. There aren’t too many pages remaining, so I’ll probably just do those with an app on my phone. That’ll be a task for another day though.
For now, I’m super excited to have gotten the majority of the book scanned in. Once I get the final schematics added in I’ll see if this can be accepted into Archive.org’s catalog.
2020-09-20
I’m going to table the rest of the boot ROM until the new EPROM/EEPROM chips arrive. I’m also restocking on breadboard jumper wires. Those have a knack for disappearing.
The plan for the day was to use a spare Arduino Uno R3 to test some of the DRAM on the memory PCA. I had come across a number of posts across various vintage computing forums. A handful of links are available on the Memory Testing Ideas section at the bottom of this page.
The uPD416C-2 chip is a 16Kx1 RAM chip. This means that the chip provides 16,384 possible addresses, and at each address you can store a single bit. Using the chip is a bit more complicated though. Looking at the pinout above, it only has 7 address lines (A0-A6). With 7 address lines you can you can only represent 7 bits at a time, which would limit you to only 128 addresses. To get 16K addresses the chip multiplexes those 7 address lines via timed latches on the RAS (Row Address Strobe) and CAS (Column Address Strobe) lines. This takes the the 128 possible addresses and multiplies it by another 128 possible addresses, giving us a total of 16,384.
Putting aside the timing, the process to read an address would be:
- Set RAS, CAS, and WRITE to HIGH.
- Set the row address.
- Set RAS to LOW.
- Set the column address.
- Set CAS to LOW.
- Read the state of the DATA_OUT line.
Easy enough, and most DRAM chips seem to work this way. This chip in particular has three voltage-in lines: +5v, +12v, and -5v.
I have the breadboard all wired in and ready with the Arduino, but only after I had everything wired up and ready to go did I realize that I needed to supply the chip with all three expected voltages. Unfortunately I can’t do that directly off of the Arduino’s power, so I’m going to need to power the chip and the Arduino off of a different power supply.
Unfortunately by the time I realized this I was done tinkering for the day. I don’t have inverter chips laying around, nor do I have a power supply laying around that outputs all +5v, +12v, and -5v at the same time. Once my extra jumper cables come in the plan will be to piggy-back off of the Wang’s power supply, which does output all of those voltages (plus a few others) and power the Arduino off of that and see how the RAM testing goes.
More to come!
2020-09-19 (Part 2)
I spent most of the afternoon reading through the manual again. Less looking at schematics, more reading details. Found the output address table! At the very end of the table is how the 7-segment error display at the end is controlled:
ADDRESS DATA
5F Error Display (7 Segment)
0 A (L)
1 F (L)
2 E (L)
3 D (L)
4 C (L)
5 G (L)
6 B (L)
7 DP (L)
The (L) indicates that when those bits are set LOW, the display should have those segments lit up.
Thankfully 7-segment displays seem to have pretty standard naming and ordering.
On boot-up I was getting a “7” on the display. That’s segments A, B, and C. By the table in the manual, that means that bit positions 0, 4, and 6 should be LOW (0).
Binary Hex
Data: 1 0 1 0 1 1 1 0 AE
7-Segment Position: DP B G C D E F A
A quick CTRL+F in the boot ROM found several sections like this:
XC4B3:
LD A,$AE
OUT ($5F),A
Load hex AE into the A register, followed by outputting the A register into 5F, the address that controls the 7-segment display. This instruction causes the 7-segment display to display what we would read as the number 7. This pattern is used throughout the ROM. Every write to 5F always comes from the A register.
My idea is that if I can follow through its execution and find the area of code that is identifying the fault, I can trace what it is actually testing and hopefully identify where the fault actually exists.
Unfortunately, at some point during today’s debugging and probing the display changed from displaying a 7 to displaying a 6.
Same approach - figure out what segments would represent the number “6” and flip the right bits:
Binary Hex
Data: 1 1 0 0 0 0 0 0 C0
7-Segment Position: DP B G C D E F A
A CTRL+F through the ROM finds four areas where a value of C0 is written to the A register. That’s too bad, because there was only one area where the previous value of AE was coming from.
I’ll be spending some more time digging through the ROM’s code, seeing if I can trace where what section of code is triggering the write of C0 to the 7-segment display.
In the meantime I also ordered some replacement 2716 EPROM chips. I don’t want to risk breaking or wiping original one, but I’m thinking I may flash a replacement one with a modified copy of the boot ROM code and see what I can make it do. Maybe see if I can skip some checks for non-critical components or just make it do something else that’s interesting.
It’ll probably get annoying to have to UV-wipe the EPROMs with any code changes I want to do, so I also ordered some EEPROMs. The pinouts are close, but not the same. I’ll probably run it off of a breadboard with the adjusted pinout to get started - it should allow me to iterate quickly on any code changes. If I get something I intend to keep for a while maybe I’ll take the time to burn it onto the EPROM. Or maybe I can make an adapter socket if I’m feeling adventurous :)
2020-09-19
I’ve been spending some time the past few days going through the service manual. I’ve got my bearings now, and can generally find where a component is located within the schematics without too much trouble.
Power Supply Tests
I didn’t note this in an earlier update, but I did go through all of the power supply outputs and confirmed they are all up to spec. The service manual contained a nicely detailed table containing the expected voltages and tolerances for each pin going into the motherboard, and everything was up to spec.
+5V (4.75 -to- 5.25Vdc) J1 Printer PCA pin 1, ground pin 3
+12V (11.40 -to- 12.60Vdc) J1 Printer PCA pin 5, ground pin 3
-5V (-4.75 -to- -5.10Vdc) J1 Printer PCA pin 7, ground pin 3
-12V (-11.76 -to- -12.24Vdc) J1 Printer PCA pin 9, ground pin 3
+18V (+14.00 -to- 21.00Vdc) J3 Printer PCA pin 1, ground pin 3
+36V (+28.00 -to- 42.00Vdc) J3 Printer PCA pin 5, ground pin 3
Chips’ (testing) Challenge
The system boot-up says that the error message is coming from CPU board, so most of my testing has been focused on there. Every removable chip has been removed and re-seated. Contacts have been cleaned as well. No changes there.
I’m slowly going through all of the chips on the CPU board, verifying at the very least that they’re getting the expected voltage on the their +5V pins.
2020-09-15
Dumped the boot PROM from the middle motherboard. PROM chip is a Hitachi HN462716G; was able to get it dumped using XGPro with a TL866Plus EPROM reader/writer.
The PROM dump contained some strings that seem to indicate that there may have been errors in reading the ROM. It’s a 2K ROM chip, but according to the manual the ROM is wired into the bus at memory addresses 0xC000 through 0xC400, indicating that it may only be actually mapping the first 1K of data out of the chip. The error is presented a bit past the 1K mark, so I’m not entirely sure if I’m already dead in the water with a PROM that’s lost some bits over the last 40 years.
00000720 5d 80 f1 e6 0f c6 90 27 ce 40 27 77 23 c9 4d 65 |]......'.@'w#.Me|
00000730 6d 6f 72 79 20 45 72 72 6f 72 20 61 74 20 20 20 |mory Error at |
00000740 20 20 20 70 61 67 65 0d 45 78 70 65 63 74 65 64 | page.Expected|
00000750 20 64 61 74 61 20 3d 0d 52 65 63 65 69 76 65 64 | data =.Received|
00000760 20 64 61 74 61 20 3d 0d 58 4f 52 20 64 61 74 61 | data =.XOR data|
Nevertheless, I was able to disassemble the ROM using Mdz80, a disassembler for the Z80 CPU.
mdz80 -a -f -v -xc000 rom_l59.bin
The -xc000 flag was key and took me a few minutes to realize why I couldn’t follow through the assembly that came out of the first dump I did. The Z80 CPU starts its program counter at memory address 0 but the ROM is wired into memory address 0xC000, so any addresses referenced within the disassembled code need to have 0xC000 added.
The binary and disassembled ROM can be found here:
- Binary: roms/rom_l59.bin
- Hexdump: roms/rom_l59.hex
- Disassembled: roms/rom_l59.z80
2020-09
Acquired! Cleaned and it’s now taking over a table and half the floor in my TV/game room.
It powers on. No smoke or sparks. Doesn’t boot up though.
According to the manual the 7-segment display on the back is used to indicate where the power-up diagnostic routine has identified faults.
The display reads a “7”, indicating:
| Error Code | PCA | FRU |
|---|---|---|
| 7 | CPU 7777 | CPU UART OR PIO, KEYBOARD CABLE, KEYBOARD UART |
References
Datasheets and stuff. These are here mostly for my own reference.
Datasheets
- Z80A CPU
- HN462716G EPROM
- uPD416C-2 16K x 1-Bit RAM
- Intel P8272 Floppy Disk Controller
- D3-6402-9 UART (Not an exact match, but seems to be a compatible chip. Why was this one so hard to find a datasheet for?)