Making New Victor PA-T130 Mark Sheets

The first part of my reverse engineering work on this unit


I recently got a Victor1 PA-T130 Program Chime. Sold only in Japan, it is a timer with a built-in FM sound source2, allowing the scheduling of contact closure or chime audio outputs at specified times on specified days of the week. This is the sort of thing that might be used in a school or office. There’s a small community of people interested in these sorts of devices who run them in their homes, and with the other chimes I’ve been running for a year or two now3, I suppose I’ve joined that community as well.

In the PA-T130’s built-in chime, there are four internal preset melodies and a fifth slot reserved for a user-programmable melody - somewhat rare in this type of equipment. A remote trigger input also allows the first program to be activated by an external contact closure, independent of the timer. This external contact closure is the primary way I’ll be using this unit in my time signal setup, as I already have a more flexible timer made using a single board computer.

The unit has some very basic controls on the front panel, but the majority of the work of programming timer schedules (and custom melodies) is done using mark sheets. Think of these like “Scantron” tests from school. It is a proprietary format storing 75 words of 7-bit data on flexible paper cards. The unit would normally come with a number of blank sheets, printed with only the sync bits and one data word each to identify the type and end of the data. The user would use a pencil to fill in the desired data, and the sheets are then fed into a motorized optical reader in the unit.

Missing mark sheets

My PA-T130 was a fairly cheap Yahoo Auctions find and seems to have lived a hard life. The mark sheet storage tray on the bottom of the unit was missing, its mounting hardware was broken, and most importantly, it didn’t come with any sheets.

I thought this wouldn’t be a problem given my intended usage as a simple externally-triggered chime sound source, but quickly realized after some experimentation and reading of the user’s manual4 that the mark sheets were a requirement. The remote input does not activate the first chime, but instead the chime as specified by the first program. This meant that reproducing the mark sheets was now a requirement for basic operation, rather than something I’d get around to some day.

Figuring out the data format

For the purposes of this article, I will use the following naming convention. Looking at the mark sheet diagrams from the user’s manual, the topmost bit will be considered bit 0 (least significant). This counts down through bit 6 (most significant), and is followed by the sync bits at the bottom. When feeding the sheet into the unit, the sync bit will be on the left, and bit 0 will be on the right. Coincidentally, this naming convention ended up matching silkscreen markings on the optical reader PCB.

The user’s manual contains some information on the mark sheets, but not everything required to make new ones. It shows the start of the sheet with the ID bits and the overall data layout, but the diagrams are not to scale and do not show the end of the sheet or even how many words of data are stored per sheet.

Timer program diagram Chime program diagram

I was able to match up these diagrams with a photo from a previous PA-T130 listing on Yahoo Auctions.

Previous Yahoo Auctions listing

From this, it was easy to determine that the sheets store 75 total 7-bit words of data. Timer program cards use a value of hex 42 for identification, while chime program cards use hex 20. Both types of card are terminated by hex 78.

Figuring out the physical format

The mark sheet data format was now known, but the physical format remained a mystery. A paper card, of unknown thickness and size, with the data at unknown positions.

I knew I wanted to be able to print new sheets using a laser printer on 8.5x11 paper, but it was obvious from the auction site photo that the original sheets were longer than 11 inches (comparing to the width of the unit). I didn’t know if it would be a problem to squish the data closer together or eliminate some of the blank space at the beginning so it would fit lengthwise on a single page.

It was also possible that standard printer paper, being thinner than a card, would allow too much light crosstalk between adjacent marks. If I had to come up with some kind of thicker cardstock, then that would have been another problem too, since the drive rollers on my unit’s optical reader had hardened over the years and were really struggling to push a standard index card through the mechanism.

Pressing onward anyway, I partially disassembled the unit and started looking at the optical reader mechanism.

Optical reader

It’s a fairly complex design, with the paper path made of a number of separate pieces of metal which I was not looking forward to taking apart. But then I noticed the PCB with the sensors could be easily removed.

