-----Original Message-----
From: Jim Battle <frustum(a)pacbell.net>
>For instance, the first version of the emulator would convert each
>windows keystroke into an emulated "strobe" of a keystroke register.
>But then my first user noted a discrepancy in a program he tried.
>
>After thinking about it a little bit, we realized that the difference
was
>because the real Sol generates an approximately 6 us strobe when
>a key is hit, asynchronously setting a "key ready" flop. If the
processor
>polls this register, the flop gets cleared, but if it polls it before
the
>6 us strobe is finished, then reading it doesn't clear the flop since
>the async strobe has priority. Thus, one keystroke can appear twice
>in these circumstances.
This is an oddity but remember the 8080 is 2mhz (5us for an INP
insturction)
so this only can occur if the buffer read should occur within 6us of the
status
read. Typically the code is something like this:
keywait: INP status
ani keyflag
JNZ keywait ; back to top may be a JZ
INP keydata
...
The delay from the first input to the second is 10+7+7 (24 cycles or
12uS) if
the J(n)Z is not taken and much more if it is so the race condidtion it
typically
not a problem. It could be if someone was reading keystokes on the fly
something bad can occur but not reading the key pressed status first is
bad programming.
After looking at the drawing It appears the Key ready goes to a JK flop
/K input and is not async as the data (strobe) is loaded on the falling
edge of Phase2 clock. So the behavour observed is unlikely and
the read/clear has precedence. While Phase2 occurs once every
~500ns it is possible to clear and reset making the key buffer hold
what amounts to bounce (read twice). Also the Osc used for the 3uS
clock in the keyboard is a TTL RC thing that likely has a +-25% error
(times two as it's divided by 2) adding to the already long strobe.
In the end it would take a pathological programming case to make
that keyboard behavour show.
>One thing I'm planning on adding is intermittent disk errors -- the
reason
>is that I want to eventually rewrite my CP/M BIOS and I would
>rather test it on the emulator. Without failure simulation, then too
>much of the BIOS would go untested.
The assumption is the bios has error retry, many early bios did not.
You got an error and the system you give you retry or ignore both usually
fatal if bad data was read.
Some of the early 8251 serial (UART) devices had a timing thing
that could cause the reverse action. Never assume all devices
are infinitely fast compared to the cpu.
>Now for an example of behavior I'm not going to bother with.
>The Sol keyboard has infinite key rollover. On my PC, either the
>keyboard or the driver stops giving KEYDOWN messages after
>about four keys are down. Perhaps there is some way to get that
>extra info, but I'm not going to bother. I don't see any reason to
>emulate that extra behavior, so it won't go in.
No it didn't. The encoder may have had Nkey rollover but it was anything
but
infinite. There was at best one byte of buffereing. If you read the
buffer fast
enough you can stay mostly ahead of it but most software of the time
didn't
buffer what it got so the last key read was it.
Allison
At 07:10 PM 1/10/01 -0500, THETechnoid wrote:
>I'm running and have been running OS/2 since I got my first clone PC in
>1992. Never did Windows but for servicing it for others. I just bought
>EcomStation, the latest version of the OS/2 operating system from Serenity
>Systems.
Surely you must see the contradiction is having such an extreme position
on Microsoft and using an OS that was originally written by the same company.
I'm sure it has evolved quite a bit since MS gave up control of it to IBM in
1990, but if you take out the OS/2 box that you were using in 1992 I'll bet
you can still smell Bill's greasy fingers on it.
No, to be really clean, you should be using a different OS. Yes, something
more unix. Ignore these johnnies come lately, go to the true innovator, the
first unix on a PC: run Xenix. Damn. Microsoft did that one too.
Here's a link with a pretty extensive timeline of MS OS developments:
http://www.powerload.fsnet.co.uk/timeline.htm
-----
Jim Battle == frustum(a)pacbell.net
On January 10, Mike Ford wrote:
> >Last summer I picked up a Tek 2230, a 100 MHz two-channel
> >digital storage oscilloscope.
> >
> >I think I'd like to check it checked out by a repair
> >service to confirm whether all its functions are working or not.
>
> Why? I am guessing you will be out $50 to $100, and thats assuming its fine
> and needs no "adjustment".
>
> I would just use it, wouldn't most problems be fairly obvious?
This is a good point, especially with a DSO. Except for the analog
stuff in the very front-end...isolation, maybe a preamp, and some
attenuator hardware...the only things that I can think of in most
simpler DSOs that might require adjustment would be the time base and
the sweep alignment & linearity stuff. Tek DSOs are pretty solid; I'd
bet that, if it's basically functional, it's in good shape.
-Dave McGuire
> On Tue, 9 Jan 2001, Louis Schulman wrote:
>
> > OK, here is a very elementary question that has always
> > stumped me. Is there any difference between an external
> > SCSI hard drive made for a Mac and a generic SCSI hard
> > drive? Can I hook up a Mac SCSI hard drive to some other
> > computer with a SCSI interface and expect it to work (after
> > formatting, of course)? What about the other way around?
>
> The first alternative works very well indeed. The second won't, though.
> Macs use hard drives with a particular Apple firmware, without which HD SC
> Utility won't recognise the drive. Bloody stupid. Another Apple
> peculiarity would be its lack of support for remote start in
> SCSI, so the hard drives will need to jumpered for automatic start on
> power, but this won't affect other systems.
Non-Apple drives work quite well with Macs; however, while your
observation about the use of Apple's HD SC Utility is correct,
all non-Apple SCSI drives sold *FOR* the Mac come with their
own SCSI setup utility.
For a SCSI drive *NOT* sold _for_ a Mac, you'd need a third-party
toolkit like FWB' Hard Disk Tools (or whatever it's called). I've
used it to add IBM and DEC SCSI drives to a Mac.
regards,
-dq
On Jan 10, 16:09, Lawrence Walker wrote:
> One of my ST mouses (mice ?) has a simple switch to change it
> to an Amiga mouse. I also have a Kraft joystick with DE9 and
> DB15 connectors and a switch to change between Apple IIe and
> PC. There was a box from Practical Peripherals called Mouse-
> Master to switch between STs and Amigas. Seems like it shouldn't
> be too difficult to make an all-purpose connection box for different
> platforms. I also have a 4+4-input 1+1 output ABCD box, to use a
> single mouse and K-B with multiple systems, that are readily
> available, which would simplify the project. Any "gotcha's" in this
> scenario ?
The obvious one is the protocol. Or rather protocols, since there are so
many. PS/2, PC serial, SGI serial, etc are all different. However, if
you're talking about basic quadrature mice that simply output X, X', Y, and
Y' pulses, your idea should work. Add a PIC and some software and you
could handle the other types, too.
--
Pete Peter Turnbull
Network Manager
Dept. of Computer Science
University of York
Hello, here is someone looking to get rid of some stuff! Please respond
directly to him. Best, David
David Greelish
Publisher
Classic Computing Press
www.classiccomputing.com
From: scott(a)aptest.com (D. Scott Secor)
I was curious whether you might know of a deserving organization that would
want a Solbourne model 6/500 (Sun workalike) dual processor server in
roll-around cabinet. Processor boards were checked by Grumman two years ago
after system was taken out of service. Original cost in early 1990's was over
$60K.
Regards,
Scott Secor
secor(a)mn.rr.com
y2k(a)uswest.net
While mulling over some ideas for software music synthesiser programs [I
just bought a copy of Reaktor - a software synth/sampler construction kit
of amazing complexity] I started wondering just how close to 'real' an
emulator ought to be. For example, the MiniMoog emulator has a replica of
the add-on A-400 oscillator, used to tune your Moog back up as it drifted
off pitch, which they all did more or less constantly. The documentation
mentions retaining this feature even though the emulation no longer
drifts.
But: why not? Shouldn't it drift, actually?
So I ask from a "purist's purist" view... shouldn't an emulator contain
"failure modes" common to the machine emulated? And if it "breaks", then
the poor "operator" is afforded the opportunity to diagnose and then
(hopefully) "fix" the problem.
My experience with the various PDP-11 systems I owned was like this. I
spent a *lot* of time doctoring the hardware.
The same thought could be applied to a software Moog Modular synthesiser
system. If a module 'breaks', you have to open up the code, find the
'defective' module and 'fix' it. One could continue this thought right
down to having models of components, a la SPICE and the other design
modelling software. Each component or module would then have a live/die
algorithm associated with it.
Imagine how thrilled Tony Duell would be with a PERQ emulator that
exhibited random 'hardware' failure modes (based on maintenance histories)
that then needed to be repaired at the 'component' level. Running, of
couse, on a palmtop.
Hopefully one could as well disable the "real-world hardware failure"
mode, in the case of wanting to just do something trivial, like program
the thing.
Silly questions, but also maybe valid....
Cheerz
John
> > > The first alternative works very well indeed. The second won't,
though.
> > > Macs use hard drives with a particular Apple firmware, without which
HD SC
> > > Utility won't recognise the drive. Bloody stupid. Another Apple
> > > peculiarity would be its lack of support for remote start in
> > > SCSI, so the hard drives will need to jumpered for automatic start on
> > > power, but this won't affect other systems.
> >
> > Non-Apple drives work quite well with Macs; however, while your
> > observation about the use of Apple's HD SC Utility is correct,
> > all non-Apple SCSI drives sold *FOR* the Mac come with their
> > own SCSI setup utility.
>
> Granted, I forgot to mention that there are other SCSI setup utilities,
> but why in the world would one need to buy a drive /for/ a particular
> brand of computer? A hard drive is a hard drive is a hard drive.
Because the computer manufacturer's engineers, in their infinite wisdom,
decided their computer needed feature <X>...
For Pr1me minis, hard drives have to be able to support a sector size
of 2080 bytes, instead of or in addition to the usual 512-byte sector
support. With Apple, their *first* hard drive (a non-SCSI unit) had
things called disk tags that required drives that support a sector
size of 576 bytes (from memory, probably wrong).
I'm not defending the practice; while I assumed your remark was
rhetorical, not everyone in the audience may be as well-informed
as we are.
> > For a SCSI drive *NOT* sold _for_ a Mac, you'd need a third-party
> > toolkit like FWB' Hard Disk Tools (or whatever it's called). I've
> > used it to add IBM and DEC SCSI drives to a Mac.
>
> I've got an Apple-edition IBM drive in a IIcx here. =)
I've got one of those, too, and it looks *just* like the
non-Apple edition. Scary...
-dq
In a message dated 1/10/01 2:12:24 AM Eastern Standard Time,
THETechnoid(a)home.com writes:
<< A recent message mentioned that the Laser 128 has an expansion port which
can use Apple II cards. Is this accurate?
If so, I think I'll dig my laser out and dog the hell out of it. I had no
idea.
BTW, anyone got a scsi card for Apple II they don't want or need?
Regards, >>
You are supposed to run the laser expansion box off that slot connector, but
one time long ago i desperately needed another drive on my laser so i plugged
in my disk ][ controller and it worked! its not very pretty hanging off the
side, but its worth a try. anyway, i'm keeping my scsi card...
At 00:35 10-01-2001 -0500, THETechnoid wrote:
<long, pointless rant snipped>
And this is related to classic computers, how?
Despite the fact that I have no great love for M$ myself, I'm going to
limit my comments to this.
If you want to expend time and effort venting against Billy-boy and the
Redmondians, please put up a web page or something. I have far more
important things I choose to concentrate on -- AND read about on this group.
*PLONK!*
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bruce Lane, Owner and head honcho, Blue Feather Technologies
http://www.bluefeathertech.com // E-mail: kyrrin(a)bluefeathertech.com
Amateur Radio: WD6EOS since Dec. '77 (Extra class as of June-2K)
"I'll get a life when someone demonstrates to me that it would be
superior to what I have now..." (Gym Z. Quirk, aka Taki Kogoma).
