hi ben!on the model T's rst7 uses the following byte as a parameter but yes
otherwise. 503c is the published entry point for LCD and 1604 is POPALL which
pops all the regs off the stack and returns.so this conflict is resolved
anyway.yay progress!willardSent from my Galaxy Tab® A
-------- Original message --------From: Ben Wiley Sittler <[email protected]>
Date: 2/12/22 4:05 PM (GMT-07:00) To: [email protected] Subject: Re: [M100]
t200 addresses? from hterm.git I believe that in hex that sequence looks likee5
d5 c5 f5 ff 08 cd 3c 50 c3 04 16In machine code it might bePUSH HPUSH DPUSH
BPUSH PSWRST 7SUB HL-BC (undocumented!)CALL &h503CJMP &h1604On Sat, Feb 12,
2022, 11:26 Willard Goosey <[email protected]> wrote:sorry its been a rough week
will look at this tomorrow...thank you for thiswillardSent from my Galaxy Tab®
A-------- Original message --------From: B 9 <[email protected]> Date: 2/8/22
4:31 PM (GMT-07:00) To: [email protected] Subject: Re: [M100] t200
addresses? from hterm.git On Sun, Jan 23, 2022 at 4:47 PM Stephen Adolph
<[email protected]> wrote: Also, sometimes both entries can be valid.
Depends on the use case.That may be right. Both call 20540, asc("@") and 20528
print "@" to the screen, so I could see the reasoning for calling both 503CH
and 5030H as LCDPUT. However, the techref only lists 503CH and there's the
question of what do those extra 12 bytes of instructions do? I PEEKed and
they're not NOPs. So, what is the use case for calling 5030H instead?—b9P.S.
For anyone who can understand 8085 machine code, the extra bytes are: 229, 213,
197, 245, 255, 8, 205, 60, 80, 195, 4, 22.
