[z88dk-dev] grafix.inc

[Stefano Bodrato]

Where exactly grafix.inc should be placed ?
You probably noticed that I'm keeping two copies of it (don't tell that a link
should be created..)

I'm using a quick trick to "port" the existing function onto the gray stuff;
they'll be ready before tomorrow ;-)


_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Stefano Bodrato]

Where exactly grafix.inc should be placed ?
You probably noticed that I'm keeping two copies of it (don't tell that a link
should be created..)

Yes I had! Rather annoyingly it should be kept in libsrc/ because we run
z80asm from the libsrc/ directory and not the libsrc/graphics directory.
Perhaps we should include it with "#grafix.inc" and then we can put it in
lib/ and it doesn't matter where we assemble from? You've done more work
on the graphics side than I have so what do you think?

I suggest to put it under the libsrc/graphics folder and to compile everything
"staying into" the libsrc folder.
The <INCLUDE "grafix.inc"> lines would simply become <INCLUDE
"graphics/grafix.inc">



_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Rudolf \/dev/random\ Polzer]

Dominic Morris wrote:

On Wed, 7 Mar 2001, Stefano Bodrato wrote:

Where exactly grafix.inc should be placed ?
You probably noticed that I'm keeping two copies of it (don't tell that a link
should be created..)

Yes I had! Rather annoyingly it should be kept in libsrc/ because we run
z80asm from the libsrc/ directory and not the libsrc/graphics directory.
Perhaps we should include it with "#grafix.inc" and then we can put it in
lib/ and it doesn't matter where we assemble from? You've done more work
on the graphics side than I have so what do you think?

I'm using a quick trick to "port" the existing function onto the gray stuff;
they'll be ready before tomorrow ;-)

Cool!

I have bugfixed some graphics routines and made lowlevel functions that
do not do swapgfxbk1() with a new naem:

putsprite_later

Where should I post them?


--
#!/usr/bin/perl
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################

_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Stefano Bodrato]

Rudolf "/dev/random" Polzer wrote:

Dominic Morris wrote:

On Wed, 7 Mar 2001, Stefano Bodrato wrote:

Where exactly grafix.inc should be placed ?
You probably noticed that I'm keeping two copies of it (don't tell that a link
should be created..)

Yes I had! Rather annoyingly it should be kept in libsrc/ because we run
z80asm from the libsrc/ directory and not the libsrc/graphics directory.
Perhaps we should include it with "#grafix.inc" and then we can put it in
lib/ and it doesn't matter where we assemble from? You've done more work
on the graphics side than I have so what do you think?

I'm using a quick trick to "port" the existing function onto the gray stuff;
they'll be ready before tomorrow ;-)

Cool!

Er.. I meant before "the end of tomorrow".... :-( but I'm in trouble, needless to
say.

I have bugfixed some graphics routines and made lowlevel functions that
do not do swapgfxbk1() with a new naem:

putsprite_later

Why a new name?
If they are more efficient and compatible with the previous ones, they're welcome.
If you think my old TI code is still necessary, send them directly to Dominic;
otherwise forward these to me..
Please keep the libraries as much "standard" as possible, and try to write "portable"
code. This will help with new platforms. As example:
- the sin/cos 3d demos run even on the zx81,
- it should be possible to write a library for MS Visual C++ / GCC and make the sprite
demo run on a Win32/Linux platform,
-etc...



_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Henk Poley]

You'll probalby know lots of them already, but I've found some new REX
websites:

unofficial REX messageboard:
(posted a message if somebody could help with info about programming the
REX 6000 in Z80 assembly)
http://63.236.73.104/boards/REX/

Forum about Xircom REX 6000 programs (add-ons)
http://www2.pdabuzz.com/Discussion/Forum42/HTML/000059.html

Dataslim-programs (should be compatible with REX 6000):
http://dataslim.angel.co.jp/ds2/download_adin.htm
And the sources:
http://dataslim.angel.co.jp/ds2/download_addin_src.htm

_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Stefano Bodrato]

Impressive libraries? Perhaps a cool one would be to do a VT100 graphics
library? Is that feasible Stefano?

I've been thinking at it a long time. The problems :
- Are the "Black block", "Upper half black block" and "Lower half black block"
standard characters ?
- I'd have to keep track of what already is on display (I don't think that a
"getchar" would work on a serial CP/M terminal).
- 80x50 graphics wouldn't be so beautiful...

)


_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers

[Rudolf \/dev/random\ Polzer]

Dominic Morris wrote:

