Re: A83: How is it that ION was made?


[Prev][Next][Index][Thread]

Re: A83: How is it that ION was made?




As a general rule, I don't reply to threads like these because its silly and
will make me look stupid.  But at this point I don't care if I make myself
look like an idiot, because this is really pissing me off.

"I could easily make a better OS than ION (one with 83 program support) if I
had the information..."
...It's generally a bad idea to start out saying that you're better and can
do things better than other people.  That often makes people pissed off, and
you're not going to be getting the information that way.

"Yeah.  You don't have 1/3 of the ROM calls needed to port Penguins to the
83+."
...Say what?

"That's the first thing I could beat you at."
...Here's that competition thing coming in again.  I don't know about you,
but I think things go a lot nicer when people are helpful, and not saying
that they're better and can beat you.  (Yeah I'm shouting, but you got me
angry)

"Me and a friend
wrote CrASH, probably the best coded OS ever considering the limitations we
had (1000 bytes max)."
...I really don't want to hear about you bragging about yourself.  I'm not
argueing that Crash is not a good shell, but if the author has to praise
it...

"See my point about secrecy?  CrASH's source would be out if CrASH_Man
wouldn't complain about it." (In reference to "Yeah, I have the sdk :P")
...I suppose you think Joe makes the rules about the SDK.  It also seems to
me rather silly to be ranting about how wonderful Crash is, and how horrible
ion is for not releasing source, when crash's source is not released.
Regardless of what Crash_man says...

"If the calculator is crashing if you try to read past C000, it's because TI
doesn't want to let you.  That's what a disassembler is for.  It's obviously
possible to map the 32k of RAM into 8000-FFFF."
...Obviously....  So have you finished disassembling yet?

"Since Joe is being a prick by not telling anyone anything about the 83+, he
has an
effective monopoly on it..."
...First of all, Joe has no monopoly.  You'll notice in the ion archives,
that there are programs by TCPA and Ahmed, other sources as well.  When the
SDK is officially released by TI (note: this has nothing to do with Joe)
there will obviously be more information.  You'll notice that Joe provides
an include file so that you can do 83+ programming...
...Now, about that prick thing.  If there's one person around here who is
not a prick, it would be Joe.  You're being I prick, I'm being a prick by
responding to you, but Joe, is definitly not.

Now that I've shouted at you emmensly, I'm going to point out some of what I
consider to be "fatal" flaws of trying to do 83 "emulation" on the 83+:

"As for redoing RAM, you don't need that because you can patch games."
...I'm going to assume by this, you mean that instead of doing something
like moving ram around to conform to 83 standards, you're going to edit the
actual programs.  That sounds nice, except note these two parts of code:
ld hl,$8e30
or (hl)
...then...
ld hl,$8e30
ld (overhere),hl
Both of them start with a load to hl of the same number (8e30).  However,
one uses the number as a pointer, while the other as data.  If you decide to
patch this to the 83+ address (its somewhere in plotsscreen) the second
would screw up as you would load the wrong number.  But if you don't change
it, you read from the wong memory address in the first one.  Explain to me
how you get around that?

...Oh, and then there's that little Vat issue.  The vat on the 83 and 83+
are not the same.  There are (believe it or not) a number of programs that
access the vat directly.  I don't think thats something that could be caught
by a patcher.

...We'll pretend for a moment that you have your call table in place.  And
then, what happens when you call a reset address?  Oops, some of them
changed, you're out of luck.  You *could* patch, but some of the former
reset addresses, are not longer reset addresses, meaning you'd have to put a
call in, meaing you'd have to adjust all absolute addressing, which is a
large pain the butt (not to mention you could kill relative addresses as out
of range).  Thats quite a mess.

...About that rom call table.  You'll notice at some point that the header
for 83+ applications runs from $4000-$4080.  This means of course that you
can't have any asm code in that area.  That in turn means you can't have a
call table there.  That means calls located in that area, such as: divhlbya,
kbdscan, lcd_busy, cphlde, getcsc, etc wont work so good.

...Okay, fine, I'll concede that you could also patch for these addresses
and have them point somewhere else in the call table.  Have you noticed so
far how much patching we've had to do.  A whole lot.  I think I can venture
to say that a patcher of that type would not be on calc.  If its not on
calc, that means you have to convert on the computer, meaning, you can't
send between 83 and 83+ and run them.  Okay, everything good so far?

...Well, if you can't send 83 -> 83+ (or the other way around, whatever the
case may be), you're really going to have to remind me the point of this
emulator.  Have you tried converting a 83 source to an ion source (which
compiles for both the 83 and 83+ with no source changes).  There is almost
*no* work neccisary.  All you have to do is change call's to bcalls for rom
routines, and stick in the ion header (if you don't use standard equate
names, you'll have to do a touch of equating, but thats no big deal).  Thats
right, you follow those steps and you'll get 83 and 83+ binaries.

...My question is what makes more sense?  Spending 16k (or 32k whatever the
case may be) of space for an shell that will try to "emulate" the 83 (and no
doubt not be 100% accurate, as we've seen with attempts on other
calculators), or save space and convert to ion, where we have no bulky
shell, smaller programs, and it takes all of five minutes to convert (and no
extra time to compile both binaries).

...Someone is bound to say "well what if we make something that allows
binary compatability"?  That (I don't care what you say) is not going to
happen.  You'd have to implement all the conversions on calc on the 83+,
interface with the os to intercept linking, so you could unconvert them
before they are sent.  That basically means you'd have to setup an interrupt
so that you can intercept the linking routine to tell which calc you are
sending to.  Its quite a problem the interrupts are disabled in the linking
routines.

Perhaps there is a point, and I'm just missing it, if so, you're going to
have to explain it to me...If there is something there and you get it done,
great, but I see nothing at this point.

Sorry for responding, I couldn't help myself,

-Dan


----- Original Message -----
From: Barubary <barubary@home.com>
To: <assembly-83@lists.ticalc.org>
Sent: Saturday, October 02, 1999 10:41 PM
Subject: Re: A83: How is it that ION was made?

>
> Upstart my ass.  Go look at 82 assembly language.  Joe's sprite routine
> absolutely blew compared to me and CrASH_Man's sprite routine...  Also,
> since when has Joe made a display routine about twice as fast as the ROM's
> display routine?
>
> He may have a good reason, but just because he thinks it's a fatal problem
> doesn't mean it's impossible.
>
> Given the chance, I could write a much better shell than Ion.  Since Joe
is
> being a prick by not telling anyone anything about the 83+, he has an
> effective monopoly on it...
>
> -- Barubary
>
>




Follow-Ups: References: