3B1 debugger ROM availability; LEGAL ADVICE/OPINION SOUGHT
th...@btr.btr.com
came upon a set of the 3B1 Debugger ROMs (as described in the UNIX PC
Reference Manual). They were "burned" into 2764 EPROMs but can also be
placed in 27128 EPROMs.
So far I've made 3 duplicate sets AND I've converted the contents of each
EPROM to Motorola S-record files (actually, my EPROM Programmer did the
conversion and I just saved the files :-).
I'd like to make these available. Distribution via file is the easiest
since they can be archived if/when posted to comp.sources.3b1. I simply
haven't the time to make copies "a la group buy"; one person who already
used a set of copied EPROMs hasn't reported any problems, so I'm assuming
these are all OK.
Several questions: (respond by post, I'm too far behind email due to workload)
1) any problem with posting non-source (EPROM code) to comp.sources.3b1?
Voice any complaints now.
2) the files are presently in S-record format, but it'd be easy to make a
set of Intel hex format files also (for those whose EPROM programmers
require that format); is there any interest in this?
3) to whom should such a post be emailed? (I.e. who's the moderator of
comp.sources.3b1?)
AND MOST IMPORTANTLY:
4) the EPROMs were purchased by the member of the user group, so I suspect
this entitles him to ownership. But given the copyright status (by CT;
see below), I need to know *NOW* whether this kind of distribution is
going to cause any legal problems. If I don't receive competent opinion
in this regards, then I won't post since I don't need any legal problems.
If you know anything in this regards, please answer. The reason I bring
this up is due to others' legal problems regarding copied ROMs from
other systems (i.e. Macs, IBM-PCs, etc.)
My personal opinion is that there would be no problem, but I'm not a
lawyer and am only moderately conversant in copyright law. As I see it,
duplicating copyrighted EPROMs is like photocopying books and copying
commercial software floppies, hence my hesitation.
Included below is the intended README for the distribution. Comments? This
file is presently just a "note" to myself as to the nature of the several files
in the one directory in which I archived the "dumps".
The sizes of the uncompressed Hi and Lo debug files are 19.2K each, and the
hi/lo file is 38.4K. Motorola S-records are ASCII, so a uuencoded compressed
posting shouldn't be too large.
Note that you'll NEED the UNIX PC Reference Manual (with all the schematics
and the narrative) for effective use of the debugger ROMs.
Thad Floryan [ th...@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
-------------------- begin enclosure
These are the S4/3B1/PC7300/UNIXPC DEBUG EPROM code dumps. The originals are
in 2764 (28-PIN) EPROMs (though 27128 could also be used) per:
HIGH DEBUG, checksum = 074964, data bits 15-8 (EVEN), chip location 15C
LOW DEBUG, checksum = DBC89E, data bits 7-0 (ODD), chip location 14C
The "hi-lo-debug" file contains the EPROM contents in the specified byte-
sequenced order every 2 bytes to represent actual contiguous addresses.
All files are in Motorola "S" record format.
The code in the EPROMs represents:
S4 MC68010 ROM DEBUGGER V1.0
COPYRIGHT 1984 BY CONVERGENT TECHNOLOGIES, INC.
From the UNIXPC Reference Manual, beginning at page 2-12:
When a system is powered or reset, the CPU automatically addresses ROM.
A bootstrap routine directs the CPU to initialize the UNIXPC system and
read the operating system from the disk.
When a system is reset, internal microcode forces the 68010 to read from
RAM address 000000. Address 000000 is referred to as the reset vector.
The 68010 loads the stack pointer with the values stored in addresses
000000 and 000002. It reads the values stored in addresses 000004 and
000006 and loads them into the program counter.
Actual address space from ROM is 800000-BFFFFF. The values necessary to
initialize the stack pointer and the program counter are actually at
addresses 800000 through 800006. Therefore, during a reset, the hardware
is responsible for forcing address bit 23 high, thus causing the processor
to refer to ROM.
During reset, a signal called ROMLMAP* is generated and ORed with address
bit PA23. Although the processor is addressing 000000, ROMLMAP* causes
the address sent to ROM to be 800000.
At this point, the hardware forces the processor into the ROM address
space, and no RAM references can be made as long as ROMLMAP* is active.
The boot code is responsible for vectoring the processor into legitimate
ROM address space and must also cause the processor to deactivate ROMLMAP*
so RAM can be addressed again.
The processor is vectored into legitimate ROM address space by the first
instruction executed after the program counter is loaded with the vector
address at 800004 and 800006. This value is loaded into the program
counter. The processor then fetches and begins instruction execution.
Now that the CPU is driving PA23 high, ROMLMAP* is no longer necessary.
In fact, it must be dropped to access RAM. The first instruction,
addressed by the reset vector, causes 8000 to be written to address E43000.
This deactivates ROMLMAP*.
-------------------- end enclosure
Don Nichols (DoN.)
>One of the members of the Silicon Valley AT&T UNIX Users' Group recently
>came upon a set of the 3B1 Debugger ROMs (as described in the UNIX PC
>Reference Manual). They were "burned" into 2764 EPROMs but can also be
>placed in 27128 EPROMs.
[ ... ]
>I'd like to make these available. Distribution via file is the easiest
>since they can be archived if/when posted to comp.sources.3b1. I simply
>haven't the time to make copies "a la group buy"; one person who already
>used a set of copied EPROMs hasn't reported any problems, so I'm assuming
>these are all OK.
This would be a great service to the user commnunity (at least as
represented my me :-).
>Several questions: (respond by post, I'm too far behind email due to workload)
>
>1) any problem with posting non-source (EPROM code) to comp.sources.3b1?
> Voice any complaints now.
In a case like this, where the source is unavailable, and the code
is of such utility to the target group, I have *no* problems with it.
>2) the files are presently in S-record format, but it'd be easy to make a
> set of Intel hex format files also (for those whose EPROM programmers
> require that format); is there any interest in this?
S-record format is fine by me. I have no need for Intel hex, though
others may voice such a need.
>3) to whom should such a post be emailed? (I.e. who's the moderator of
> comp.sources.3b1?)
Isn't the nature of a moderated group that when you attempt to mail
to the groups, and it is flagged in your active file as moderated, that it
is sent to the moderator (through some standardized addresses derived from
the group name) automatically?
>AND MOST IMPORTANTLY:
>
>4) the EPROMs were purchased by the member of the user group, so I suspect
> this entitles him to ownership. But given the copyright status (by CT;
> see below), I need to know *NOW* whether this kind of distribution is
> going to cause any legal problems. If I don't receive competent opinion
> in this regards, then I won't post since I don't need any legal problems.
> If you know anything in this regards, please answer. The reason I bring
> this up is due to others' legal problems regarding copied ROMs from
> other systems (i.e. Macs, IBM-PCs, etc.)
>
> My personal opinion is that there would be no problem, but I'm not a
> lawyer and am only moderately conversant in copyright law. As I see it,
> duplicating copyrighted EPROMs is like photocopying books and copying
> commercial software floppies, hence my hesitation.
I am not a lawyer (and I don't even play one on the net :-), but I
would think that you would need the permission of Convergent to do this, and
if possible in writing. An alternative would be to get the posting to be
made from Convergent, so there is no question of an unauthorized posting
having been made. In all probablilty, Convergent would consider the machine
old enough so they wouldn't get bent out of shape, but who knows what the
Unisys lawyers might do? By the time the copyright has expired, the eproms
will have forgotten their contents. :=(
>Included below is the intended README for the distribution. Comments? This
>file is presently just a "note" to myself as to the nature of the several files
>in the one directory in which I archived the "dumps".
>
>The sizes of the uncompressed Hi and Lo debug files are 19.2K each, and the
>hi/lo file is 38.4K. Motorola S-records are ASCII, so a uuencoded compressed
>posting shouldn't be too large.
>
>Note that you'll NEED the UNIX PC Reference Manual (with all the schematics
>and the narrative) for effective use of the debugger ROMs.
>
This information is probably in the TRM (I'm to lazy to dig it out
now), but why don't you add in the information as to which sockets each
eprom should live in? It is probably obvious from inspection, but I don't
have a machine open in front of me at present.
Good Luck
DoN.
--
Donald Nichols (DoN.) | Voice (Days): (703) 704-2020 (Eves): (703) 938-4564
D&D Data | Email: <dnic...@ceilidh.beartrack.com>
I said it - no one else | <dnic...@ceilidh.aes.com>
--- Black Holes are where God is dividing by zero ---
David H. Brierley
>In article <59...@public.BTR.COM> th...@btr.btr.com writes:
>>1) any problem with posting non-source (EPROM code) to comp.sources.3b1?
Normally I would reject a non-source posting but in this case I will make an
exception. I guess you could rationalize it by arguing that this is the source
code for the EPROM.
>>3) to whom should such a post be emailed? (I.e. who's the moderator of
>> comp.sources.3b1?)
>
> Isn't the nature of a moderated group that when you attempt to mail
>to the groups, and it is flagged in your active file as moderated, that it
>is sent to the moderator (through some standardized addresses derived from
You can mail things directly to me if you want to, but the standard procedure
is that you take the name of the group, change all the dots into dashes and
then mail to "group...@big.host" where "big.host" is one of the so-called
"usenet backbone" sites. In this particular case I recommend sending the mail
to "comp-sou...@uunet.uu.net".
>>4) the EPROMs were purchased by the member of the user group, so I suspect
>> this entitles him to ownership. But given the copyright status (by CT;
I am not a lawyer and I don't want to need the services of one. If there is
any question at all as to the legality of the post I will hold it up until I
get confirmation of its legal status. I delayed one of Alex Crain's postings
a while back for a similar reason. As a general rule, I don't think anybody
cares about this machine anymore. I mean, if Craig can get permission to let
everybody in the world have access to the source code for the OS why should
any care about the contents of the debugger EPROM?
--
David H. Brierley
Home: da...@galaxia.newport.ri.us; Work: d...@quahog.ssd.ray.com
Send comp.sources.3b1 submissions to comp-sou...@galaxia.newport.ri.us
%% Can I be excused, my brain is full. **
Convergent MightyFrame
https://groups.google.com/d/msg/comp.sys.3b1/Ud2-DNZSO5E/I7OiQ4WhBAAJ
Please join us over there to continue this discussion.
Thanks,
-AJ