#: 20799 S10/OS9/6809 (CoCo)
    23-Feb-95  20:17:22
Sb: #Status calls
Fm: Rogelio Perea 72056,1204
To: Pete Lyall 76703,4230 (X)

Pete,

I found two or three system calls that might be useful. One of them actually
returns the caracter code found at the current cursor position, but it does it
only in a VDG screen. The other calls work in the bigger screens but only to
return which screen type is beign used and the other one returns the attributes
of the screen.

From this, it seems that the easiest thing to do will be to RUN the program in
a VDG window. The other SYSCALLs will probably get some use to determine the
screen type where the user is trying to run the program, and alert him of any
"illegal" attempt.....

..huh, I had been avoiding using SYSCALL for sometime now, but there's always a
first time :-)

Rogelio Perea


There are 2 Replies.

#: 20800 S10/OS9/6809 (CoCo)
    25-Feb-95  10:32:20
Sb: #20799-Status calls
Fm: Pete Lyall 76703,4230
To: Rogelio Perea 72056,1204 (X)

Syscall is a wonderful tool - it really opens up the whole operating system to
you from within Basic09, so look forward to using it!

Pete

#: 20801 S10/OS9/6809 (CoCo)
    25-Feb-95  11:05:47
Sb: #20799-#Status calls
Fm: Kevin Darling 76703,4227
To: Rogelio Perea 72056,1204 (X)

Rogelio,

There's a Syscall tutorial in Library 2 that I wrote a while back... it's
geared towards Basic09 under Level 2.  Do a "bro syscal" to find it.

best - kevin

There is 1 Reply.

#: 20802 S10/OS9/6809 (CoCo)
    25-Feb-95  13:45:45
Sb: #20801-Status calls
Fm: Rogelio Perea 72056,1204
To: Kevin Darling 76703,4227 (X)

Thanks Kevin!

I do it right now   :-)

Rogelio

#: 20803 S10/OS9/6809 (CoCo)
    25-Feb-95  13:46:43
Sb: #Basic09 tid-bits
Fm: Rogelio Perea 72056,1204
To: Larry Olson 72227,3647

Larry,

>> Not knowing what you are trying to do... >> How much time would you lose by
doing....

The program itself  *is*  not too complex.  I am just trying to cross- over to
Basic09 an old text  based arcade game I  did sometime ago in RSDOS. The
program is structured as follows:

- Setup variables - Scroll the screen --- This is done by printing a character
at a random position in --- the lowest text row thus scrolling the screen one
row upwards. - Check the keyboard for user input - Maneuver the play-piece
accordingly * Check for collision - If hit <exit> else go to <Scroll the
screen>

The  line marked with  *  is the troublesome part,  currently,  I have one
System  Call  that  returns  the  status  for  the current cursor position on
screen.  This  call works  only in  a VDG screen though; I had  hoped  to find
something  similar for the 40 and 80 columns wide text screens,  on which  it
seems the  ScreenArray(x,y) you suggest is the way to go.

As the  original program  (RSDOS)  was setup for the CoCo 1 and 2 text screen,
maybe  I should give  it a try using the array technique first and stear  away
of  using  SysCall,  which will be used  if the  array method doesn't give
satisfactory results......

I think  the main changes  will have to be  done to the scroll portion of the
program,  maybe by  tagging each  row with  the TAB position at which  the
obstacle is  placed,  then  checking for  same  horizontal coordinates at a
given point would be a breeze to do :-)

....got to go and boot up OS9!

Rogelio Perea Nogales Sonora MEXICO

"MEXICOCO - A CoCo with a *taste* that's really south of the border"

There is 1 Reply.

#: 20807 S10/OS9/6809 (CoCo)
    26-Feb-95  03:44:36
Sb: #20803-Basic09 tid-bits
Fm: LARRY OLSON 72227,3467
To: Rogelio Perea 72056,1204


 > - Setup variables - Scroll the screen --- This is done by printing a
 > character at a random position in --- the lowest text row thus scrolling
 > the screen one row upwards. - Check the keyboard for user input - Maneuver
 > the play-piece accordingly * Check for collision - If hit <exit> else go
 > to <Scroll the screen>

 Rogelio,

       The way you are describing the action, the ScreenArray(80,40), may
   not be needed at all.
       You say that the program will place a character at a random location
   on the bottom line of the screen, and then scroll to the top. There is
   the key, you already know the screen x,y location, because you put the
   character there, and as the character scrolls up, the x location stays
   the same, while the y location is decremented. You could just use 2
   variables for the player character and 2 for the target character.
       If I understand correctly, the program would be something like:

   DIM  PlayerX, PlayerY, TargetX, TargetY:INTEGER

   (* Place Player character in center of screen ? *)
   PlayerX = 40
   PlayerY = 12

   TargetX = RND(79) + 1
   TargetY = 24

   CurXY(PlayerX,PlayerY)
   PRINT "*";


   CurXY(TargetX, TargetY)
   PRINT "+";

   (* Here you would be doing your loop, checking for Player moves *)

   HitFlag = 0
   EndFlag = 0

   WHILE (HitFlag = 0 AND EndFlag = 0)  DO
       REM First erase Player character
       CurXY(PlayerX, PlayerY)
       PRINT " ";

       REM Scroll screen up, check for top of screen
       REM If you want to continue scrolling characters, you could use the
       REM EndFlag to tell you when to place another character at bottom
       CurXY(0,0)
       RUN gfx2("DELLIN")
       TargetY = TargetY -1
       IF TargetY < 0 THEN
           EndFlag = 1
       ENDIF

       REM do routine to check & move player character

       CurXY(PlayerX, PlayerY)
       PRINT "*";

       REM Check for hit

       IF PlayerX = TargetX AND PlayerY = TargetY THEN
           HitFlag = 1
       ENDIF

   ENDWHILE

   This example may be way off from what you are trying, but maybe it will
   give you some ideas. You didn't mention it but will you be using more
   than 1 target character at a time ? If so, these can be treated the same
   way but instead of just a TargetX,TargetY, you could use:
       Target(number, xloc, yloc)
   Which would keep track of all the targets. You might also look into using
   the Basic09 gfx2 command ("INSLIN"), which would allow you to scroll the
   screen down instead of the normal scroll up. Some more things you might
   try are, if you want to stay with characters, try making up your own
   character set with different objects, or you might try using GET/PUT
   buffers for larger objects.

   I hope this helps
   Larry

#: 20804 S10/OS9/6809 (CoCo)
    25-Feb-95  13:47:31
Sb: #Basic09 tid-bits
Fm: Rogelio Perea 72056,1204
To: Bob van der Poel

Larry,

It  is my  understanding that  you live in  Canada.... if so,  then it would
be  *quite*  a trip  for me  for a  cup of  coffee <grin>. Just imagine,
crossing  the US  all the way  from southern Arizona... maybe someday I'll
visit  Canada, a country  I always have  admired. Perhaps I'm  a bit of  topic
here --  about three  or four  years ago  I was a volunteer firefighter  here
in Nogales,  and a  family of (guess what) firefighters  came to visit us  at
the station and I had the chance to show them around,  what a  surprise  when
they said  they  were  from Ottawa  (is that  city's name well spelled?).  We
exchanged souvenirs, decals, baseball  caps  (with the  respective Department
logos).  They even  invited me to drop by their homes in  case of traveling by
those parts ....<sigh>...

Back to OS9 ... <click> ... I  will give it  a try to the STRING thing for my
...humble-little... Basic09 program :-)

Take care, and keep the coffee maker plugged in... you never know....

Rogelio Perea Nogales Sonora MEXICO


There is 1 Reply.

#: 20806 S10/OS9/6809 (CoCo)
    25-Feb-95  18:22:00
Sb: #20804-Basic09 tid-bits
Fm: Bob van der Poel 76510,2203
To: Rogelio Perea 72056,1204

Hmmm, seems like you have me and Larry a bit confused. So, I'll assume that the
message was for me...

>It  is my  understanding that  you live in  Canada

Yes, that is why I am so rash in making bets.

>I  will give it  a try to the STRING thing for my Basic09 program :-)

Please let us know how it works out.

>Take care, and keep the coffee maker plugged in... you never know....

It is always on. Mind you, I must warn you that we still have snow on the
ground here.

#: 20798 S12/OS9/68000 (OSK)
    23-Feb-95  20:04:09
Sb: #20789-IRQ Stack
Fm: David Breeding 72330,2051
To: David M. Horn 73260,242 (X)

 > Microware sets the IRQ stack size intentionally low to get good minimum
 > memory numbers for marketing.  If your system has a significant amount of
 > IRQ activity (such as serial I/O), this number should be increased
 > generously.

Thanks, David,

I think I'll follow Steve's lead and set it for about 1K Words.  Actually, I
don't have an _extremely_ lot of IRQ's to contend with, Steve probably has a
more intense usage than me, so this should probably take care of me.

I'll keep your info filed away, as it appears to be pretty inforative.

                         -- David Breeding --
       CompuServe : 72330,2051              Delphi :  DBREEDING
           ***  Sent via   InfoXpress/OSK - Vr. 1.02   ***

Press <CR> !>