Re: ASM Question
[Prev][Next][Index][Thread]
Re: ASM Question
the fifteen millionth time (slightly exaggerated) I wrote this:
Both have a z80 processor. similarly, your tv (probably) has an 80186.
Yet, you can't run a 8086 program on your tv somehow. The difference
in hardware is big. Other example: the Commodore Amiga, the TI-92, and
the Apple Classic II all have a M68k. yet, none can run another's
software.
The hardware differences are usually so huge that it simply isn't
possible. have you ever seen asm? you can only do stuff that the chip
can do, since you are programming in the chip's language. Can the chip
clear the screen? No, it can't. in the case of a graphic card system,
you'd have to tell the chip to tell the graphic card to clear the
screen. often that's not even possible, so you need to set up a loop
that turns all the pixels to black. In the case of the TI-8x, they all
work (fortunately) memory-directly, which makes it a bit easier, but
not much. you call the ROM instead, since the routine is already
there, and as such you won't have to reinvent the wheel, nor take up
memory when it isn't needed.
There's a difference. the locations are different. no big deal, you
say. ZShell programs call a shell (ZShell/CShell/Usgard, what have
you) to give them the correct location, since they even differ
between, say, 85 ROM 9 and 85 ROM 10. However, what does NOT differ
between 85 rom versions is the way the rom function would work. let's
take the display hex ROM routine. on the 85, you supply the number in
the register pair BC. On the 86, you supply it in HL. (No clue- just
giving a hypothetical example.) Is there any way we can make the code
use HL instead? not without recompilation and a special 'scanning'
program that goes over the source (on your ibm pc) and automates the
process. that's just one.
another: the ti-86 has page swapping on the RAM, due it it having
128k. ZShell programs don't call the shell to write to memory. there
is no way for the shell to 'detect' when this happends. This isn't a
multitasking processor, people. There are some more differences that
just make it impossible. not next to impossible, completely
impossible. Because even if you could write a program that takes an
85S file and converts it to an 86P and changes all the appropriate rom
routine usages and somehow magically (how I wouldn't know) insert
correct RAM swap routines, since the code is now bigger than it was,
loading a constant (such as the introtext. ie: Copyright(C) whatever.
from the wrong place. all permanent data is 'misaligned' any way to
align it? not without knowing where it starts.
Conclusion: you need to take your SOURCE, and write a rather complex
program that converts it to 86 source. so, you'd have to bug the
authors of programs. aside from the fact that no such converter is out
there, and that it would be next to impossible to write one that takes
care of eveything, timing is off now. Just like a turboed calc tends
to choke on almost all asm programs, so will you get problems here.
Now stop whining about it. it can't be done.
Follow-Ups:
References: