> >> But this string:
> >>
> >> C085 426F6F74206572 DEFM "Boot error"
> >> 726F720D0A DEFB #0D,#0A
> >> C091 50726573732061 DEFM "Press any key for retry"
> >> 6E79206B657920 DEFB #0D,#0A
> >> 666F7230726574
> >> 72790D0A
> >
> >Ah, no. You have to include the byte after #0A too!!! I bet it is a 0.
>
> Of course. I wanted to show that the string contained no "$" signs, so it
> was possible to just call function #09.

??? Frits Hilderink told me not to bet anymore because the byte after #0A
was a "$" sign!
Maybe your Dos-version is different.


> >No, it saves some time... :) It saves a CALL and a RET-instruction.
>
> Mmm... if it wasn't for the unjustified JP (and your smiley!) I could
> believe that but... no 8:D 8:D 8:D 8:D

Hey, it really saves time!


> > And
> >besides, they use 0 as terminate-character, and not "$"... (I don't
> >understand why, for god's sake why does the stringroutine use "$" as
> >terminating character??? CP/M-compatibility, okay. But then why did the
> >developers of CP/M choose "$" instead of a 0????
>
> Definitely CP/M legacy.
> Another source of *BAD HABITS* *:D

Yeah.


> >Well okay that's not a trick, I meant it as an expression. But if you
want
> >to see a Microsoft-trick, try to disassemble (and understand!) the first
> >part of the MSXDOS2.SYS-file.
>
> Mmm... you all guys seem very fond of the MSX firmware & system software.

Dos is nice to disassemble.


> Well, it should be, since this is the first computer I still had not the
> need to disassemble / reverse-engineer its ROM!!! 8:)

Phew, it will come, believe me.
I still need info on the H_BEXT (or EXTBIO) hook!!!
(and if I don't get it...)


> >But if you really want to know why they used JP: let's just say that JP
is
> >generally faster than JR, and you will never get 'out of range'-problems,
so
> >most programmers use JP all the time. I do too. I hardly use
> >JR-instructions. Only sometimes, when it's faster than JPs (for example
in
> >conditional jumps which are 'false' more than 60% of the times they are
> >executed).
>
> The best solution is an assembler with optimization capabilities. Again,
> like DevPac for ST & Amiga. In restricted memory and speed environments
> like all the 8-bit computers any byte and T-state saved has its weight (at
> least in your programmer's pride!) 8;)

Sounds really nasty!
An assembler modifying my own written source!
Why do I program assembly? I want to know exactly what happens.
How could an assembler distinct an interruptroutine where I need the speed a
lot from a diskroutine where space is more important???


~Grauw


--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<
          email me: [EMAIL PROTECTED] or ICQ: 10196372
             visit the Datax homepage at http://datax.cjb.net/
MSX fair Bussum / MSX Marathon homepage: http://msxfair.cjb.net/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<


****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****

Reply via email to