RE: A82: New Versions of CrASH...
[Prev][Next][Index][Thread]
RE: A82: New Versions of CrASH...
> > -> VAT compatible Relocation of Programs
> > Allows using external data files by a running program
>
> Would this allow for absolute addressing in external files? Say, not ones
> with just data for levels, but how about if I want to run
> commands from the
> external file, would the data need to be copied to an executable location?
The programs will be found through a VAT search... I may include a routine
you can call to find a program within VAT.
> > -> Several Newly added CrASH Calls:
> > CR_SpriteXOR ; draws clipped 8x8 sprite at GRAPH_MEM
> > CR_SprHtChg ; changes sprite's height
> > CR_GRBClear ; clears GRAPH_MEM - suggestion from Kouri
> > etc.
>
> Sounds alright, but I guess you decided not to go with the X by X
> sprites,
> and does the "CR_SprHtChg" routine change the "X" in an "8 by X"
> sprite? I
> never did get that answered... =P
Sorry, but X by X requires tremendous overhead, and I don't think I can go
on writing an extremely optimized one. I do, however, already have a very
quick 8x8 sprite routine at my disposal along with its sprite height changer
so I thought I might want to stick with that.
> > -> Macros for some op-code combinations
> > LD_HL_BC, NEG_HL, etc.
>
> I think I understand that Macros have the Compiler just copy that
> section of
> code into spots of the code whenever a referrence is made to that Macro.
> However, does this save space? Why not just include these two
> routines and
> "etc" as subroutines within CrASH?
Well, some macros take up the same space or a negligible amount over the
number of bytes required to simply do a CALL. (like 2 to 5 bytes, and CALL
is 3 bytes) The extra CALL/RET combo requires 27 clocks, so for
speed-sensitive code, I thought it would be better to use macros. I do plan
to have other macros too, like ADD_HL_A, and CMP_HL_DE, and the like.
> There's a small routine I use in my 83 programming that I find useful, so
> maybe its worth putting in, i dunno... When getting direct input from the
> keypad, the keyport value can be loaded into B, a call made to
> this routine,
> and the value in A checked upon returning from the subroutine...
>
> Direct_Input:
> ld a, 0ffh
> out (1), a
> ld a, b
> out (1), a
> in a, (1)
> ret
>
> This subroutine seems useful to me, that if a programmer was reading from
> many different keyports this repetitious code would not have to
> be included,
> which saves bytes in programs. Perhaps more people could use this
> technique,
> but perhaps it isnt signifigant enough to include. Whatever you
> think, just
> giving some suggestions... cya. =P
Actually, I use a similar technique, though that should not be a call, as I
explained above with the macros. I guess I can include it though, as some
people may find it useful.
-crashman
References: