
       ICTARI USER GROUP             ISSUE 51                November 1997

              ___   ______     ___       _________   _________   ___
              \__\  \   __\    \  \__    \______  \  \   _____\  \__\
                ___  \  \       \  __\     _____\  \  \  \         ___
                \  \  \  \       \  \      \  ____  \  \  \        \  \
                 \  \  \  \_____  \  \____  \  \__\  \  \  \        \  \
                  \  \  \       \  \      \  \        \  \  \        \  \
                   \__\  \_______\  \______\  \________\  \__\        \__\

                     *   m   a   g   a   z   i   n   e   *

     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                       I C T A R I   U S E R   G R O U P
       G Greenway, 8 Denmark Road, Reading, Berks, RG1 5PA. 0118 756668
                 http://www.elis.demon.co.uk/ictari/ictari.htm
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 51                                                        
                              ==================

         ASSEMBLY:          Translator program
         
         GFA:               Sampled sound routines
         
         HISOFT BASIC       Cadenza address book with sources
         
         STOS:              GEMMA (Use GEM from STOS. Latest version.)
                            Scrolling routines
                            STOS updater
                            STOS Falcon Extension
                            Joystick extension
                            Code to display Spectrum 512 images
                            Starfield code
                            STE extension
                            Quartet track player
                                                    
         MISC:              Current membership list
                            Index for issues 1-50         
                                                                                                                                                                                                               
    -------------------------------------------------------------------
 
                                   EDITORIAL
                                   =========
                                   
    Hello again. Well, this issue was  almost on time. (Don't hold  your
breath for issue 52.  it'll be out  in the new year.)  It's been a  very
good month for ICTARI on the WEB. Since I last updated the pages the 5Mb
site has shifted 47Mb of  data ! There are  three sorts of feedback  the
form on the WEB-site generates:

1) An e-mail with no comments and half the fields left blank. 
(Response: "Harrumph, more mail to delete !")

2) A short reply something along the lines of "great site" or "I wish  I
had found this ages ago". 
(Response: Well, you might not get  added to the members list, which  is
largely an irrelevance  if you  get ICTARI from  the 'net,  but it  does
cheer me up and the next issue might come out quicker !)

3) Offers of submissions or questions to go in the magazine.
(It *can* happen !)
           
    This seems to have turned into  the STOS special issue. Well, so  be
