Re: working on Apple ][ emulator, need volunteers

On Aug 15, 9:52 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
Gate-level simulation may also include routing and transport delays of
gates themselves usually in the form of min/typ/max. So, this is close
to a "cheap" first-approximation quazi-analog simulation.

True. For a design already known to work, this analysis is unnecessary.
Only the logic equations need to be evaluated, and even then, only the
ones whose terms have changed. This is where static compilation is a
huge win.

Last time I played with a Verilog compiler it produced 'C' code (best
optimized on any host) that still represented the normal processing -
handling event queues. Looked a lot like macro-generated and
performance was not that great, although ahead of the interpretive.
Very similar to compiled AppleSoft approach.

Current high-end state-of-the-art compilers should do much better work
at utilizing modern computing facilities, but I don't have access to
any.

Certainly, for anything of the net complexity of the Apple II's, static
timing analysis is more than adequate. Of course, there are a couple
of places (pointed out by Sather) where the Apple II design misses the
spec'ed setup and hold times...but it works. ;-)

I guess that after speccing produced samples from various lots they
put a safety margin. What about the usual 1.2? :-)

Given the hierarchical nature of Apple II address decoding, I'd
expect compiled simulation to be relatively fast--since the only
conditions that must be reevaluated on each cycle are the ones that
change, and most can be ruled out in a CASE statement or very few tests.

It's not only the decoding. Main clock is 14Mhz and there are enough
signals toggling in a bus cycle (14 or 16 clocks). Video itself has
enough circuitry clocked at 14 Mhz. All this compiled from Verilog
will make for enough load to exceed realtime on today's PC ... IMHO.
Overhead is quite big from toggling a signal in equation to processing
the event queues to C code calling C libraries.

I agree about posting--Google always seems to line-wrap early,
and now that there's no "preview" function, its easy to create
a messy post.

There's even more - you have tiny little window, proportional fonts,
you have to login everytime, you have to use mouse, and best of all -
there's some expiration time. So, after answering a lengthy message
and clicking "Send" you just receive "Session expired" error and there
begins the battle of saving the long answers and transferring them to
a freshly opened new page to paste there.

You'll note, however, that a "guaranteed adequate" capture is pretty
large unless provably pruneable for each particular program.

I know how large it is going to be with all 0.25 tracks included. As
you said in that long thread, it's nothing for current standards and
that's required only for the protected titles. All other stuff lives
happily in DSK.

While the big image can be pruned, it's really not necessary unless
someone has extra time and motivation.

What do you think that the Apple II controller cannot be used to
capture? The length of each nibble can be determined within one
bit time, and "weak" bits can be distinguished from "strong" bits.
Relative track synchronization can be determined. What's missing?

Giving exact technical details will require analyzing again all
documentation, but I think it was a mixture of resolution, no hole
index signal, the sequencer prolonging nibble with high bit for some
additional cycles and the speed at which 6502 can react to a change. I
can be wrong, so that's why the reward was proposed. Sorry, I have
vague memory of conclusion paths, only remember the conclusion itself
(takes few bits only).

Some approach I can think of is runtime construction of code to
analyze a track, with execution time of the "analyzing" code constant
close to a revolution time, but then the constructor also has to have
constant time. And then it gets really hairy ...

