27 Mar
2008
27 Mar
'08
12:44 p.m.
Date: Wed, 26 Mar 2008 14:12:02 -0500
From: Randy Dawson
IBM's software would not run on a machine that did
not have "copyright
IBM" in the BIOS.
hahaha their workaround made them the most compatible clone.
Actually, a lot of people spent a lot of time reverse-engineering the
IBM BIOS. You really don't get a sense of this until you realize
that Phoenix not only made sure that the functionality of the BIOS
routines was the same, but that the routines themselves were located
at the same place in memory.
I wonder why this wasn't done with the Mac ROMs? Fear of Apple
suing? Anyone know for certain?
Cheers,
Chuck
27 Mar
27 Mar
3:12 p.m.
Chuck Guzis wrote:
...
Actually, a lot of people spent a lot of time
reverse-engineering the
IBM BIOS. You really don't get a sense of this until you realize
that Phoenix not only made sure that the functionality of the BIOS
routines was the same, but that the routines themselves were located
at the same place in memory.
I wonder why this wasn't done with the Mac ROMs? Fear of Apple
suing? Anyone know for certain?
Cheers,
Chuck
Not for certain, but I'm sure relative market share had a lot to do with
it. I'd say another factor was that the mac ROMs were quite a bit
larger than the PC BIOS of the time (512KB vs 40 KB).
4:26 p.m.
Jim Battle wrote:
I'd say another factor was that the mac ROMs were
quite a bit
larger than the PC BIOS of the time (512KB vs 40 KB).
The PC BIOS was 8KB. The rest of the ROM (32KB) was Microsoft BASIC.
Most (legitimate) clones didn't bother to include BASIC in ROM,
instead supplying BASIC on disk (vs. BASICA on IBM-DOS, which was an
extension to the ROM BASIC).
The original Mac ROM was 128KB.
Jim Leonard wrote:
Having them in the same place in memory seems like a
big waste of time.
Suppose you're trying to market a PC clone. How successful will you be
if some piece of popular software for the PC won't run on your clone,
because that software depends on direct calls into the ROM, or direct
access to tables in the ROM (e.g., the character generator)? Back in
those days, *lots* of software did wacky things like that.
Eric
7:53 p.m.
Eric Smith wrote:
Suppose you're trying to market a PC clone. How
successful will you be
if some piece of popular software for the PC won't run on your clone,
because that software depends on direct calls into the ROM, or direct
access to tables in the ROM (e.g., the character generator)? Back in
those days, *lots* of software did wacky things like that.
Yes, but *why*? I am getting to be what I consider a pretty decent
assembler programmer, specifically on the 5150/5160, and I honestly
can't see *why* I would *ever* want to specifically jump directly into
the middle of the BIOS. I *call* BIOS routines, obviously, but what
possible benefit or purpose could there be to jumping directly into ROM?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
8:06 p.m.
On Mar 27, 2008, at 7:53 PM, Jim Leonard wrote:
Eric Smith wrote:
1. Because you can.
2. Because it can save a bit of RAM. Remember in the early days of
the PC, saving bytes was important for a number of programs. They had
to fit in "typical" machines at the time. In many cases this was on a
16K machine, every byte counted and not all of the functions in the
BIOS were exported by INT xx entry points. In many ways IBM made it
easy because they published the complete assembly listing of the BIOS
ROM.
While I was at IBM (Boca Raton, FL), there were rules on the locations
of certain BIOS routines (ie their entry points needed to be at a
certain address in the ROM). This continued into the 1990's.
TTFN - Guy
Suppose you're trying to market a PC clone.
How successful will
you be
if some piece of popular software for the PC won't run on your clone,
because that software depends on direct calls into the ROM, or direct
access to tables in the ROM (e.g., the character generator)? Back in
those days, *lots* of software did wacky things like that.
Yes, but *why*? I am getting to be what I consider a pretty decent
assembler programmer, specifically on the 5150/5160, and I honestly
can't see *why* I would *ever* want to specifically jump directly
into the middle of the BIOS. I *call* BIOS routines, obviously, but
what possible benefit or purpose could there be to jumping directly
into ROM?
8:50 p.m.
Guy Sotomayor wrote:
2. Because it can save a bit of RAM. Remember in the early days of the
PC, saving bytes was important for a number of programs. They had to
fit in "typical" machines at the time. In many cases this was on a 16K
machine, every byte counted and not all of the functions in the BIOS
were exported by INT xx entry points. In many ways IBM made it easy
because they published the complete assembly listing of the BIOS ROM.
While I can appreciate this philosophy, I still can't see how it would
be beneficial on the 5150/5160. For example, let's say I want to move
the cursor to a new location, say (10,15). Typical way is something
like this:
mov ah,2 ;set video mode
mov bh,0 ;video page 0
mov dh,15 ;col 15
mov dl,10 ;row 10
int 10h ;do it
That's 10 bytes.
The INT call pushes the flags, CS, and IP onto the stack, jumps to the
routine, the routine executes, and then *in the ROM routine itself*
there is an IRET, which POPs IP, CS, and flags and then continues from
that point. It is the IRET that is causing me trouble on how to figure
out what better way to do this, because once you hit the IRET you had
better have the IP, CS, and flags on the stack because they're going to
get restored whether you want them to or not. And you can't just patch
in a JMP into the ROM code to return, because it's ROM.
So the only scenario I can think of is something like, maybe you only
want to move the cursor downward, on the same page, and you don't want
to set those extra input registers. Let's also assume that you know the
exact location in ROM where you want to JMP so that the BIOS routine can
do only what you want it to. You would still have to do something like
this:
mov bh,0 ;set video page 0
mov dl,10 ;move cursor down only
CALL 1234:5678 (go directly to your magic function)
That's 9 bytes. So you have saved ONE byte, yes, but that is for an
extremely specific optimized case. The CALL is necessary because of the
IRET that is coming at the end of the function.
If that was a more common practice than I realize, then I guess I stand
corrected. But it just doesn't seem worth it. When I'm *that*
pressured for space, I use code overlays (if the language allows it) or
something else, like using non-visible video RAM for storage. (Yes,
that's disgusting, but I'm not going to turn down 12K of free RAM just
because I'm only using one video page! Remember, even a monochrome
card, with it's single 80x25 video page, has 96 bytes of unused ram...)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
9:21 p.m.
On Mar 27, 2008, at 8:50 PM, Jim Leonard wrote:
Guy Sotomayor wrote:
That's not what people were doing. As I said before, they called in
to functions that weren't exported. Or they wanted a bit more speed,
so they bypassed the higher level routine (done by the INT) and called
directly in. In some cases it actually saved bytes because you didn't
have to load the function ID into a register first, you just called
the specific routine you wanted.
Without having a BIOS listing in front of me, I can't quote an exact
example. But the above was the philosophy...speed (skipping a few
instructions *did* make a difference) or saving bytes by not having to
do all of the setup.
TTFN - Guy
2. Because it can save a bit of RAM. Remember in
the early days of
the PC, saving bytes was important for a number of programs. They
had to fit in "typical" machines at the time. In many cases this
was on a 16K machine, every byte counted and not all of the
functions in the BIOS were exported by INT xx entry points. In
many ways IBM made it easy because they published the complete
assembly listing of the BIOS ROM.
While I can appreciate this philosophy, I still can't see how it
would be beneficial on the 5150/5160. For example, let's say I want
to move the cursor to a new location, say (10,15).
10:33 p.m.
Guy Sotomayor wrote:
Without having a BIOS listing in front of me, I can't quote an exact
example. But the above was the philosophy...speed (skipping a few
instructions *did* make a difference) or saving bytes by not having to
do all of the setup.
I have a BIOS listing of the PCjr (techref is in front of me); I will
look at the listing to see if I can see obvious places where this would
result in a savings. Thanks for the discussion and history.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
28 Mar
28 Mar
3:42 a.m.
While I can appreciate this philosophy, I still
can't see how it would
be beneficial on the 5150/5160. For example, let's say I want to move
the cursor to a new location, say (10,15). Typical way is something
like this:
It has nothing to do with efficiency, it has to do with compatibility.
Everyone was jumping on the IBM bandwagon, and they were not all good
designers - lots of commercial code depended on details of the ROM that
they should not have ... but they did.
Your clone might have a fantastically wonderful BIOS. Faster, more bug
free than IBM, and code that was a work of art to appreciate... but as
soon as some bit of software called a function in the IBM rom that you
didn't provide, or provide in the right place, you machine became one
of the many "incompatibles" that didn't make it.
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
27 Mar
27 Mar
8:15 p.m.
Rumor has it that Jim Leonard may have mentioned these words:
Eric Smith wrote:
But you wouldn't have to *jump* into the middle of a bios for wanting stuff
in the right place - back in them thar daze, just peeking for a value
(screen size / format / other things I can't begin to fathom as I don't
know PeeSee's for diddle ;-) could cause programs to break... heck, even
just poking into video memory was a widespread tactic to increase speed,
and if Compaq could make their cleanroom BIOS as compatible as possible -
trying to look ahead to squish bugs that may or may not exist (gosh, what
if BG took that tactic with Vista nowadays??? ;-)
Well, it must've worked even partway - Compaq was an awfully big company at
one time... ;-)
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
zmerch at 30below.com
Hi! I am a .signature virus. Copy me into your .signature to join in!
Suppose you're trying to market a PC clone.
How successful will you be
if some piece of popular software for the PC won't run on your clone,
because that software depends on direct calls into the ROM, or direct
access to tables in the ROM (e.g., the character generator)? Back in
those days, *lots* of software did wacky things like that.
Yes, but *why*? I am getting to be what I consider a pretty decent
assembler programmer, specifically on the 5150/5160, and I honestly can't
see *why* I would *ever* want to specifically jump directly into the
middle of the BIOS. I *call* BIOS routines, obviously, but what possible
benefit or purpose could there be to jumping directly into ROM?
28 Mar
28 Mar
11:53 a.m.
I wrote:
Suppose you're trying to market a PC clone. How
successful will you be
if some piece of popular software for the PC won't run on your clone,
because that software depends on direct calls into the ROM, or direct
access to tables in the ROM (e.g., the character generator)? Back in
those days, *lots* of software did wacky things like that.
Jim wrote:
Yes, but *why*? I am getting to be what I consider a
pretty decent
"Why" doesn't matter. The fact is that if you're a company trying
to sell a BIOS to clone makers, and it doesn't work with some even
modestly popular software, the clone makers aren't going to buy it.
It's a business issue, not a technical issue. You could decry the
practice of using unsupported entry points until you were blue in
the face, but it wouldn't convince anyone to buy your BIOS.
Eric
27 Mar
27 Mar
3:19 p.m.
Chuck Guzis wrote:
Actually, a lot of people spent a lot of time
reverse-engineering the
IBM BIOS. You really don't get a sense of this until you realize
that Phoenix not only made sure that the functionality of the BIOS
routines was the same, but that the routines themselves were located
at the same place in memory.
Having them in the same place in memory seems like a big waste of time.
I can't think of a single instance in which knowing where the routines
are located in memory can help me write a faster or smaller program.
If the routines do the same thing, and are at the same place in ROM, how
different enough (to avoid copyright) from the originals could they be?
It's been a while since I looked at the tech ref listings but they
didn't seem all that horribly written (I know others will disagree, I
myself found a bug in the cursor handling in my 5160 ROM, but that's not
the point -- the point is that they weren't SO terrible that they could
be significantly improved or made smaller)...
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
4:02 p.m.
Jim Leonard wrote:
Chuck Guzis wrote:
I worked with a
number of people who worked for Phoenix and have also
worked with people who who have had to make the BIOS work. it also is
not so much that the routines have to be the same place, but the data
tables do as well for things to work. Many drivers will go thru the
bios table and find the routine then tables for various functions. They
would fail if the signature was different or the tables didn't match.
Many times the code that does this was in other rom drivers as well.
It became simpler to just put all as near the same spot as possible and
do away with such problems that way.
Also as far as the Mac roms are concerned Apple never published them in
any form, and may in fact have them under a copyrighted "unpubliished"
form which cannot be legally reverse engineered as was the IBM BIOS.
IBM did not come after the copiers until a stable clone of the BIOS
appeared and the market demanded that IBM keep compatability with the model.
Only marginal changes such as the AT updates took hold with few of the
updates to the model which was in the originally closed PS2 design ever
got traction.
If Apple had ever let a reverse engineered version of their hardware out
of their control take hold, they would have had the same situation as
IBM w/o the resources to survive the competition.
--
**********************************
*
* note my email address is changing to jws at jwsss.com
*
**********************************
Actually, a lot of people spent a lot of time
reverse-engineering the
IBM BIOS. You really don't get a sense of this until you realize
that Phoenix not only made sure that the functionality of the BIOS
routines was the same, but that the routines themselves were located
at the same place in memory.
Having them in the same place in memory seems like a big waste of
time. I can't think of a single instance in which knowing where the
routines are located in memory can help me write a faster or smaller
program.
If the routines do the same thing, and are at the same place in ROM,
how different enough (to avoid copyright) from the originals could
they be? It's been a while since I looked at the tech ref listings
but they didn't seem all that horribly written (I know others will
disagree, I myself found a bug in the cursor handling in my 5160 ROM,
but that's not the point -- the point is that they weren't SO terrible
that they could be significantly improved or made smaller)...
28 Mar
28 Mar
11:50 a.m.
New subject: Reverse-engineering Mac ROMs (was Re: ROM BIOS)
jim s wrote:
Also as far as the Mac roms are concerned Apple never
published them in
any form, and may in fact have them under a copyrighted "unpubliished"
form which cannot be legally reverse engineered as was the IBM BIOS.
Actually, having purchased a Macintosh 128 that contained those ROMs,
there was no legal impediment whatsoever (at least in the US) to
reverse-engineering them.
In recent times, Sega tried to convince a court that any transient copy
of a ROM produced in the course of reverse-engineering is an infringement
of copyright, but the court rejected that concept.
If someone had really wanted to clone the Mac ROM as part of a
commercial venture, they would have needed to use two teams, one to
reverse-engineer and write specs, and a the other to write new code from
the specs. The fact that Apple published specifications (_Inside
Macintosh_) that covered much of the functionality would have helped
a lot.
A clone produced in this way would have had problems with each successive
release of Apple system software, because they implemented ROM patching
in ways that were very dependent on the locations of specific call
instructions in the ROMs. In other words, if ROM routine foo is
broken, and it calls routine bar via a vector in RAM, foo is patched
by intercepting the vector to bar, and having the patch check whether
the return address is a precise address within foo.
Eric
5891
days inactive
5892
days old
15 comments
9 participants
participants (9)
-
alexandre-listas＠e-secure.com.br -
cclist＠sydex.com -
dave06a＠dunfield.com -
eric＠brouhaha.com -
frustum＠pacbell.net -
ggs＠shiresoft.com -
jws＠jwsss.com -
trixter＠oldskool.org -
zmerch-cctalk＠30below.com