it. The idea of "STOS 2000" really excites me. Tracking down the authors
and setting up  a small  consortium to  sell STOS  as cheap  licenseware
would be  a  great  thing  to  happen.  Imagine  an  integrated  set  of
extensions along with  a compiler version  of GEMMA and  a GEM  friendly
editor ! In terms  of power and  ease of use, STOS  could become the  ST
equivalent of Visual BASIC. How's that for an idea ? Visual STOS  anyone
? (There's a  visual assembler  for the Falcon,  I will  investigate...)
Hello to another new member !

                            Have Fun,
                                  Giles           
                                                                                               
    ------------------------------------------------------------------- 
                                                          
                                CORRESPONDENCE
                                ==============

To:     ICTARI
From:   Paul Jones
Re:     GEMMA
                            
* Official GEMMA document by Paul Jones
* GEMMA now, the myths and the future...

    If I now could go back in  time to when I started the GEMMA  project
and tell my old self about what it's like now...

    A few people fail to realise that GEMMA - GEM in STOS - is possible.
In fact, a few also think that GEMMA "imatates" GEM, having some sort of
routines to bring up alerts/dialogs/menus  etc. Don't believe it!  GEMMA
uses the *REAL* GEM system on your machine.

    It is also said in the rules  of STOS that it cannot multitask,  use
the GEM mouse pointer  et al. Again, this  is completely wrong. As  from
GEMMA v1.62 the  new STOS loader  (GEMMA STOS) can  work with  MultiTOS,
effectivly multitasking.  However, you  can't multitask  with real  STOS
programs, just programs which use the GEMMA system. You can create  real
GEM programs which multitask and are unidentifiable from STOS  programs.
GEMMA programs can even register their name in the 'Desk' menu and other
programs can  be  started alongside  it.  The system  can  even  execute
programs with command lines and send VA starts to programs which support
it.

    GEMMA can also work in any number of Falcon resolutions,  effectivly
returning back to the  one you were in  before STOS changed  resolution.
There are no memory problems anymore.  The mouse works fine... I am  now
working on  a system  which  lets you  edit your  STOS  files in  a  GEM
window!! But this won't be available for some time in the future.

    If you have any  replacement fileselectors, or  just even the  plain
TOS one, they can be called too. The new modern GEMMA programs can  even
use Thomas Much's BubbleGEM and  if programmed correctly, OLGA!! I  have
even programmed routines to make  GEMMA programs display .HYP files  via
ST-Guide.

    In short, with the GEMMA/STOS combo  you can access ALL of GEM,  not
some, or even immatate it - all.

* The technical details, what GEMMA actually does.
* A brief rundown...

    It's pretty easy  to access  GEM from  machine code,  which is  what
GEMMA actually does. All it required is a list of addresses in d1.l  and
the function code #200 in d0.w, then a trap 2.

	move.l	#aes_params,d1
	move.w	#200,d0
	trap	#2
	
aes_params	dc.l	control,global,int_in,int_out,addr_in,addr_out
control		ds.w	5
global		ds.w	14
int_in		ds.w	16
int_out		ds.w	7
addr_in		ds.l	3
addr_out	ds.l	1

    The opcodes for  the AES command  go in global,  with the extras  in
int_in/addr_in,  and   after   the   call,  possibly   coming   out   of
int_out/addr_out.

    Using this method you can access every AES command, but will not  be
able to access it fully. STOS won't  let you click on object etc. To  do
this you first need to restore the GEM pointer.

    There are two things to do to return the pointer, first you need  to
restore the  actuall  code. The  address  of  the mouse  routine  is  at
kbdvbase+16. Get  this before  STOS and  return with  initmous in  STOS.
Also, do display the mouse first hide the STOS one, then return the  VBL
pointer in the VBL list to the GEM one... et volia the GEM mouse pointer
will be around. To see it, try changing the palette to $777,$700,$70,1.

    Memory is another problem, STOS assumes it has all memory, malloc -1
(trap 1,$48,.l-1) will  return a  very small  amount of  memory for  the
AES/VDI  to   use.   This  is   terrible   since  now   we   can't   use
windows/resources/menus etc. The only solution is to reserve some memory
before STOS starts, STOS then checks memory and reserves it all. We then
deallocate the memory and we have memory space for the AES, this is  one
of the functions the GEMMA acc served for.

    Now we need  to restore  the screen. GEM  assumes the  screen is  at
physic and logic,  but STOS changes  these address, so  we need to  know
what they were before, and change  them back later. If you are  bothered
about Falcon resolutions you  need to know about  vsetmode -1... as  you
can see it's a bit  of a nightmare. The GEMMA  acc was needed to  return
these addresses, but that was too tedious.

    So GEMMA  STOS was  created.  This is  a  modification of  the  STOS
loaded, which before changes all the  settings, makes a copy of them  in
it's data storage space. In STOS, the initgemma command finds where this
information is and sets the settings back unnoticed to the user.

* Editing STOS files

    Currently you need  to be  in a standard  ST resolution  to edit  in
STOS. If  you aren't,  you get  garbage as  text output.  I'm hoping  to
create a  new input  system  which replaces  WINDO102.BIN in  your  STOS
folder you can edit in any resolution, Falcon or not.

-- 
 _____                                                         _____
/\  _ `\    * It's good to talk, but even better to email! *  /\___ \
\ \ \L\ \     * Internet email: paulat.jones@zetnet.co.uk *   \/__/\ \
 \ \ ,__/             * PJCO & GEMMA member 1. *                 _\ \ \
  \ \ \             * Check out the homepage at: *              /\ \_\ \
   \ \ \   * http://www.users.zetnet.co.uk/pjones/home.htm *    \ \____/
    \/_/     * HBASIC tutorial writer for Atari Computing *      \/___/
                                                                
    -------------------------------------------------------------------

To:      ICTARI
From:    John Nicholas Oakes
Re:      Gasteiner hard drives

    Please could you help  me with my hard  drive. I have been  recently
getting an odd noise from it like something is slipping inside. It is  a
105 Mb from Gasteiner, is it serious as nothing is affected by it at the
moment.

    -------------------------------------------------------------------

To:      John Nicholas Oakes
From:    Giles Greenway
Re:      Gasteiner hard drives

    I have a Gasteiner drive attached to my old ST, and I have cause  to
regret my decision  ! Do you  have one  with a cable  with nasty  silver
plastic  connectors   ?  That's   the  Top-link,   its  rather   sketchy
implementation of the SCSI command set gave me all sorts of trouble when
I wanted to  connect a CD-ROM  drive. Sometimes I  needed to wiggle  the
cable to get the machine to boot ! This is beside the point however...

    Do you get the noise  all the time or just  when the drive is  being
accessed ? Maybe some of the partions are a bit fragmented. If not, then
I don't know. If it works, I  suppose it's okay, but you should  address
the issue of back-up  anyway. I just  about managed to  back up a  270Mb
drive using  ST-Zip and  floppies, but  it was  quite painfull.  A  nice
option would be to get a SCSI Zip  drive (go to an ST dealer to get  the
software, you might try HiSoft) as they have removable 100Mb  cartidges,
perfect for back-ups.  I'm sure  the through-port on  your current  hard
drive could take it.  If the worst happens  and it dies completely  then
the Zip drive would make a respectable main drive anyway. You'd have  to
ditch the Top-link and  get the much better  ICD link II instead.  There
remains the slight problem of what to back up the Zip drive with !  Good
luck.
    
    -------------------------------------------------------------------

To:      ICTARI
From:    Mario Becroft
Re:      Scrolling in GEM Windows

    Hello,   

    I did send you an email about  the smooth scrolling in a GEM  window
for ICTARI, but  it doesn't seem  to be there  in issue 50  that I  just
looked at.

    Anyway, some comments  more on the  subject and particularly  letter
included in issue 50 from Levien van Zon:

    You don't need to bypass the rectangle list to do smooth  scrolling.
Instead, simply handle each  rectangle as you  would the entire  window.
Well perhaps this is  slower, maybe the slight  slowness of walking  the
rectangle list realy does make a difference. Perhaps 1% slower? 0.5%?  I
really don't think it makes any practical difference.

    I don't follow the bit about  the slow scrollbars. Perhaps this  was
under a slow AES like AES 4.0.

    Double buffering is really not possible under GEM. There's no  point
even trying to hack together something like this that half-works,  IMHO.
Yes, you could do it if you locked the screen, but why use GEM at all if
the screen is simply  going to be locked  all the time anyway?  Blitting
the whole image  into the window  (as explained in  ICTARI #50) is  like
double buffering. But if you have slow blitting, there really isn't  any
way around it. Just get a better graphics card.

    Also a custom blitting routine  is certainly not recommended,  since
it would be impossible to make it fully compatible with all displays.

    So, provided the blitting is fast  enough you don't have a  problem.
If the blitting is slow then you just have to put up with it (or upgrade
your hardware).

    But even on my TT in VGA 16 colour mode, where the blitting seems to
be about as slow as it gets, a real-time game I'm making in a GEM window
works perfectly  smoothly (I  guess  about 15  frames per  second).  And
that's with  code  that is  extremely  NOT speed-optimised  (e.g.  using
floating point  math for  the  display of  vector  graphics). If  I  was
writing for speed I could probably have got it up even higher than that.
Admittedly that is  with the  window only about  one third  of the  full
screen size. It does get slow when  the window is the size of the  whole
screen,  but  hopefully  a   graphics  card  with  high-speed   blitting
capability would fix that.

    -------------------------------------------------------------------

To:      Mario Becroft
From:    Giles Greenway
Re:      Scrolling in GEM windows

    Oops, sorrry about  that, I *do*  get the odd  mail problem now  and
again. Can't wait to see the game.

    -------------------------------------------------------------------


To:     ICTARI
From:   Philip Eddies
Re:     STOS

  Dear ICTARI Programmer's  User Group,
   I am writing  to you about  the programming language  STOS and I  was
wondering if you would answer some questions that I have.

1) Do you know of any to play  Quartet music in STOS ? If you do,  could
you please send me a listing to show me how to do this ?

2) Do you know of any way of loading .SPU files into STOS or of any  way
of loading .TGA  files ? I  know that  you can load  .TGA files  because
there is a program called Spectra which can load up .TGA files and a lot
of other files as well, and this was made using STOS.

3) Is there a limit to the amount of extensions you can have in STOS ?

4) Could  you please  send  me a  listing  to show  me  how to  do  text
scrolling ? If you can't send me  a listing then could you just tell  me
how to do it ?

5) Do you  know of  any extension  or any other  way to  read the  other
joystick port so that you can have two player games with two joystick ?

6) Now for my last question: HOW THE HELL DO I MAKE STARFIELDS that look
good like in Star Trek or just 2D ones would be very very very helpful.

                        P. Eddies
                        
P.S.
    I have an Atari STe with 1Mb, so could you make sure any listings
    that you send me work on this computer ?
    
    -------------------------------------------------------------------

To:     Phil Eddies
From:   Giles Greenway
Re:     STOS

    Hello and welcome ! -Don't ask much, do we ? Are all these questions
to do with one  single project ?  -It doesn't bear  thinking about !  It
would be nice to see some work in progress so we can all see how  you're
getting on. I'm not much of a STOS user, but I've had a go at trying  to
answer your  questions,  perhaps others  would  like  to chip  in  ?  To
business:

1)  I  *did*  find  an  extension  to  play  Quartet  tracks.  Look   in
STOSPLAY.ZIP. As I said, I'm not a STOS user so all this is untested.

2) .SPU files ? Certainly, look in SPECSHOW.ZIP. The only TGA decoder  I
found was in the STOS Falcon extension. Whoever wrote that other program
probably just had code to load in  the binary file and did all the  hard
work. Turn your  .TGA files into  .SPU format with  good ol'  ImageCopy,
it'll be easier.  (I can dig  out the  specs for the  Targa format  next
time, if you're interested.)

3) -No idea  ! If  there is  a limit, I'm  sure one  the extension  will
conflict with the others and cause a crash before the maximum number  is
ever reached...

4) Scrolling ? I refer you to Mr Railton ! See below. Get your font from
a sprite bank and just paste the characters down I suppose....

5) I  found two  joystick  extensions, one  in  the STE  extension,  and
there's also a more specfific, but more limited one.

6) Would you believe, I found a starfield extension as well !

    I really ought to thank the people who made this all possible.  Tony
Greenwood of STOSSER software maintains and excellent WEB-page, (go  see
it from the links section if you are reading this online) Anthony Jaques
wrote quite a few STOS extensions, and his pages are worth a visit  too.
All the extensions I put in this  issue were grabbed from the STOS  file
site. Enjoy.

    -------------------------------------------------------------------

To:     STOS users
From:   Philip Eddies
Re:     STOS routines   
      
                              STOS ROUTINES
                             ---------------

FOLLOW THE LEADER
------------------

SPRITE FOLLOW OTHER SPRITES

10 KEY OFF : HIDE : CURS OFF : MODE 0 : UPDATE OFF
20 LOKE $45A,BUNT(START(1) TO START(1)+LENGTH(1),"PALT")+4 : WAIT VBL
30 DIM X(9),Y(9)
40 FOR T=0 TO 9 STEP 3
50 SPRITE T+1,X(T),Y(T),1
60 NEXT T
70 FOR T=9 TO 1 STEP-1
80 X(T)=X(T-1) : Y(T)=Y(T-1)
90 NEXT T
100 X(0)=X MOUSE : Y(0)=Y MOUSE
110 UPDATE : WAIT VBL
120 IF INKEY$<>" " THEN GOTO 30
130 DEFAULT : END

BOUNCER
--------

THIS LISTING ENABLES YOUR SPRITE TO BOUNCE AROUND HITTING OF THE LEFT
AND RIGHT OF THE SCREEN

10 KEY OFF : HIDE : CURS OFF : MODE 0
20 X=20 : Y=20 : SX=4 :SY=0
30 SPRITE 1,X,Y,1
40 X=X+SX : IF X>300 OR X<4 THEN SX=-SX
50 IS SY<19 THEN INC SY
60 Y=Y+SY
70 IF Y>184 THEN THEN Y=184 : SY=-SY
80 WAIT VBL
90 IF INKEY$<>" "THEN GOTO 30

SPRITE PALETTE
---------------

A QUICK WAY TO GET THE PALETTE FROM A SPRITE BANK

10 H=HUNT(START(1) TO START(1)+LENGTH(1),"PALT")+4
20 LOKE $45A,H : WAIT VBL

CHANGE THE FREQUENCY
---------------------

IF YOU WANT TO CHANGE FREQUENCY WHILE YOU ARE IN A PROGRAM, TRY:

<< FOR 50 Hz >>
(This is the normal freqency)

10 WAIT VBL : POKE $FFF820A,254

<< FOR 60 Hz >>

10 WAIT VBL : POKE $FFF820A,252

ROUND IT
---------

TO ROUND A NUMBER TO THE NEAREST 16

10 X=X AND $FFF0

MAD MAX MUSIC
--------------

ON THE WHOLE STOS CHIP MUSIC IS PRETTY CRAP,SO HERE IS A ROUTINE TO PLAY
MAD MAX CHIP MUSIC

10 RESERVE AS WORK 10,30000
20 BLOAD "MAD_MAX.MUS",10
30 DREG(0)=1 : CALL START(10):REM < INITIALISE MUSIC #1 >
40 LOKE $4D2,START(10)+8 : REM < PLAY ON INTERRUPT >
50 WAIT KEY
60 LOKE $4D2,0 : REM < DISABLE INTERRUPT >
    
    -------------------------------------------------------------------                                      
                                
From:    Jason J Railton
To:      Stephen Bruce
Re:      Atari Monitor Cable

    I use a  Sony portable  TV for  my ST,  which has  a full  RGB-Scart
implementation  (unlike  some  equipment   which  just  connects   Audio
left/right and composite Video in/out - 'AV-Scart'). When I tried to buy
a lead,  I found  that it  didn't  work. I  found some  instructions  on
building my own, and found that this used this 'combined sync' line.  It
still uses vertical sync, but has 'combined sync' instead of  horizontal
sync.

    What it  is, in  fact, is  the composite  video line.  Your  display
device then takes  the horizontal  sync information  from the  composite
video image, but takes the colour information from the RGB lines to give
a sharper picture.

    The Sony PlayStation also  has an RGB-Scart  lead available for  it,
which does the same  thing (although with stereo  audio). This leads  to
another problem though.

    Most equipment,  and  this  includes  nearly  all  video  recorders,
satellite systems, cable TV boxes and  switcher boxes that have a  Scart
connector, have only the  AV Scart connected.  That is audio  left/right
and video  in/out.  Sometimes there  is  also a  switching  line,  which
carries an  on/off voltage  to signal  to the  receiving device  that  a
picture is being sent. This is how some TVs automatically switch over to
the video channel when you press 'Play' on the video.

    The problem comes if you plug an RGB Scart into one of these devices
rather than straight  into your TV.  The RGB lines  stop there, and  the
only picture that gets through to  your TV is the composite signal.  You
may not  even realise  what is  going on,  but you  will get  a drop  in
picture quality.

    Now you _can_  buy switcher boxes  that switch all  21 lines in  the
Scart socket, but these tend to be the big expensive ones. Most salesmen
DO NOT KNOW the difference, and some items will say 'Switches all  Scart
lines' when it only does AV-Scart.  So, go to somewhere like Maplin  (or
Tandy at a stretch) but do not hand over your money unless the assistant
is willing to unscrew the box and show you that all the lines are  wired
up. Seriously. Even the guys at Maplin couldn't be sure from the product
descriptions in the catalogue. (By the  way, the '21' comes from the  20
pins in the socket  plus the shielded metal  casing. Connecting this  is
only necessary if you're using very expensive screened cable too).

    Most AV switchers are little boxes on the end of a cable for under a
tenner, but for the full 21-line switchers expect to pay 10-15 quid  for
the box then at least another 10 for a full-line cable to connect to the
TV.

    One last chance though - I bought Maplin's AV switcher, which  comes
in a pop-apart  narrow black plastic  box. It has  Scart sockets on  two
sides, a red push-button at one end and the TV lead out of the other.  I
opened it up and found a long 4-pole 2-way changeover switch and the two
Scart sockets mounted on a PCB inside. The ground lines were common, and
it switched video and left/right audio.

    I bought this, a length of 9-way  cable (of which I needed 7  lines)
and a longer 6-way  2-pole changeover switch, all  for about 12 quid.  I
de-soldered the cable  and the switch  that was in  there (use a  solder
sucker and a lot of patience to ease out all 12 legs) and scratched  off
the connecting lines of the circuit board (make sure you get them all).

    Then I drilled 6  new holes and fitted  the longer switch (it  still
fits nicely inside the casing).

    Next I  took the  Scart plug  off the  lead from  the switcher,  and
connected it to  my length of  cable. The connections  were as  follows,
looking at the _back_ of the Scart plug:

                  B       G       R     Gnd
                  |       |       |    /
    .----------------------------------------.
    | 1   3   5   7   9  11  13  15  17  19  |
    |                                        |
    |   2   4   6   8  10  12  14  16  18  20 \
    '------------------------------------------'
           /    |                 /     |    \
        Gnd     L-Audio     V-Sync     Gnd    Composite

In summary (in case that print is slightly off):

    Red -   15 (picture)
    Green - 11 (picture)
    Blue  -  7 (picture)

    Vert. - 16 (sync)
    Comp. - 20 (sync/video)

    L-Aud -  6 (audio, left channel only)

    Gnd   -  4, 17 & 18 (ground lines)

    There are  three separate  ground lines  for audio,  video and  sync
separately (I think), but most systems connect them together  internally
so I only used one ground line and wired it to all three.

    Note the colour of each  line you use, for  wiring the other end  of
the cable up. Using the red, green and blue cores for R, G & B (in  that
order) surprisingly enough is not compulsory... but why not, eh?

    If you want stereo audio, tough! They don't do a bigger change  over
switch. Anyway, my  ST is mono  and my PlayStation  is connected to  the
Hi-Fi.

    Handy tip - always fit the Scart plug to the cable first in any  job
- that way it doesn't matter if you forget to slide the screw-cap of the
Scart plug onto the cable first!

    Another Handy Tip - if you change from first to third person in  the
middle of a set of instructions, forget it! Carry on regardless. Anyway,
if you've  read  this far,  you've  got to  be  interested in  doing  it
yourself.

    Then came the wiring  - I linked the  ground lines together, and  to
ground on my new TV lead. To the centre pins of the change over switch I
connected the other  six lines.  These were for  the R,  G, B,  Vertical
Sync, Composite (for h-sync) and Left audio connections. I preferred  to
connect these to the  loop connectors on  the top of  the switch, for  a
more secure fit than to the pin legs.

    The next bit  is to take  wires from  the two Scart  sockets to  the
input pins of  the switch. Do  one whole socket  first, then the  other.
That way you won't forget which  side of the centre pins you're  working
to. Note that you can wire to the legs of the switch under the board, or
to the loops on the top. Be careful not to melt the insulation of the TV
lines that you've already connected.

    Finally, there's a  thick sleeve  that grips  the old  TV cable  and
holds it in place where it passes out of the casing. I slit this  sleeve
up one side,  pulled it  off and  slipped it around  the base  of my  TV
cable. It still gripped the cable quite well. Then, all I had to do  was
clip the casing back on.

   And by crikey, it worked!

    Now, I can't be held responsible  for any of this you try  yourself.
If you take my word for it, you  must be mad. I'm _pretty_ sure the  pin
connections are  right, so  there you  go. If  they're not  right,  then
either I'm  wrong or  reality is  inconsistent. And  these were  checked
recently. So...
...

... And that's all I have to say about RGB-Scart.

    -------------------------------------------------------------------

From:    Jason J Railton
To:      Stephen Bruce
Re:      Parallax Scroll

    I'm glad I managed to impress your woman. If nothing else, at  least
it gave  you a  (presumably)  well-deserved night  off! (That  might  be
censored. Who knows? But  since I got my  pink Ictari-subs final  demand
last month, what have I got to  lose? {Pink is so much more polite  than
red, don't you think? Anyway... } Anyway... ) anyway, what was I saying?

    Oh, yes, for your information that  parallax scroll is very hard  to
do. It took longer to get it going that fast than the 3D maze stuff.  It
actually relies on a  piece of code that  re-writes itself based on  the
scroll position to be as efficient as possible.

    I've  added  some  bits  and  pieces  to  the  demo  for  lives  and
player-collisions, but there's not much more to see yet. I've also  done
a bit of work on  my block (map) built  version of the parallax  scroll,
but that  needs to  be optimised  because although  it runs  in under  2
frames, I don't have much time left for sprites. It does however have  a
small vertical scroll range as well as the horizontal scroll.

    -------------------------------------------------------------------    
    
From:    Jason J Railton
To:      Giles Greenway
Re:      Sound from Machine Code
         
    The XBIOS  function  Dosound wouldn't  work  in my  game  because  I
replace the system vertical blank interrupt entirely with one of my own.
As for the Giaccess function, does it cause any delay when it  operates,
in order to communicate with the PSG chip ?

    And if I just write data to the PSG adresses, do I have to wait  for
a certain condition before I send another  byte (as you have to do  with
the keyboard chip) ?
   
    I've considered  setting up  the three  channels to  tone,noise  and
tone+noise, then varying the volume of  each channel when I want a  hum,
explosion or a shot.                                                     

    -------------------------------------------------------------------    

To:      Jason J Railton
From:    Giles Greenway
Re:      Sound from machine code

    I don't use assembler, so  I can't be much help,  but I can find  no
mention of any delay when using Giaccess. You might have to just throw a
little test proglette together and see what happens. Good luck !

    I still can't get Buzzsaw to work on my Falcon, (Wahhhh. Bawl.)  the
whole thing seems  slow, especially  the joystick, and  the fire  button
doesn't respond.  Might it  be  worth trying  some  of the  STOS  update
programs that come with this month's issue ?

    -------------------------------------------------------------------    

From:    Jason J Railton
To:      Everyone
Re:      Scrolling in STOS

    I've been trying out  a new method of  scrolling. It's currently  in
STOS but I'm  going to  convert it  into machine  code for  use in  STOS
programs.

    Normally, scrolling is done by storing a backup screen (or  screens)
for copying out to the display. This back screen may be shifted  around,
and re-written at the edges with data  drawn from a map of blocks.  This
gives the impression of a continuously  scrolling area but cuts down  on
the data storage required for a huge multi-screen area.

    The main disadvantage is that horizontal scrolling by anything other
than 16 pixels is very time consuming. For 16 pixel scrolls you can just
change a pointer, to offset data by whole words. For 1 pixel scrolls you
can rotate words in memory, using the carry bit to carry data over  from
one word  to  the next.  Anything  more and  you  either have  to  store
multiple copies (e.g. 4 screens, each offset by 4 pixels like I use)  or
use a FETCH-SHIFT-STORE method, which is very slow.

    Typically the scroll will be optimised  for one speed, so you  can't
jump around the map or change scroll speed easily. Also changes made  to
the map must either be  made on the backup screen  at the same time,  or
they won't appear until that part of the map scrolls off the screen  and
back on again.

    But what if you could generate  the screen every time from the  map,
with pixel-perfect positioning? What if  you could display the map  from
any position? Well, that's what I'm trying to do. (The Sega and Nintendo
8-bit and 16-bit consoles have this built into the hardware. That's  why
you get so many blocky 2D platform games for them).

    I achieve this by keeping the number of scenery blocks low - only  3
here (0=blank, 1=wall, 2=coin). This gives me 9 possible adjacent  pairs
of  blocks  (0=blank/blank,  1=blank/wall,  2=blank/coin,  3=wall/blank,
4=wall/wall, 5=wall/coin, 6=coin/blank,  7=coin/wall, 8=coin/coin),  and
it is these pairs which are the key to the whole thing.

    Although the blocks  are 16  pixels wide,  as they  scroll left  and
right they do not always line up with the word boundaries of the  screen
display. As one  block scrolls out  of its 16-pixel  wide column to  the
left, so  it  will be  replaced  by the  block  to its  immediate  right
scrolling into place. Now, if I store  what this looks like for all  the
above combinations (9 pairs, 16 pixel-scrolled frames, each 16*16 pixels
in size) you can begin to see how it works.

    The map is converted from one which stores the 0,1,2 for blank,wall,
coin to one which stores the pair code 0-9, describing both the block at
that point on the map and the  one to its immediate right. You can  then
build the  display in  word-boundary-positioned blocks  using the  first
image for  each pair.  To make  the  whole thing  scroll left,  you  use
subsequent images from each sequence, so all the pieces move off to  the
left of their blocks, and are filled in with the correct image from  the
right hand side.

    Once you reach  the end of  the sequence, you  move the whole  thing
along a block (16 pixels) and start again. To go right, you reverse  the
sequence. To go  up and down,  you use offsets  to copy the  data a  bit
higher or lower.

    Now, this runs a bit slow in STOS, even when compiled, but it's  not
bad when you consider that you  have a go-anywhere, at any speed  scroll
routine. The machine code version should be very quick.

    I've also added a bit of  parallax scrolling with a background  grid
in a 4*4 pattern. It  moves horizontally at 1/4  of the scroll speed  by
moving it across behind the blocks  as the 16 frames are generated,  and
it moves vertically  using colour cycling  to negate the  effect of  the
vertical scroll,  but  letting  through  1/4 of  the  movement  for  the
parallax effect.

    Try my demo, and  use the joystick and  mouse to see the  scrolling.
The joystick does 4-pixel scrolling, the mouse any speed you like.

    And yes, there is a game on the way.

    ------------------------------------------------------------------- 

