Does anyone know anything about the computer above? They appear to be
educational single board computers. A strip along the frond edge, lists a
number of commands to set breakpoints, jump in memory, examine memory, etc.
I found a pile of them at an auction preview. They're single board
computers that are mounted in a wooden boxs that measures roughly 10" x 12"
x 2". The box has a smoke colored plastic lid that's hinged in the back.
When it's closed, everything is covered except for a 3 x 4 keypad. The CPU
board appears to use the Motorola EXOR-bus and has a Motorola 6800 CPU.
There is a smaller card on the RH side that has the keypad and six digit
seven segment LED display. The ICs are dated 1979 and 1980.
These appear to be part of a system. I found several other boxs that
were also made by ASCI. One of them has a micro-cassette drive. Another is
a switch box that switchs between a printer, punch, etc. Another larger box
has relays and a bunch of terminal strips on it. It appears that it's meant
to be controlled from the CPU box and can operate a good number of external
devices.
I need to know what they are before Saturday.
Joe
>the adjacent ones. The BDOS doesn't change, generally, though there may
be
>changes in the BIOS. By finding each sector of the BDOS, one learns
about
>the format of the boot tracks. My CCS system, for example, requires, at
>least for the distributed boot EPROM, that the boot tracks be SSSD.
That
I have a fully documented CCS and it clasifies as the early basic CP/M
bios
of low to average functionality. It's robust but closer to a minimal
example.
>> the key parameters are the DPH, DPB and SKEW... also you need to know
>> how big the sector is and if there is embedded skew within the sector.
>> Then you need to know the disk layout, things like what side/sector
>> numbering was used. For example I've seen two sided media where
>> sector one occured on both sides and where identically formatted, also
>> I've seen side one as 1 thru 9 and side two as 10 through 17...
>>
>These parameters are all there on a boot diskette. It's just necessary
to
>find them.
Not all and they may be very hard to find. DPH, DPB ahve pointers to
them as a result of the BIOS call to Seldisk. The SKEW however may
not be used in the SECTRAN call at all! Often the skew translate is
a table but it can be calculated and for DD the SECTRAN call is applied
at the logical sector level and doesn't apply well for double density who
have sector sizes larger than one logical sector. So skew in that case
will likely be burried in the raw read/write routine. Or possibly even
at the logical sector level inside the the physical sector.
So wome things are not guarenteed and also not easily found.
>The Multidisk and Eset that I have are not for this purpose. They want
to
>be passed the information that I'm suggesting could be extracted.
Oh like I said I can be... but if you know it's easier as even with 33mhz
z180 your going to flog a while getting to the same answer.
>That's exactly the problem I'm trying to circumvent. The interleave,
skew,
>sector size, etc, are all accurately represented on the boot diskette.
The
Ah, no. Most boot sectors are not skewed and like you observed may
not be the same density or sector size.
>BDOS is the BDOS, i.e. shouldn't be different on different boot
diskettes,
Likely but not always true.
>so long as the CP/M version is the same. Consequently, it should be
There were patches and the CP/M version can be misleading. Many of the
clones use base 2.2 ID so apps will run normally, most all are written
using
z80 unique instructions where DRI used only 8080.
>possible, having once determined the sector size, to extract,
automatically,
>the relative locations of sequential sectors of this known file. Since
we
>KNOW and RECOGNIZE the BDOS, shouldn't it be possible to find its
beginning,
BDOS is not part of the CP/M file system! It's in the boot tracks.
>paramters from the system BIOS and verifying them against another known
file
>e.g. PIP.COM, should provide the necessary information about the
directory
>and data areas of the diskette. Isn't that so?
You would be forced to do that and huristically that will be a PITA! PIP
is
in the file system whereas BDOS is out on the boot tracks. the boot
tracks
in the CCS case is SSSD and the system tracks can be DSDD! The bios
entries for DPH, DPB do not say if the disk is DSDD or even if it's
floppy.
It will tell you how many logical sectors per track, If skew is used. If
directory
is checked, allocation size and the size of the area used ofr data
storage.
You will have to figure out from that a lot of things that are variable
and can
still end up as the same answer.
>> >Another item I've wanted for some time to automate is the setup of a
hard
>> >disk BIOS. Since it's dependent not so much on CP/M quirks but often
>more
>> >on decisions made on the basis of folklore, I thought it might be
>> >interesting to examine the process as a candidate for automation.
it's been done but the usual is to hook the disk IO routine and lod a
mini
hard disk bios in high memory. Teltek, Konan and a few others did that.
A better way is to provide slots that can be filled with an address of
the
driver(s). The reason for the difficulty is the wide assortment of
controllers and the varied protocals to talk to them. If it was always
IDE
or SCSI it would be simpler.
>Well, I don't see hand-feeding a set of parameters that one has to
determine
>by guessing on the basis of lots of conflicting folklore as particularly
>easy. Authors who wrote about the process e.g. Laird and Cortesi seemed
to
No folklore. There are detailed tables out there for every drive and
disk going
if one care to look. What do you think Multidisk does/is?
>equivocate considerably about this, and, while it's straightforward to
come
>up with a set of parameters that work, it's not easy to come up with the
>optimal ones, at least where the HD is concerned. Both of the authors I
Optimal ones for hard disk in the timeframe they wrote in was simple.
hard disks are FAST and Z80s (pre 1990) are NOT. No amount of
optimization is possible. Actually if you have banked memory caching
is the solution as it steps neatly around the problems. FYI: the
problem is that CP/M does a lot of realatively small transfer with
lots of references to the directory. the true limiter to performance is
not data rate but latency (mostly from shuffling the head). When Laird
wrote a fast drive was a Quantum D540(31mb MFM 5.25 FH) with a
average latency of around 30mS.
>is in hand, it's easy, certainly, but what should one do, given a known
>bootable but otherwise undefined boot diskette? The reality of the data
>present on a boot diskette defines all the parameters necessary to
recreate
>it, doesn't it?
No. the boot tracks are always written by a specialized utility like
SYSGEN
(which is not generic code) that is always system specific.
>I get emails from people all the time, asking about how to build a boot
>diskette for a system they can't boot because they don't have a BIOS on
the
>diskette for the I/O ports they use.
Most of those I converse with with that set of questions have no sources
to
work from and find 8080 or Z80 asm code scary to terrifying. Often they
dont
know the ports in use nor what they mean. Rare is the one with Docs for
their
system at the time the question is launched. They often think it's just
like a
PC where dos boots on all if the disk fits.
>Likewise, I get frequent questions
>about how to formulate an optimal configuration for a hard disk. While
it
Like Laird said and I'll say _optimal_ for what? I"d never use the word
optimal.
Again, expereince most want a drop in replacement like a PC. Most do not
code at that level or dont wish to try. Many dont have docs needed. So
what
they want is not optimal, just something that works.
>may not be a terrible thing, it is something many people, including
myself,
>though I've done it several times, find daunting. In the absence of a
>rigorous method it's hard to find peace at the end of the task because
so
>many less-than optimal solutions will work quite well. How's a person
to
>determine what's best?
Lesse, I have five systems with hard disks all were added later two with
code supplied. I find peace with the fact that they work and are
reliable.
Only one have I applied rigorous and experimental methods to the extreme
to see what was possible and effective... Occams razor won most often.
Here it is: hard disks and performance. Assume nothing about the hard
disk used rare is the old drive/controller that can really help you. DMA
or a seperate processor will help if the CPU is loaded or memory is
short.
Caching at the track or cylinder level with a LRU method really helps if
you have space (64-128k is good). You will cache(call it host buffer if
you like) anyway as most hard disk have sector sizes larger than 128
bytes requireing deblocking. Caching the directory seperate from
the data area cache really pays as it saves head thrashing. Achieve the
above or subset with direct and efficient code.
I've tried this using a IDE drive (still working the code out) and most
decent over 100mb drive have caching (quantum PRO AT series does).
use it as it isolates you from things like skew and all.
If you using a an old SA4000, forget all this as making it work is
three quarters the battle.
Allison
> > > > Hearing anyone decode the FUBAR makes me twitch.
> > >
> > > Uhmm isn't the computer version Foo bar as in Foo bar
> blatz zam zow
> >
> > On some models of VAX there's a hardware register that
> stores (part of)
> > the address of a Unibus cycle where the selected device failed to
> > respond. This register is called, not suprisingly, the
> >
> > Failed UniBus Address Register
This is certainly serendipitous, but not the origin of the epithet.
FUBAR dates at least to WWII; I read that in an article about tech
terms that we tend to think are recent inventions but which have
been around for a rather long time.
For example, while Grace Murray Hopper is credited with finding
an actual moth wedged in a relay in the Eniac 1 (thus "bug" in
the system), the term "bug" has been found in the writings of
Thomas Edison, referring to a defect in a design.
"HAM", referring to amateur radio operators, is a 19th-century
invention; it was previously used to describe self-taught telegraph
operators.
And "to hack" is supposedly an old Yiddish phrase that refers to
the making of furniture with an axe (and although a different usage,
"hack" has referred to taxis since they were horse-drawn in the
early 1800s).
And on and on...
regards,
-dq
Hello everyone, I realize that VMS 7.2 doesn't meet the 10 year rule but
the hardware it is running on does :-)
To "close the loop" on this one, Zane pointed me to a recent fix posted by
Compaq on their support site for TCPIP V5.0A. This update fixes a bunch of
different bugs. My bug was the Telnet server went berserk when I tried to
connect to it.
The problem is in the WILL/WANT negotiation that goes on gets screwed and
ends up looping infinitely.
You can fix this by installing the TCPIP$TNDRIVER.EXE and TCPIP$TELNET.EXE
images from the fix on top of an existing TCPIP 5.0 installation.
--Chuck
> Uh, where in the Eniac might the relays be? I think you meant
> Mark I...
BTW, I would be surprised to find out that the Eniac didn't
use relays for power distribution... Hell, even the IBM 716
Line Printer I used to have had them for that (it used 220v
3-phase to drive a dynamotor which in turn generated the
50vdc power that was then distributed to the 711 card reader
and perhaps other peripherals).
regards,
-dq
> -----Original Message-----
> From: Will Jennings [mailto:xds_sigma7@hotmail.com]
> Sent: Thursday, October 05, 2000 10:24 AM
> To: classiccmp(a)classiccmp.org
> Subject: RE: FUBAR and DW780
>
>
> Uh, where in the Eniac might the relays be? I think you meant
> Mark I...
>
> Will J
> (now where are my car keys again?)
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
> Uh, where in the Eniac might the relays be? I think you meant
> Mark I...
You are correct... she worked with both systems, the bug was indeed
found in relay #70 on the Mark I.
-dq
Uh, where in the Eniac might the relays be? I think you meant Mark I...
Will J
(now where are my car keys again?)
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
