25 Jul
2010
25 Jul
'10
8:50 p.m.
I'm working with an old data sample (ca. 1979) to a piece of
equipment that I do not have access to. I've identified some bits
and pieces of code and am trying to identify the processor.
Here's what I know. The processor is big-endian and appears to be
byte-addressable. The opcode for CALL appears to be D3 xx xx, where
xxxx is the address of the destination. 2C appears to be load
immediate instruction and is also 3 bytes long.
The code doesn't look tight enough to be a p-code implementation of
any sort.
Does this ring any bells to anyone?
--Chuck
26 Jul
26 Jul
7:52 a.m.
New subject: More on mystery system
I'm plowing throught the 6 or so hard-sector floppies that I have
from this thing and I ran across a few ASCII text
strings. Here's
the largest one and perhaps it furnishes a clue to what
I've got:
---------------------------------------------------------------------
* INSTRUMENT CONTROL SUBROUTINE
*
* FAIRCHILD SERIES 70/76
*
* WAVETEK 172A FUNCTION GENERATOR
SUBROUTINE SETUP,FG_2 SHAPE @1:C,DC_OFFSET @2:S,MODE @3:C
SET @1="W172A-2; 15/MAY/83";
IEEE_SEND(1:7)"S", at 1,"I";
B DECLARE S:0,I:0,C:0;
SET LC0 = "2";
SET LC0 = "1";
SET LC1 = "2";
* ( ISSUE 26 APR 1981 ) *
OUTPUT /LC3 "SHAPE:", at 1/;
OUTPUT /LC3 "MODE:", at 3/;
SET @1="W172A-2;
--------------------------------------------------------------------
It would seem that I'm dealing with something from an old piece of
ATE equipment. Does "Fairchild Series 70/76" conjure up any
memories? Does anyone have a clue to what processor this thing might
have used?
Thanks,
Chuck
10:14 a.m.
New subject: More on mystery system
On 2010 Jul 26, at 7:52 AM, Chuck Guzis wrote:
I'm plowing throught the 6 or so hard-sector
floppies that I have
from this thing and I ran across a few ASCII text strings. Here's
the largest one and perhaps it furnishes a clue to what I've got:
---------------------------------------------------------------------
* INSTRUMENT CONTROL SUBROUTINE
*
* FAIRCHILD SERIES 70/76
*
* WAVETEK 172A FUNCTION GENERATOR
SUBROUTINE SETUP,FG_2 SHAPE @1:C,DC_OFFSET @2:S,MODE @3:C
SET @1="W172A-2; 15/MAY/83";
IEEE_SEND(1:7)"S", at 1,"I";
B DECLARE S:0,I:0,C:0;
SET LC0 = "2";
SET LC0 = "1";
SET LC1 = "2";
* ( ISSUE 26 APR 1981 ) *
OUTPUT /LC3 "SHAPE:", at 1/;
OUTPUT /LC3 "MODE:", at 3/;
SET @1="W172A-2;
--------------------------------------------------------------------
It would seem that I'm dealing with something from an old piece of
ATE equipment. Does "Fairchild Series 70/76" conjure up any
memories? Does anyone have a clue to what processor this thing might
have used?
I scanned the Osborne book, didn't spot anything with a D3 opcode for
branch/jump/call.
Stating the obvious by this point perhaps, but considering the function
and the "IEEE_SEND", I would suspect some HP computer being used as an
HPIB/IEEE-bus instrument controller.
10:55 a.m.
New subject: More on mystery system
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Brent Hilpert
Sent: Monday, July 26, 2010 10:15 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: More on mystery system
On 2010 Jul 26, at 7:52 AM, Chuck Guzis wrote:
IMHO HP would NOT use the term "IEEE_SEND" but rather "HPIB_SEND".
Branding, branding, branding....
I'm plowing throught the 6 or so hard-sector
floppies that I have
from this thing and I ran across a few ASCII text strings. Here's
the largest one and perhaps it furnishes a clue to what I've got:
---------------------------------------------------------------------
* INSTRUMENT CONTROL SUBROUTINE
*
* FAIRCHILD SERIES 70/76
*
* WAVETEK 172A FUNCTION GENERATOR
SUBROUTINE SETUP,FG_2 SHAPE @1:C,DC_OFFSET @2:S,MODE @3:C
SET @1="W172A-2; 15/MAY/83";
IEEE_SEND(1:7)"S", at 1,"I";
B DECLARE S:0,I:0,C:0;
SET LC0 = "2";
SET LC0 = "1";
SET LC1 = "2";
* ( ISSUE 26 APR 1981 ) *
OUTPUT /LC3 "SHAPE:", at 1/;
OUTPUT /LC3 "MODE:", at 3/;
SET @1="W172A-2;
--------------------------------------------------------------------
It would seem that I'm dealing with something from an old piece of
ATE equipment. Does "Fairchild Series 70/76" conjure up any
memories? Does anyone have a clue to what processor this thing might
have used?
I scanned the Osborne book, didn't spot anything with a D3 opcode for
branch/jump/call.
Stating the obvious by this point perhaps, but considering the function
and the "IEEE_SEND", I would suspect some HP computer being used as an
HPIB/IEEE-bus instrument controller.
10:57 a.m.
New subject: More on mystery system
On 26 Jul 2010 at 10:14, Brent Hilpert wrote:
Stating the obvious by this point perhaps, but
considering the
function and the "IEEE_SEND", I would suspect some HP computer being
used as an HPIB/IEEE-bus instrument controller.
It doesn't correspond to anything that I can identify, including a
PDP11. I'm hoping that some HP aficionado will save me the time of
plowing through a bunch of HP reference manuals trying to identify
this thing.
Again, it might not be HP at all, but the GPIB references may be a
clue.
--Chuck
12:14 p.m.
New subject: More on mystery system
On 26 Jul 2010 at 10:14, Brent Hilpert wrote:
For the reason already stated (HP would call it 'HPIB', not 'GPIB' or
'IEEE')_, I doubt it's an HP machine. Although to be honest, HP tended to
just use a SEND command unless it as an HP9830 when it was CMD.
In 1979, most small HPs used either BASIC or HPL, and your code fragment
looks like neither. And the instrucuiton set doesn't look like any HP
procesor I've ever seen.
Could it be a custom Farichild processor?
-tony
Stating the obvious by this point perhaps, but
considering the
function and the "IEEE_SEND", I would suspect some HP computer being
used as an HPIB/IEEE-bus instrument controller.
It doesn't correspond to anything that I can identify, including a
PDP11. I'm hoping that some HP aficionado will save me the time of
plowing through a bunch of HP reference manuals trying to identify
this thing.
1:20 p.m.
New subject: More on mystery system
On 26 Jul 2010 at 20:14, Tony Duell wrote:
Could it be a custom Farichild processor?
I'm hoping that it isn't, but have no way of knowing. I did check
the Fairchild 9440/DG Nova reference also, and it doesn't fit. It
could also be a small mini, such as a Varian or GA. For yucks, I
checked out the F8 as well, but it would have been way underpowered
for something like this.
Just hoping that someone might recognize it. There's zip out on the
web for this thing.
The curious thing is that, but for a twist of fate, I might have been
the one who ended up writing the code for this beast. I used to run
into my old CDC boss, Fred Laccabue, at the De La Cruz Deli from time
to time and he lobbied pretty hard to get me to join him over at
Fairchild. Promised me my own VAX, he did. I couldn't see myself
making a career out of ATE, however. Fred probably made out okay
when Schlumberger bought Fairchild.
--Chuck
1:33 p.m.
New subject: More on mystery system
On Mon, 26 Jul 2010, Chuck Guzis wrote:
Date: Mon, 26 Jul 2010 13:20:33 -0700
From: Chuck Guzis <cclist at sydex.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: More on mystery system
On 26 Jul 2010 at 20:14, Tony Duell wrote:
A Sentry ATE system processor? (24 bits)
Peter Wallace
Could it be a custom Farichild processor?
I'm hoping that it isn't, but have no way of knowing. I did check
the Fairchild 9440/DG Nova reference also, and it doesn't fit. It
could also be a small mini, such as a Varian or GA. For yucks, I
checked out the F8 as well, but it would have been way underpowered
for something like this.
Just hoping that someone might recognize it. There's zip out on the
web for this thing.
The curious thing is that, but for a twist of fate, I might have been
the one who ended up writing the code for this beast. I used to run
into my old CDC boss, Fred Laccabue, at the De La Cruz Deli from time
to time and he lobbied pretty hard to get me to join him over at
Fairchild. Promised me my own VAX, he did. I couldn't see myself
making a career out of ATE, however. Fred probably made out okay
when Schlumberger bought Fairchild.
--Chuck
1:51 p.m.
New subject: More on mystery system
On 26 Jul 2010 at 13:33, Peter C. Wallace wrote:
A Sentry ATE system processor? (24 bits)
Hmm...that might fit what I'm seeing! If that were the case, then
would 16-bit addresses and 24-bit instruction words fit?
Does anyone have any documentation on this processor or its software?
Thanks!
Chuck
2:12 p.m.
New subject: More on mystery system
On 2010 Jul 26, at 10:55 AM, Ian King wrote:
IMHO HP would NOT use the term "IEEE_SEND"
but rather "HPIB_SEND".
Branding, branding, branding...
On 2010 Jul 26, at 12:14 PM, Tony Duell wrote:
For the reason already stated (HP would call it
'HPIB', not 'GPIB' or
'IEEE')_, I doubt it's an HP machine. Although to be honest, HP tended
to
just use a SEND command unless it as an HP9830 when it was CMD.
HP may well not have used the IEEE ref, but I would think the code was
more likely written by the end customer or the assembler of the ATE
system, not HP.
For alternatives, what other companies made HPIB/GPIB/IEEE controllers?
8:38 p.m.
New subject: More on mystery system
Brent Hilpert wrote:
On 2010 Jul 26, at 10:55 AM, Ian King wrote:
The only one that popped into my head was the IBM CS-9000 but that had a
Motorola 68000 CPU, and I don't think that fits. OTOH, I could not find
quickly find an opcode table for the 68K either...
Luck,
Charlie C.
IMHO HP would NOT use the term
"IEEE_SEND" but rather "HPIB_SEND".
Branding, branding, branding...
On 2010 Jul 26, at 12:14 PM, Tony Duell wrote:
For the reason already stated (HP would call it
'HPIB', not 'GPIB' or
'IEEE')_, I doubt it's an HP machine. Although to be honest, HP tended to
just use a SEND command unless it as an HP9830 when it was CMD.
HP may well not have used the IEEE ref, but I would think the code was
more likely written by the end customer or the assembler of the ATE
system, not HP.
For alternatives, what other companies made HPIB/GPIB/IEEE controllers?
27 Jul
27 Jul
1:05 p.m.
New subject: More on mystery system
For the reason
already stated (HP would call it 'HPIB', not 'GPIB' or
'IEEE')_, I doubt it's an HP machine. Although to be honest, HP tended
to
just use a SEND command unless it as an HP9830 when it was CMD.
HP may well not have used the IEEE ref, but I would think the code was
more likely written by the end customer or the assembler of the ATE
system, not HP.
For alternatives, what other companies made HPIB/GPIB/IEEE controllers?
At that time, I would guess Tektronix did. Possibly Fluke? Actually just
about anyotne in the ATE buisness would have done, surely?
-tony
4:42 p.m.
New subject: More on mystery system
On 07/27/2010 04:05 PM, Tony Duell wrote:
Possible, but HP users tended to have the 'HPIB' name ingrained
into
them...
Everyone else does not and companies like Tektronix, Keithley
and a raft of others make gear for IEEE/GPIB bus.
I wrote a metric bucket load of code for ATE using GPIB (IEEE) controller
in a PC using QBasic45/dos and a IO library supplied with the card.
Very common in industry, though old. People have moved on to
RS485, Ethernet and smart devices using MPUs with tose interfaces.
Allison
For the reason already stated (HP would call it
'HPIB', not 'GPIB' or
'IEEE')_, I doubt it's an HP machine. Although to be honest, HP tended
to
just use a SEND command unless it as an HP9830 when it was CMD.
HP may well not have used the IEEE ref, but I would think the code was
more likely written by the end customer or the assembler of the ATE
system, not HP.
For
alternatives, what other companies made HPIB/GPIB/IEEE controllers?
At that time, I would guess Tektronix did. Possibly Fluke? Actually just
about anyotne in the ATE buisness would have done, surely?
-tony
7:15 p.m.
New subject: More on mystery system
For alternatives, what other companies made
HPIB/GPIB/IEEE controllers?
At that time, I would guess Tektronix did. Possibly Fluke? Actually just
about anyotne in the ATE buisness would have done, surely?
-tony
26 Jul
26 Jul
11:22 a.m.
Chuck,
I'm curious what you found to make you think the call was D3, etc.? I
looked and found a some
other processors which might have 16 bit immediate and wondered how you
figure the call, vs.
branch, etc. I can guess, but thought I'd ask a few blobs of hex might
put more eyeballs on
the puzzle.
Also on the subject of Fairchild, they did make test equipment and other
ATE equipment in the
50's and 60's. I wonder what the time frame is on the equipment, and if
it might predate 1972
by some time.
Jim
On 7/25/2010 8:50 PM, Chuck Guzis wrote:
I'm working with an old data sample (ca. 1979) to
a piece of
equipment that I do not have access to. I've identified some bits
and pieces of code and am trying to identify the processor.
Here's what I know. The processor is big-endian and appears to be
byte-addressable. The opcode for CALL appears to be D3 xx xx, where
xxxx is the address of the destination. 2C appears to be load
immediate instruction and is also 3 bytes long.
The code doesn't look tight enough to be a p-code implementation of
any sort.
Does this ring any bells to anyone?
--Chuck
11:21 p.m.
On 26 Jul 2010 at 11:22, Jim Stephens wrote:
I'm curious what you found to make you think the
call was D3, etc.? I
looked and found a some other processors which might have 16 bit
immediate and wondered how you figure the call, vs. branch, etc. I
can guess, but thought I'd ask a few blobs of hex might put more
eyeballs on the puzzle.
Easy--inspecting the code that I have, the call to display (print) a
message takes the form:
D3 08 00
(size of ASCII string)
(ASCII string)
next instruction
If you think about it, the only way this will work is if the called
routine takes the return address from the D3 instruction and uses it
to access the inline data and then resumes after the end of the
string has been reached.
Similarly, 2C xx xx appears to be a load immediate of some sort, as
it's used to set up constant data before a D3 xx xx instruction.
The code is peppered with D3 xx xx for the various other statement
types that I can recognize (I have a couple of less-than-one page
JPEGs of old program listing). I don't have much of a Rosetta stone,
but I'm satisfied that instructions are 24 bits long and addresses
appear to be no more than 16 bits.
Thanks to Brent giving a starting point and from the date of the
code, I believe the equipment to be a Fairchild Series 70 ATE rig
using a Fairchild FST-2 CPU. The weird 8" floppy formats confirm the
time period (i.e., both hard sector FM and soft sector MFM, with
utterly non-standard encodings).
Thanks,
Chuck
P.S. Here's some sample code:
00A320 50 52 4F 47 52 41 4D 20-49 53 20 46 4F 52 D3 74
00A330 0C 80 D3 41 00 00 00 01-D3 74 0C 8A 90 3F 8C 00
00A340 90 36 99 03 B0 74 D3 2D-00 01 90 3F 99 02 30 70
00A350 90 3B 00 1A 90 3F 8C 03-8D 01 90 36 99 04 B0 36
00A360 D3 08 00 24 20 20 20 20-20 20 20 20 5A 4F 4F 4D
00A370 20 26 20 48 49 53 20 42-4F 41 52 44 20 4F 4E 4C
00A380 59 20 20 20 20 20 20 20-D3 74 0C 8A D3 41 00 80
00A390 00 01 D3 74 0C 94 90 3F-8C 00 90 36 99 03 B0 74
00A3A0 D3 2D 00 01 90 3F 99 02-30 70 90 3B 00 1A 90 3F
00A3B0 8C 04 8D 01 90 36 99 04-B0 36 D3 08 00 24 20 49
00A3C0 4E 53 45 52 54 20 55 55-54 20 41 4E 44 20 53 59
00A3D0 4E 43 53 20 47 45 4E 45-52 41 54 4F 52 20 43 41
00A3E0 52 44 D3 74 0C 94 D3 41-00 80 00 01 D3 74 0C 9E
00A3F0 90 3F 8C 00 90 36 99 03-B0 74 D3 2D 00 01 90 3F
00A400 99 02 30 70 90 3B 00 10-90 3F 8C 06 8D 0C 90 36
00A410 99 04 B0 36 D3 08 00 10-50 52 45 53 53 20 47 4F
00A420 20 54 4F 20 54 45 53 54-D3 74 0C 9E D3 41 00 00
It starts in the middle of a display screen "PROGRAM IS FOR". At
00A363, you'll see " ZOOM & HIS BOARD ONLY". Then, at 00A3BD,
the display text "INSERT UUT AND SYNCS GENERATOR CARD". Finally, at
00A417, "PRESS GO TO TEST".
27 Jul
27 Jul
9:47 a.m.
From: cclist at sydex.com
---snip---
Easy--inspecting the code that I have, the call to display (print) a
message takes the form:
D3 08 00
(size of ASCII string)
(ASCII string)
next instruction
If you think about it, the only way this will work is if the called
routine takes the return address from the D3 instruction and uses it
to access the inline data and then resumes after the end of the
string has been reached.
Hi
Passing parameters was often done this way on many machines with limited
registers.
Is it possible you are looking at compiled BASIC instead of machine instructions?
Dwight
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…
10:09 a.m.
On 27 Jul 2010 at 9:47, dwight elvey wrote:
No, the language appears to be Factor and the ratio of object code to
source code (from the small samples I have) indicates compiling to
machine code.
If you'd like to play with what I have, you can download the
following:
http://www.sydex.com/temp/tp.main.jpg - A JPEG image of a short
source program.
http://www.sydex.com/temp/tp.main.hex - the binary of the compiled
program.
http://www.sydex.com/temp/zoom3.zip - the raw, sector-by-sector disk
image (about 1.2MB, compressed to 330K).
--Chuck
Passing
parameters was often done this way on many machines with
limited
registers.
Is it possible you are looking at compiled BASIC instead of machine
instructions? 
11:53 a.m.
On Tue, 27 Jul 2010, dwight elvey wrote:
Passing parameters was often done this way on many
machines with limited
registers.
Is it possible you are looking at compiled BASIC instead of machine
instructions?
Or, some form of tokenized storage.
GOTO's and assignment statements don't need much more.
But, the source code snippet (if related) doesn't look like BASIC.
It looks more like a predecessor to FORTRAN.
Considering that it was done on a Sentry computer, albeit not the model
70, the answer is obviously that this is Valtrep.
Document it well, so that when Titor shows it to Backus, he will know what
to do.
1:42 p.m.
On 26 Jul 2010 at 11:22, Jim Stephens wrote:
It doesn;t have to be a CALL in the normal sense (i.e. it stacks the PC
contents, it might just save the PC in some other register (or in the
word preceeding the subroutine itself, or..)
I'm curious what you found to make you think
the call was D3, etc.? I
looked and found a some other processors which might have 16 bit
immediate and wondered how you figure the call, vs. branch, etc. I
can guess, but thought I'd ask a few blobs of hex might put more
eyeballs on the puzzle.
Easy--inspecting the code that I have, the call to display (print) a
message takes the form:
D3 08 00
(size of ASCII string)
(ASCII string)
next instruction
If you think about it, the only way this will work is if the called
routine takes the return address from the D3 instruction and uses it to access the inline data and then resumes after the
end of the
string has been reached.
Similarly, 2C xx xx appears to be a load immediate of some sort, as
it's used to set up constant data before a D3 xx xx instruction.
How do you know it's immediate, rather than, say, absolute. And how do
you know it's a load and not some other opeation between a register and
the next 2 bytes?
It starts in the middle of a display screen
"PROGRAM IS FOR". At
00A363, you'll see " ZOOM & HIS BOARD ONLY". Then, at 00A3BD,
the display text "INSERT UUT AND SYNCS GENERATOR CARD". Finally, at
00A417, "PRESS GO TO TEST".
Is this to test some kind of video display system. 'ZOOM and HIS' might
be Zoom and Histogram board (A histrogram of the displayed pixels -- that
is keeping a vount of how many of each intensity are present) was not
uncommon on video systems of that period. UUT is almost certianly 'Unit
Under Test'. ;'Syncs Generator' is also possibly video-related. It sounds
a little like the I2S image dispalys I have, but not exactly.
-tony
2:43 p.m.
On 27 Jul 2010 at 21:42, Tony Duell wrote:
T(5000) appears to translate to 2C 13 88, followed by a D3... Since I
don't know the register architecture of the FST-1/2, I can't say for
certain where the value goes. My guess is a register--not required,
but possible.
--Chuck
It doesn;t have to be a CALL in the normal sense (i.e.
it stacks the
PC contents, it might just save the PC in some other register (or in
the word preceeding the subroutine itself, or..)
I meant it in that sense--i.e., the value of the current PC is saved
(on a stack, in memory or in a register) and is program-accessible
(not all CPUs allow this) and a transfer of control occurs. It's
only people born since 1970 who think that all machines have hardware
stacks. Consider it to be equivalent to a TSX, RJ or BAL instruction
if you desire. (The first time I heard someone referring to S/360
BAL, I thought "Boy, that's pretty silly, limiting yourself to one
instruction.").
to access the
inline data and then resumes after the end of the
string has been reached.
Similarly, 2C xx xx appears to be a load immediate of some sort, as
it's used to set up constant data before a D3 xx xx instruction.
How do you know it's immediate, rather than, say, absolute. And how do
you know it's a load and not some other opeation between a register
and the next 2 bytes? 
3:25 p.m.
Chuck Guzis wrote:
On 27 Jul 2010 at 21:42, Tony Duell wrote:
Or some machines like the
one I am working on; one does not even have
a CALL of any kind. It is not needed.
TAD I [.+1
JMP SUB
It doesn;t have to be a CALL in the normal sense
(i.e. it stacks the
PC contents, it might just save the PC in some other register (or in
the word preceeding the subroutine itself, or..)
I meant it in that sense--i.e., the value of the
current PC is saved
(on a stack, in memory or in a register) and is program-accessible
(not all CPUs allow this) and a transfer of control occurs. It's
only people born since 1970 who think that all machines have hardware
stacks. Consider it to be equivalent to a TSX, RJ or BAL instruction
if you desire. (The first time I heard someone referring to S/360
BAL, I thought "Boy, that's pretty silly, limiting yourself to one
instruction.").
28 Jul
28 Jul
7:48 a.m.
Chuck Guzis wrote:
On 27 Jul 2010 at 16:25, Ben wrote:
A very simple 18 bit cpu, I have fit in 128 cell CPLD.
I have the CPLD logic defined but I still need to revise my
Glue CPLD's, before I start working on PCB.
Two glue 64 cell CPLD's, 2 EEPROMS, 2 32Kbx8 ram, 6850
and the 128 CPLD will comprise the system.A IDE interface
is planned, but I have finished the resolving the I/O yet.
A .8 us memory cycle is planned, with 1.6 us needed for
a 18 bit memory access. Consider it a stretched PDP8
with ISZ,JSR, and I/O instructions missing.
The PDP 8 style code was ment to be:
TAD (.+1)
JMP SUB
Or some machines like the one I am working on;
one does not even have
a CALL of any kind. It is not needed. TAD I [.+1 JMP SUB
It *looks* like PDP-8 code, but that can't be as the PDP-8 has a JMS
instruction. What machine is this? --Chuck
Ben.
29 Sep
29 Sep
9:47 a.m.
New subject: Machine code riddle (Fairchild Series 70 system)
Chuck,
I came up with a box of floppies labeled for this system. I have a box
of 11 floppies with Fairchild labels in a Fairchild box.
If you still have the means and interest to look at this you are
welcome to them. I don't have a way to deal with them.
The base media is Verbatim 32 sector floppies.
How to get them to you intact is another question. I don't trust
shipping magnetics anymore.
I'll send one note to the list in case anyone else discovered anything
or wants to chime in, reply to me off list if you like to save
bandwidth, or reply here if you like and think it is interesting.
JIm
On 7/25/2010 8:50 PM, Chuck Guzis wrote:
I'm working with an old data sample (ca. 1979) to
a piece of
equipment that I do not have access to. I've identified some bits
and pieces of code and am trying to identify the processor.
Here's what I know. The processor is big-endian and appears to be
byte-addressable. The opcode for CALL appears to be D3 xx xx, where
xxxx is the address of the destination. 2C appears to be load
immediate instruction and is also 3 bytes long.
The code doesn't look tight enough to be a p-code implementation of
any sort.
Does this ring any bells to anyone?
--Chuck
10:31 a.m.
New subject: Machine code riddle (Fairchild Series 70 system)
On Thu, 29 Sep 2011, Alexandre Souza - Listas wrote:
Umm, no. Aluminum has a relative permeability > 1, so wrapping the disks
in aluminum will make them a tiny bit _more_ susceptible. You'd want to
wrap them in a superconductor, or faling that a very thick layer of
bismuth :-) Practically speaking, you should just put the disks securely
in the center of a box significantly larger than themselves.
Alexey
How to get
them to you intact is another question. I don't trust shipping
magnetics anymore.
Envolve them in aluminium paper :)
1:21 p.m.
New subject: Machine code riddle (Fairchild Series 70 system)
How to get them to you intact is another question. I
don't trust shipping
magnetics anymore.
Envolve them in aluminium paper :)
10:58 a.m.
New subject: Machine code riddle (Fairchild Series 70 system)
On 29 Sep 2011 at 9:47, jim s wrote:
Chuck,
I came up with a box of floppies labeled for this system. I have a
box of 11 floppies with Fairchild labels in a Fairchild box.
If you still have the means and interest to look at this you are
welcome to them. I don't have a way to deal with them.
The base media is Verbatim 32 sector floppies.
How to get them to you intact is another question. I don't trust
shipping magnetics anymore.
I'll send one note to the list in case anyone else discovered anything
or wants to chime in, reply to me off list if you like to save
bandwidth, or reply here if you like and think it is interesting. JIm
Another data point for the Sentry would be welcome. The funny thing
about them was that they used hard-sector media, but recorded data in
soft-sector mode that didn't line up with the sector holes. Just
plain weird. My guess is that the platform started off on hard
sector, but then moved to soft sector recording, but tolerated HS
disks out of respect for the customer.
We sent them back and forth to Israel in a standard Fedex box. I
slipped them into an old 8" polyethylene floppy box but did nothing
special.
Remember that magnetic fields are a inverse-square sort of thing, so
wrapping about a half-inch of bubble wrap around the bundle before
you stick it into a box will do wonders.
Floppies, particularly the 8" kind, are very durable beasts.
--Chuck
1:25 p.m.
New subject: Machine code riddle (Fairchild Series 70 system)
Remember that magnetic fields are a inverse-square
sort of thing, so
Is it? I thought a dipole field fell off as 1/R^3. Anyway, it falls off
pretty fast. I don;t think I've ever damaged a magnetic recording by
accidentally subjeting it to a mangentic field. I once tried rubbing a
floppy disk across the grill of a medium-sized loudspekaer unit, in front
of the bass drive unit. No damage to the data on the floppy at all. (Of
coruse I did with a disk I had a backup of :-)).
wrapping about a half-inch of bubble wrap around the
bundle before
you stick it into a box will do wonders.
Indeed...
Somewhere I have a report from 3M on the robustness of magnetic
recordings on their 9-track tape. I seem to recall they would stand up to
quite a lot...
-tony
2:32 p.m.
New subject: Machine code riddle (Fairchild Series 70 system)
On 29 Sep 2011 at 21:25, Tony Duell wrote:
Is it? I thought a dipole field fell off as 1/R^3.
Anyway, it falls
off pretty fast.
It's more complicated than that. At *near* distances, it's inverse-
square; at *far* distances, it's inverse-cube. At intermediate
distances, it's somewhere betweeen the two and a nightmare to
calculate.
--Chuck
30 Sep
30 Sep
12:18 p.m.
New subject: Machine code riddle (Fairchild Series 70 system)
On 29 Sep 2011 at 21:25, Tony Duell wrote:
I thought the ideal dipole had 0 separation (if you see what I mean). In
other words, the 'dipole field' is defined when the distance form the
pair of poies is much larger than their separation.
That implies of course that the field from a bar magnet is not a dipole
field , certianly not if you're close to it.
-tony
Is it? I thought a dipole field fell off as
1/R^3. Anyway, it falls
off pretty fast.
It's more complicated than that. At *near* distances, it's inverse-
square; at *far* distances, it's inverse-cube. At intermediate 
1 Oct
1 Oct
9:36 a.m.
New subject: shipping magnetics
On 9/29/11 9:47 AM, jim s wrote:
How to get them to you intact is another question. I
don't trust shipping magnetics anymore.
The best article I have ever seen on this is Geller's "Erasing Myths About
Magnetic Media"
which I've uploaded to:
http://bitsavers.org/pdf/nbs/publications/Geller_Erasing_Myths_About_Magnet…
11:55 p.m.
New subject: shipping magnetics
On Sat, 1 Oct 2011, Al Kossow wrote:
On 9/29/11 9:47 AM, jim s wrote:
Recently at a hotel, I managed to erase my magnetic key card twice. Once
by carrying it against my cell phone and again by laying it on top of my
notebook computer. The people at the front desk told me that it happens
all the time.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
How to get them to you intact is another
question. I don't trust shipping
magnetics anymore.
The best article I have ever seen on this is Geller's "Erasing Myths About
Magnetic Media"
which I've uploaded to:
http://bitsavers.org/pdf/nbs/publications/Geller_Erasing_Myths_About_Magnet…
2 Oct
2 Oct
10:22 p.m.
New subject: shipping magnetics
Hi
While I've intentionally use a strong magnet to destroy
the files on a 360K disk when I wanted to record fat on one
side only, to defeat MS insistance on not letting me do what
I want, I've only had one problem with normal stray
magnetic fields.
I have found that floppies are sensitive to the stray fields
of things like monitor deflection coils while they are being recoded.
I've never seen similar fields cause any problem while reading.
Even moving the monitor as little as another 6 inches was enough
to stop the problem.
Dwight
From: dgriffi at cs.csubak.edu
On Sat, 1 Oct 2011, Al Kossow wrote:
On 9/29/11 9:47 AM, jim s wrote:
Recently at a hotel, I managed to erase my magnetic key card twice. Once
by carrying it against my cell phone and again by laying it on top of my
notebook computer. The people at the front desk told me that it happens
all the time.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail? How to get them to you intact is another
question. I don't trust shipping
magnetics anymore.
The best article I have ever seen on this is Geller's "Erasing Myths About
Magnetic Media"
which I've uploaded to:
http://bitsavers.org/pdf/nbs/publications/Geller_Erasing_Myths_About_Magnet…
3 Oct
3 Oct
8:25 a.m.
New subject: shipping magnetics
On 10/2/11 10:22 PM, dwight elvey wrote:
I have found that floppies are sensitive to the
stray fields
of things like monitor deflection coils while they are being recoded.
How far away was the monitor?
I could believe the monitor was interfering with the read preamp.
10:17 a.m.
New subject: shipping magnetics
On 3 Oct 2011 at 8:25, Al Kossow wrote:
How far away was the monitor?
I could believe the monitor was interfering with the read preamp.
That was very common on old designs; put a monitor on top of a box
containing disk drives and the read signal gets all screwed up. Some
steel shielding around the drives usually clears that problem up
(easier to do it to the drives than the monitor).
AC operated fans, printer stepper motors, etc. can have a similar
effect if close enough. And vice-versa--an impact printer placed
close to a monitor can cause the image to wobble quite a bit.
And then there's the Coleco Adam...
--Chuck
9:40 a.m.
New subject: shipping magnetics
The other really strong field from a monitor is the degauss coil
around the tube at switch on and was probably the guilty source
Dave Caroline
10:49 a.m.
New subject: shipping magnetics
On 3 Oct 2011 at 17:40, Dave Caroline wrote:
The other really strong field from a monitor is the
degauss coil
around the tube at switch on and was probably the guilty source
I own a fairly strong degausser that I use on diskettes. For it to
be effective, the disk must almost be in contact with the surface of
the degausser. With only an inch of separation, almost nothing
happens. The material used in floppy disk emulsions has a pretty
"square" magnetization curve.
--Chuck
11:28 a.m.
New subject: shipping magnetics
On 10/3/11 10:49 AM, Chuck Guzis wrote:
I own a fairly strong degausser that I use on
diskettes. For it to
be effective, the disk must almost be in contact with the surface of
the degausser. With only an inch of separation, almost nothing
happens. The material used in floppy disk emulsions has a pretty
"square" magnetization curve.
That is exactly the conclusion in the paper I uploaded.
If you look at the graphs, it is very difficult to accidentally erase
digital magnetic media. That has been my experience as well. I have had
much more trouble with physical media failure than the magnetization
going away.
4:28 p.m.
New subject: shipping magnetics
On Mon, 3 Oct 2011, Al Kossow wrote:
That is exactly the conclusion in the paper I
uploaded.
If you look at the graphs, it is very difficult to accidentally erase
digital magnetic media.
Maybe I'm cynical, but it seems to me that it is hard to DELIBERATELY
erase digital magnetic media, but easy to do it accidentally.
That has been my experience as well. I have had
much more trouble with physical media failure than the magnetization
going away.
TRUE.
Look for small creases in the surface, etc.
4 Oct
4 Oct
6:28 a.m.
New subject: shipping magnetics
On Mon, 3 Oct 2011, Chuck Guzis wrote:
On 3 Oct 2011 at 16:28, Fred Cisin wrote:
Maaaany years ago I worked for Gemini Shareware for a short time doing
disk duplication. I was astonished at some of the crap disks they were
buying. I found one 5.25" disk that had what appeared to be a 1/2" wide
strip of cellophane tape on the cookie. it was almost as if they coated
to the very end of the roll, including the tape that held the material to
the cardboard tube.
The Tracer 5 disk duplicators were cool as hell though. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
Look for small creases in the surface, etc.
Or certain brands. Wabash floppies top my list of "you have to be
kidding" media.
12:22 p.m.
New subject: shipping magnetics
Maybe I'm cynical, but it seems to me that it is
hard to DELIBERATELY
erase digital magnetic media, but easy to do it accidentally.
I am sure Mr Murphy had soemthign to say about this :-)
It also appears to be much easier to accidentally erase magnetic media if
you don't have a backup.
-tony
3 Oct
3 Oct
12:35 p.m.
New subject: shipping magnetics
I have found that floppies are sensitive to the stray
fields
of things like monitor deflection coils while they are being recoded.
I've never seen similar fields cause any problem while reading.
Even moving the monitor as little as another 6 inches was enough
to stop the problem.
I am supriset it affected writing and not reading. Had it been the other
way round, I would have suspected interfecent pickup in the read
amplifier (seen that often enough), this does not damage the disk though.
I assume your disks written when the drive was too close to the monitor
were not readable elsewhere, the data on the disk was genuinely
corrupted. But I don;t see why a disk would be more susceptable to
external mangetic fields when writing than at any other time.
It also may not have been the defleciton coils. There are plenty of other
magnetic devices in CRT nonitors -- PSU transformer, flyback transformer,
degausisng coil (if a colour CRT), etc.
-tony
7:14 p.m.
New subject: shipping magnetics
From: ard at p850ug1.demon.co.uk
Hi Tony
I did enough experiments to see that I had no problems reading floppies
other than those that were recoreded near the monitor.
My guess is that it upset the bias so that it shifted the depth over time,
enough to upset the read of the data. The recoding is all through
the depth were as the reading is more of a surface thing. To read
it is the spacing of the edges of the NS-SN fields. Singe the recording takes
place over a larger volume of the media, it can effect the NS-SN
transitions because of the depths of the fields.
Dwight
I have found that floppies are sensitive to the
stray fields
of things like monitor deflection coils while they are being recoded.
I've never seen similar fields cause any problem while reading.
Even moving the monitor as little as another 6 inches was enough
to stop the problem.
I am supriset it affected writing and not reading. Had it been the other
way round, I would have suspected interfecent pickup in the read
amplifier (seen that often enough), this does not damage the disk though.
I assume your disks written when the drive was too close to the monitor
were not readable elsewhere, the data on the disk was genuinely
corrupted. But I don;t see why a disk would be more susceptable to
external mangetic fields when writing than at any other time.
It also may not have been the defleciton coils. There are plenty of other
magnetic devices in CRT nonitors -- PSU transformer, flyback transformer,
degausisng coil (if a colour CRT), etc.
-tony
4 Oct
4 Oct
12:45 p.m.
New subject: shipping magnetics
I did enough experiments to see that I had no
problems reading floppies
other than those that were recoreded near the monitor.
OK. I ssume areas of the disk that were not written near the monitor were
unaffected.
My guess is that it upset the bias so that it shifted
the depth over time=
There's nop bias (in the normal magnetic-recording sense of an HF
oscillation) in disk deives (and they use DC to drive the tunnel erase
head too). I wonder if somehow, in the presense of the normal write
field, the alternating field from the monitor was recorfed, causing extra
transition...
I don;t suppose you still have such a disk? If so, it would be
interesting to see what a efective track contains, both at the output of
a normal floppy drive trying to read it, and as an analgoue signal at the
putput of the read amplifier.
-tony
5 Oct
5 Oct
7:18 a.m.
New subject: shipping magnetics
From: ard at p850ug1.demon.co.uk
Subject: Re: shipping magnetics
To: cctalk at classiccmp.org
Date: Tue, 4 Oct 2011 20:45:03 +0100
Hi Tony
No, once I determined the problem, I moved the monitor away and
reformatted the disk.
I didn't means a bias signal, I was thinking more a magnetic offset
to the signal.
Dwight
I did enough experiments to see that I had no
problems reading floppies
other than those that were recoreded near the monitor.
OK. I ssume areas of the disk that were not written near the monitor were
unaffected.
My guess is that it upset the bias so that it
shifted the depth over time=
There's nop bias (in the normal magnetic-recording sense of an HF
oscillation) in disk deives (and they use DC to drive the tunnel erase
head too). I wonder if somehow, in the presense of the normal write
field, the alternating field from the monitor was recorfed, causing extra
transition...
I don;t suppose you still have such a disk? If so, it would be
interesting to see what a efective track contains, both at the output of
a normal floppy drive trying to read it, and as an analgoue signal at the
putput of the read amplifier.
-tony
4589
days inactive
5025
days old
48 comments
18 participants
participants (18)
-
aek＠bitsavers.org -
ajp166＠verizon.net -
alexeyt＠freeshell.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
csquared3＠tx.rr.com -
dave.thearchivist＠gmail.com -
dgriffi＠cs.csubak.edu -
dkelvey＠hotmail.com -
geneb＠deltasoft.com -
hilpert＠cs.ubc.ca -
IanK＠vulcan.com -
jws＠jwsss.com -
n0body.h0me＠inbox.com -
pcw＠mesanet.com -
pu1bzz.listas＠gmail.com