FDI is designed to be multiplatform and universal, so Apple ][ is just
a fraction.

But most "dimensions" of the FDI comes into play with one or another
Apple copy protection scheme. It isn't its versatility that I was
talking about, but what it represents about the signals readable from
the disk.

What I meant was that FDI has extra resolution that is unnecessary for
Apple ][. Smaller files won't hurt, especially if hardware emulation
is to be done (RAM is limited).

With Disk ][ outputting pulses of 1usec spaced no closer than 4usec
apart, then additionaly shaped and passing through Woz-sequencer, how
much resolution and information is really needed?

Well, you potentially need that information for each quarter track
(since you don't know which quarter tracks are valid), and you need
to know which bits are "strong" (read solidly from one read to another)
and which are "weak" (read differently on different reads--usually
because of no recorded transitions on the media).

Quarter tracks for sure. But for media data we can stick to 250kbit/s.
Also, I think there's no need to store "weak" and "strong" bits -
after getting enough revolutions' data simple processing will tell
which are which. Then only "strong" bits are recorded (this is sure
flux change) and other are just skipped. Getting random or "weak" bits
is more a function of the drive itself and is emulator's obligation
therefore.

Here's my proposal for media image format:
0) global track length TLEN in bits (5000 +/- small %)
1) TLEN bits per track, synchronized to a virtual index hole:
0 represents no flux change
1 represents flux change
2) every track is tagged with physical position (0, 0.25, 0.50,
0.75, $17, 35, ....)
3) if necessary, tracks with TLEN bits describing media damage can
be included:
0 media ok
1 media damaged
4) data track can have reference to media damage track if necessary

written in pseudo C:

struct disk2_media {
int tlen;

char *data[MAXTRK]; // points to media data
int phys; // physical position * 4
int dmg; // damage track index if necessary

char *damage[MAXTRK]; // points media damage
};

File size is variable and depending on human intervention can get
quite small. Media damage tracks will be used very rarely (<1%?) and
for selected tracks only.

Well I can guarantee that if you use some non-Apple method, there
will never be much help! Removing obstacles is the name of the game.

I know this, but imagine the other thing - until recently I couldn't
find even working clone. And here we don't have access to serial
cards, so even if I could get some image on the clone, I cannot
transfer it to the PC. I believe this is not so uncommon.

Such a protected game would have to be run without write protection
in any case, but the capturing "physical damage" information is both
potentially damaging and exceedingly rare in the Apple II world, so
I wouldn't bother with it--those programs would have to be "special-
cased".

My thought exactly - requires human analysis and providing extra
information unavailable by non-desctructive means.

Correct--so the "weak"/"strong" determination must be made at the
time of capture of the image.

Yes, and this just gives the clean bit-stream recorded. The other
layer is noise generated by the amplifier in bit sensing chip
(MCxxxx).

It is possible to use the Disk II controller to erase selective regions,
thus restoring "weak" status if required (though I know you aren't
interested in re-creating real protected disks).

If we ignore track width and close tracks for a moment, I think that
writing a whole track is easy on Apple ][:

1) position to a new track in exactly 1/5 second
2) while (N--)
write_data_latch (data); // on exactly every 32 cycles
3) goto 1

"data" is just every next 8 bits of data, totally unrelated to
nibbles. One can write any 8 bits of data, provided they are spaced 32
cycles apart.

In the previous thread, we identified just two mechanisms that could
not be re-created by writing on a Disk II: physically damaged media,
and disks written with a wider than normal head.

First is still doable, but with a lot of extra information. If there's
only one "hole" on a disk, it can be created manually (or by attached
laser in drive) and after putting it into the right track software
will sync to the hole and write rest of disk accordingly.

Latter problem I haven't investigated that much.

.

Relevant Pages

  • Re: Deleting data from a HP 3000 disk drives
    ... >> Purging information is a media sanitization process that protects ... > Unless your ATA disk has a firmware secure wipe function, ... > sight of everything but the drives firmware, ...
    (comp.sys.hp.mpe)
  • Re: Running Protext
    ... My Brother laser printer is so old I did not think it had a usb connector, ... The printer is recognised by media edition and works ... the cd disk as it does on the other computer. ... Ken Blake - Microsoft MVP Windows: ...
    (microsoft.public.windowsxp.general)
  • Re: Good source for "new" 5.25 and 3.5 inch floppy disks?
    ... HD media in DD 3.5" drives should be avoided. ... HD 5.25" disk in an AppleDisk 5.25" drive: ... Would NOT format without errors, would not read or write data. ...
    (comp.sys.apple2)
  • Re: LinkSys Media Center Extender disconnection, error code 000100
    ... I setup the computer again with Basic Disk and the Extender is working OK. ... the media center pc the following event are logs. ... Barb Bowman ...
    (microsoft.public.windows.mediacenter)