Re: working on Apple ][ emulator, need volunteers

vladitx wrote:
On Aug 17, 8:49 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:

I realize that most specs are "nominal", but I'm actually surprised
that they routinely provide more margin than required by the accuracy
of their testers.


On the N-dimensional plane of frequency, power supply, temperature,
etc. where the set of points is experimentally measured, one would
better leave some margin to be sure that timing is within limits. If
it was me, I'd play it safe and put reasonably pesimistic values. Note
that I am talking about characterization of limits that are function
of N variables.

I get your point. Since most ICs run relatively near room temperature,
and near correct Vcc, yet are spec'ed for up to 70C and up to 10% lower
Vcc, there would normally be a fair amount of margin...

Does that also mean that any microprocessor will run reliably at its
spec'ed clock frequency + 20%? (I think I've found some exceptions
to that rule. ;-)


Any .. hardly. Some don't work at all even at nominal clock ... ;-)
But you know how much a desktop CPU is overclockable with a good power
supply and careful cooling - way over 20%.

I suppose I always regarded this as a function of good luck, whether
or not the maufacturer binned parts, and how close together the bins
were...

That's interesting, since some specs are not just limits, but
the actual values could be important to a design.


Yes, they're different thing, like for example output capacitance or
oscillator's frequency and duty ratio. But then again you have to
specify tolerance, and here's another place for some safe margins.


I remember a case where we designed a system with an external
cache memory (SRAM), and we saw that the system could run with
a much faster clock if the cache were wave-pipelined--by driving
the next address to the cache even before the old data was clocked
into the machine. This required a *minimum* access time spec, and
we found several manufacturers who were willing to commit to such
a spec. ;-)


Not that uncommon probably, but this design became particularly locked
to some generation of memories of certain manufacturer from a certain
fab. What if they went to next technology and this time shortened to
1/4th?

Fortunately, the product cycle for workstations was well within a
single semiconductor process generation. ;-)

For the next design, we bumped up the clock speed, of course.

So, should I expect that all lower limits are spec'ed 20% lower
than the lowest actuals and upper limits are spec'ed 20% higher
than the highest actuals?


No, didn't mean to imply this. I don't have insight for practical
values and surely they vary wildly between manufacturers/technologies/
products, but as some speed spec limits are being characterized at
corner cases like high temperature and low power supply, I'd
fearlessly violate them by a small percentage.

As to the example 20% given - it's just constant I like.

Sounds right. ;-)

Right, but I was arguing that in a proven design, no timing analysis
is needed or useful, only logic simulation.


Maybe this is the reason we don't know about a powerful logic-only
simulator ... at least me. Proven design implies product already
sells, and who will want to simulate it's logic only anyway.

Actually, this situation used to come up all the time. When bringing
up a new system, the logic design (and simulation) can always be ready
long before qualified prototype silicon, so the OS folks would bring
up the system on a logic simulator, prior to first silicon, and be
ready to go when the chip came out of fab.

For this purpose, a compiled logic simulation was *much* faster than
the timing simulations used by the chip designers, making it practical
to, for example, boot the OS on the simulator.

Of course, there were even higher level functional simulators, but
they were basically architectural simulators that didn't simulate
the actual logic implementations of particular chips/systems. They
were, of course, much faster yet.

