You need Asm( for it. Instructions are in the earlier post.
By "smaller ways" I mean one-byte instructions that do the same thing as the three-byte bcall.
Asm(30) is the same as Asm(EF4072) (bcall(_FPAdd)).
PTR:Asm(20) is the same as Copy(PTR,E8478,9) and the same as PTR:Asm(EF417A) (bcall(_Mov9ToOP1)).
ACagliano wrote:
I would use Basic, except I need an ability to read data, held long term, in appvars, which basic doesn't support. And, since I'm a huge fan of programs being stable on their own (no external stuff needed), I would rather not need an asm routine or third-party app to do it. That's my dilema.
You know that I'll continue to recommend you use the relevant Celtic III libraries, as provided by Doors CS (and of course Celtic III itself, if you hate Doors CS for some reason).
I understand your recommendation, Kerm. I think I will wind up using DoorCS's libraries. As a programmer, tho, I just don't like relying on another app for functionality. It's a hangup I have. lol.
Would this render the image onto the buffers? And what what b_calls would put the two on the screen to make greyscale?
Code: .nolist
#include "ti83plus.inc"
#include "dcs7.inc"
.list
.org $9D93
.db $BB,$6D ; AsmPrgm
splash:
ld bc,Image_Layer0
ld hl,$9340
ld (hl),bc
ld bc,Image_Layer1
ld hl,$86EC
ld (hl),bc
Image_Layer0:
[giant fracking_data]
ld (hl),bc is not a z80 instruction, have you tried assembling this?
No. I'm on my mac side, which doesn't have an assembler. I'm just doing some rough scratchwork.
Ok, well it's not an instruction, and anyway you can't copy 768 bytes without a loop(ing instruction), LDIR for example.
Code: ld hl,Image_Layer0
ld de,$9340
ld bc,768
ldir
; same idea for the other half
Ok. Thanks, now assuming I have that done right for those two buffers, what are the b_calls that are needed to put the two on the screen?
You'd better use ifastcopy or fastcopys to copy the main buffer to the screen, for grayscale you have to use some other commands.
to use fastcopy:
Code: call ifastcopy
I am interested in greyscale for it...
This is to return a 2-byte random number.
ld b,256
call IRandom
push a
ld b,256
call IRandom
ld l,a
pop a
ld h,a
ld (xposition),hl
That work?
wrong, you cant load 256 in a 1-byte register. you should do ld b,255 (=$FF)
oh. lol. thats a stupid error.
Because 256 = %100000000
There are no b_calls for grayscale. (None of TI's apps or OSes have grayscale, anyway.) You have to write your own screen-writing routine (straight to the port) to get grayscale to work. There are some sample codes floating around that you could use for that.
Can I have a link to one, if you get the time?
ACagliano wrote:
No. I'm on my mac side, which doesn't have an assembler. I'm just doing some rough scratchwork.
The Doors CS SDK works perfectly on Macs. You can't just copy the data once for grayscale; there's nothing native that deals with it. You need to use a package like Jim E's Grascale Programming Package (GPP 1.1), which installs an interrupt that constantly switches the screen data between the two buffers.
Well, is there no routine to copy the secondary buffer to the screen? I know there is one for the main buffer. I'll just put the two routines in a while not (getCSC) loop. Only the splash screen is to be greyscale, and its the whole screen. Wouldn't that be easier than an interrupt?
You could easily modify iFastCopy to display an arbitrary buffer.
FWIW,
this reference is really great for looking up what instructions you have, and how they work. Also, for code, could you please use [ code ] tags (without the spaces). Thanks
To add on to what Souvik said, there is a
routine in DCS that does what you want (Really MOS, but DCS includes it
)
souvik1997 wrote:
You could easily modify iFastCopy to display an arbitrary buffer.
As Tanner just ninja'd me to say, the DCS SDK mentions fastcopy. Yes, if you're just making a single grayscale splash, that is much, much easier.
