Eric Stanley recently told me that he was having problems with a program which he runs from an Eprom pak. The program includes a copy of the MZ-700 ROM Monitor and, when the program is running, the ROM Monitor code is correctly located; but it is in RAM. Eric was finding that tapes saved by this program would not load back into the ROM Monitor itself. After some research, I discovered the reasons, which I explained to Eric in the following letter:-

“On the MZ-700, tapes saved by Monitor routines in RAM may not reload via the ROM Monitor because of the differences in the timing - RAM runs faster than ROM. I know this sounds daft, as the CPU clock runs at the same speed, but the MZ-700 ROM controller inserts 1 WAIT STATE PER INSTRUCTION to allow for slow eproms. Taking the routine DLY1 at $0759 in the ROM Monitor as an example, in RAM it takes 14 x 21 clock pulses ( = 294 x 0.282µS = 83µS ); but in ROM, with 4 added wait states per loop, it takes 18 x 21 clock pulses ( = 378 x 0.282µS = 106.6µS Q.E.D. ). In other words, for the identical routine, the delay in RAM is 14/18 of the delay in RAM.

Now, in the Sharp tape system a ‘long‘ pulse ( 100% ) is twice the length of a 'short' pulse ( 50% ). The sampling routine is triggered by the leading edge of a pulse and then waits for 75% of a ‘long' interval before taking a sample. A 'short' pulse is therefore sampled as LOW, but a 'long‘ pulse samples as HIGH.

But if the tape has been saved by the same routine in RAM, its pulse lengths will all be reduced to 14/18 = 78% of what they should be; so there is a distinct possibility that, due to something as simple as a fluctuation in tape speed, a 'long‘ pulse will be sampled as a 'short' one, and thus give a checksum error."

The remedy is to lengthen the delay loops when the tape routines are running in RAM, by a factor of 18/14. The locations are:-

In the course of sorting out this problem I came across several related items of interest. For example, S-BASIC and K&P DBASIC have their own tape routines in RAM, which are very different from the tape routines in ROM. On the other hand, the Sharp disk Basics 2Z-009E and 5Z-008 do not have tape routines of their own - they bank-switch the ROM Monitor back in as required! And the MZ-700 Monitor ROM in the MZ-800, which allows the MZ-800 to simulate the MZ-700, has its delay loop counters increased by exactly 18/14 - from which I deduce that the MZ-800 ROM does NOT employ wait states; furthermore, I am pretty certain that the MZ-800 Basics, like 2Z-009E and 5Z-008, bank-switch to Monitor tape routines.

And then there is the general point that the 'sampling‘ method, being very flexible, does allow a lot of latitude between tapes from different machines ( but not as much as 78%! ). I hope to explore all these topics more fully, in time for the next issue; but my provisional conclusion is that this particular ROM / RAM tape problem really is peculiar to the MZ-700.