On Thu, 8 Mar 2001 seiberdragan@... wrote:

They are not compatible to the other ones on the TI83. They do not
call cpygraph and therefore only draw on the buffer. That is, a
program not knowing of swapgfxbk and swapgfxbk1 would fail if my
functions are used.

Okay, if they only work on the ti83 then you should make the directory:

libsrc/graphics/ticalc/ti83

They are not 83-specific but the same when used on a 85. It is like this
C macro:

#define plot(x,y) { swapgfxbk (); plot_later ((x), (y)); swapgfxbk1 ();
}


And, which operations can the assembler understand?
Does
add a, (((173/25)%3)<<3)^17
work? I want to know this because I wrote a keyboard library function
that should better be inlined (ie asm("...")). But I use operators like
<< in the code...

[Rudolf \/dev/random\ Polzer]

Dominic Morris wrote:

Hi Rudolf,

[ti83/85 graphics routines]

Okay, if they only work on the ti83 then you should make the directory:

libsrc/graphics/ticalc/ti83

They are not 83-specific but the same when used on a 85. It is like this
C macro:

#define plot(x,y) { swapgfxbk (); plot_later ((x), (y)); swapgfxbk1 ();
}

Okay, I think they should go in graphics/ticalc then, the alternative is
to have to copies for a graphics/ticalc/ti83 and graphics/ticalc/ti85
directory.

And, which operations can the assembler understand?
Does
add a, (((173/25)%3)<<3)^17

Nope, '<<' doesn't exist, though you could easily multiply by 8 instead
(Or in z80asm speak (2^3)? Instead of '^' for XOR you should use ':', and
stick a '#' at the front to make it clear that it's a constant expression.

work? I want to know this because I wrote a keyboard library function
that should better be inlined (ie asm("...")). But I use operators like
<< in the code...

One of the problems with inline code is that it can increase the side of
the code substantially if it is used on multiple occasions. A call to a
keyboard handler will only use 3 bytes (excluding any library code)
whereas inline code could use a lot more..but I leave it up to you of
course!

I found out that an array-accessing macro and a poll routine should be
much better (but maybe generate bigger code).

Is it possible to check if di is running? The problem is

di
; ...
di
; ...
ei
; ... now interrupts are ENABLED!
ei
; ...

That is, can a function store if the interrupts are enabled and restore
that? Is that in AF?

--
#!/usr/bin/perl
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################

[Rudolf \/dev/random\ Polzer]

Dominic Morris wrote:

Hi Rudolf,

[ti83/85 graphics routines]

Okay, if they only work on the ti83 then you should make the directory:

libsrc/graphics/ticalc/ti83

They are not 83-specific but the same when used on a 85. It is like this
C macro:

#define plot(x,y) { swapgfxbk (); plot_later ((x), (y)); swapgfxbk1 ();
}

Okay, I think they should go in graphics/ticalc then, the alternative is
to have to copies for a graphics/ticalc/ti83 and graphics/ticalc/ti85
directory.

AFAIK they are not specific to ANY machine. They are just the same as
the normal functions, except that calls to swapgfxbk are removed and
calls to swapgfxbk1 are replaced by a ret. They will never hurt, but
they can really help on calculators with a screen double buffer (like
the 83).

--
#!/usr/bin/perl
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################

[dom]

One of the problems with inline code is that it can increase the side of
the code substantially if it is used on multiple occasions. A call to a
keyboard handler will only use 3 bytes (excluding any library code)
whereas inline code could use a lot more..but I leave it up to you of
course!

I found out that an array-accessing macro and a poll routine should be
much better (but maybe generate bigger code).

Fair enough..

Is it possible to check if di is running? The problem is

di
; ...
di
; ...
ei
; ... now interrupts are ENABLED!
ei
; ...

That is, can a function store if the interrupts are enabled and restore
that? Is that in AF?

Yes, ISTR that you can do it, I forget the exact way at present, but isn't
it something along the lines of:

ld a,i ; one of the flags holds IFF2(?> bit 2?
push af
pop hl ; return the value of the flags, high byte will be
equivalent to f,

So that a bit 2,h will give the status of interrupts enabled or not. It's
something like this but I'm not entirely certain! The best thing to do is
to try to find either a Spectrum Multiface ROM or a +D ROM and have a look
at the code around address 102.

Hope that's what you were asking for..

d.





_______________________________________________
z88dk-developers mailing list
z88dk-developers@...
http://lists.sourceforge.net/lists/listinfo/z88dk-developers