Sensor PCB Sensor holes with PCB removed

With this access, I could not only measure the spacing between the sensors, but also their position relative to the left edge of the card. To make things easier to measure, I inserted some blank paper in the card slot and used a pencil to mark the leftmost and rightmost sensor holes. This way I could simply measure the marks on the paper instead of struggling to fit my calipers inside the unit.

Measuring sensor PCB Measuring paper

I came up with the following measurements:

  • Card input slot width: 79.5mm (output slot is slightly wider, irrelevant here)
  • Distance between centroids of sync and bit 0 sensors: 48mm
  • Distance between sensors, derived from the above: 6.85mm
  • Distance from left edge of card to centroid of sync sensor: 11mm

Generating the mark sheets

It seemed like the best way to tackle this was to generate an image of a mark sheet “parametrically” and print it, designing at a fixed DPI value to ensure correct dimensions on the printed page. I chose 10 pixels per millimeter, about 254 DPI. To minimize iteration time, it made more sense to have the data pre-filled, rather than printing only the ID/sync and filling in the data with a pencil, as would have been done with the original sheets.

For generating the image, I used an old standby with which I’m very familiar: PHP with the GD library. My code exports a PNG file, which is then imported into GIMP at the correct 10px/mm resolution, printed, and trimmed to the correct dimensions with scissors.

Generated mark sheet


The first few sheets I printed were total failures. They were not even detected by the PA-T130, they’d just be pulled through with no success or error output at all. I started playing around with sizing and spacing, changing them almost randomly. This was mostly a foolish waste of time, but I did get the unit to output an error once or twice. It was at least nice to have something!

Optical reader control PCB

Looking at the control PCB for the optical reader, the design was pretty obvious. Eight comparators, converting the analog light level from the sensor to a digital 0/1, and a trimpot and test point for each, most likely to set the threshold. I resisted the urge to mess with the trimpots5 and instead stuck the oscilloscope on the test points. The test points are on the analog light signal and not the digital comparator output.

Sync bit test point

From this, it’s obvious the marks are being seen by the sensors, but it’s unclear if the signal is usable. After some probing on the connector leading from the reader PCB to the main PCB, I found which pin carried the sync signal, in its digital form after passing through the comparator. From there, it was a simple matter of tuning the mark/space ratio on my printed sheets to provide a good signal at about 50% duty cycle. Most importantly, and very conveniently for me, each word could be packed more closely than on the original card without causing any timing issues with the firmware. An entire mark sheet could be compressed to fit on standard 8.5x11 paper, and the unit was able to read these sheets successfully!

Probing the comparator outputs Comparator output for sync bit

Future preservation work

As with all of my reverse engineering and modification work on these various chime devices, I will be releasing the mark sheet generator code as open source soon. A direct line output recording of the four built-in melodies is available here.

I’ll also be dumping the unit’s program ROM and possibly doing some analysis of the rest of the circuit. Through some emulation effort, code disassembly, or even just a logic analyzer and patience, it would be possible to make VGM logs of the raw data sent to the FM chip.

On the subject of other chime devices, I already own a few others and each one will be getting some reverse engineering and preservation work in due time. I’ve written a functioning MAME driver for the TOA MEL-O-DIX ML-30x series which is due to be released whenever I have time to finish it up. There’s also a program ROM disassembly and internal card modification for that unit. When we are dealing with relatively obscure and obsolete hardware, I hope to be able to help preserve it and contribute back to the community in some way.

Thank you for reading.

  1. Known in the US as JVC ↩︎

  2. Yamaha YM2413 (OPLL) ↩︎

  3. More on that in a future post, maybe? ↩︎

  4. Available here ↩︎

  5. Please never change factory settings like this, unless you know exactly how to calibrate them again! I see people do this all the time with CD and tape transports, CRT monitors, things like that, and it drives me nuts ↩︎

Built with Hugo
Theme Stack designed by Jimmy