3 ms·

That original emulation was actually in microcode; and it wasn't quite 100% compatible with all the options and extensions that were possible for the 1401 (exam

That original emulation was actually in microcode; and it wasn't quite 100% compatible with all the options and extensions that were possible for the 1401 (example: multiply and divide hardware was optional on the 1401). Seems to me that pure software emulators (like the one written in BAL, mentioned below) would not be subject to any particular kind of Y2K problem. I think it was more of a problem of having very old 'working' legacy code that nobody wanted to touch anymore. If one had the expertise, one could in principle do Y2K fixes to (original) 1401 autocoder code. There is excellent work by Ken Shirriff e.g. http://www.righto.com/2019/01/accounting-machines-ibm-1403-and-why.html http://www.righto.com/2019/01/accounting-machines-ibm-1403-a... that has much 1401 detail.

lucas_membrane 8y ago
>> If one had the expertise, one could in principle do Y2K fixes to (original) 1401 autocoder code << By 1999 there were so many generations of 360 programs that read and wrote the same files as the 1401 code that any changes to record formats (e.g. 4-digit years) would have been very impractical. The worse date rollover for the 1401 code came in April of 1983, when months since 1900 reached 1000. Stuff like that mostly got fixed with overpunches, but some of the record layouts were running out of places to overpunch. I read that page by Ken Shirriff when it was posted somewhere a few weeks ago. Very informative. > multiply and divide hardware was optional on the 1401 Weren't both floating point (wobbly precision) and packed fixed decimal each extra-cost options on the first 360's?