If trying to do sync only by software on Apple ][, what if the data on
track is not the standard layout with 16 sectors? What pattern you're
going to use for reliable syncing? Can it be really accurate?

Any unique, stable pattern--which is not a practical problem.


And what that pattern may be?

I had a thought - if imaging was possible on the bare Apple ][ and you
can get the bitstream of all tracks synchronized to each other, and
because you can write any data easily (head width aside...), then why
such a program was not created in the 80s? I remember trying several
popular bitcopiers to autocopy certain disks and they just couldn't.
And what was the reason behind parameters - human guidance because
machine alone cannot deduce all information. So, isn't there something
missing?

I suspect what was missing was enough development of the right kind.

Bit copiers developed in an evolutionary way, with relatively few
"fresh starts".

If one started from first principles, then I think it would be possible
to fully characterize a disk using an Apple II and the Disk ][
controller. Whether that would also be enough to then write a copy
of the disk is a little different, since some (closer than 3/4 track)
tracks must be "fractionally" written to preserve adjacent track data.

Now, suppose you sync reliably on a certain spot of a track. Next you
have to image the next track relatively to that spot and best you can
do is move the head in some exact timed loop. This loop has to be
carefully calculated to be equal to track length time. But if you move
35 tracks away any small additive error will get multiplied
reasonably.

The time would not be a full track length--it would be the amount
of time to get to where the next track (or track fragment) should
start. This would be done with a fixed time seek (usually only
two steps (or less)) followed by a programmed time delay.

Ideally all tracks would be sync'ed to the track that was used by
the program to check sync, but that, of course, is knowable only
by analysis of the program. An excellent substitute would be to
sync tracks to adjacent tracks, so that the speed variation between
rotations would be minimal.

Angle errors are still cumulative, so an occasional check against,
say track 0 or track $11 would be appropriate to assess actual
drive performance. If a drive's speed wanders too much, it would
be best to use a drive with tighter speed control.

Practically, it's not a problem - original software should
work also with tolerance. So far, so good. But what if some track
starts with weak bits or in-between nibble? Some jitter will occur,
but hopefully after few passes (and knowing track length) software can
decide 1s and 0s.
Is this overly optimistic? Do I miss something? And how much that
pattern recognition is viable?

In practice, it should not be difficult to find a several-nibble pattern
of unique, stable data. The track "start" is not this pattern, in
general, but must be determined by finding track length accurately
and a suitably long region of (apparent) sync nibbles for the "splice".

This is a potential ambiguity, since I have seen examples of protected
disks that had regions of apparent sync nibbles which were actually
counted, and required a very tight tolerance. To reproduce this on
an Apple would take multiple tries, with actual track length being
verified between tries--could take a while to get right!

It can be at least as accurate as the response of a phototransistor
looking through a hole! It's sync'ed to the recorded data within
a few microseconds. I'd expect the rotational jitter to be much
greater--in the millisecond range.


It's interesting to compare bitstreams captured from disk RD signal
and from Apple ][ software. I suspect some surprises and
enlightenment, at least to myself.

That would be interesting.

Of course subsequent data is safe - it does it very neatly. :-)
For me the problem is that you can check the latch at various times,
and being "elongated" in time decreases precision.

Think about the cases--all information about the timing of the
recorded transitions can be deduced accurately, there is no loss.


Maybe. Give me few months to turn attention to Disk ][ and we'll have
practical results to discuss.

Okay.

You can actually watch sync being achieved by doing multiple, closely
spaced reads of the shift register. It is only necessary to read the
register about every 16us to see the partial and final bit patterns,
and intervening zeros can be deduced from timing.


I thought about this but the bandwidth is tricky. Again, let's return
to this later...

This multi-read routine is pretty dedicated--I've used generated in-line
code for this, but it takes up a fair amount of memory! ;-)

Multiple reads will reveal exactly which "transitions" are stable and
which are not, so the exact recorded data can be discovered.


If there is any stable, unique data pattern on the track, that serves
as the reference point for all other data. This is the process of
determing "track start". It is also the natural point for determining
relative track synchronization.


BTW, what is the official tolerance on rotation speed and what is a
practical one, by experience?

I looked this spec up a few years ago, and IIRC, it was a few percent.
I've had drives that showed that much variation on each rotation!
(The drive belts had been in one position for years, and had become
somewhat stiff. With use, they became somewhat better.)

Modern half-height direct-drive drives should be quite good.

An interesting non-clone clone. ;-) Most of the clones I have seen
were practically 1:1 duplications of the ][ / ][+, and I have never
seen a clone of the //e, though I have heard of them.


It's called Pravetz-8C. Actually has UART footprint on motherboard
(it's all-in-one), but is rarely populated. I think it's using
derivative of 8250 on 1.8MHz clock. IOU and MMU are cloned, too, with
a different pinout and small twists. ROM is a little bit different,
too. Main advantage is that it handles CTRL+F2+RESET much nicely -
dumps you to Monitor.

A lot of people were annoyed by the //e ROM's habit of tromping on
memory on a reset. ;-)

If it came to it, it would not be difficult to substitute the speaker
toggle for the cassette toggle as an output from the Apple/clone, and
joystick compatibility would require that the pushbutton inputs be
implemented for input to the Apple (as any game port communication
program would expect). There's a little fiddling to do to simulate
an annunciator with the speaker toggle, but it could be done. ;-)


No, for fiddling I prefer capturing raw bitstream directly from Disk ]
[. And then maybe attempt software approach because image will be
known and can be compared. Thinking about data transfer with PC
requires first two steps to be done. :-)

Good luck!

-michael

NadaNet file server for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Loading