
     ICTARI USER GROUP             ISSUE 37                    August 1996

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

                     *   m   a   g   a   z   i   n   e   *

     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                       I C T A R I   U S E R   G R O U P
      63 Woolsbridge Road, Ringwood, Hants, BH24 2LX   Tel. 01425-474415
     =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              INDEX FOR ISSUE 37
                              ==================

     ASSEMBLY        ST Assembly Language Workshop. Chapter 2.
                     Raster and mouse control routines.

     C               Richard Harvey. C Tutorial Part 1.
                     Garden Database program.

     GFA             Various font routines.

     STOS            Alert box routine for STOS.
                     Fill demo and source code.

     MISC            Mouse icon images.
                     Current membership list.

     In next months issue of ICTARI (this may change) :-

     ASSEMBLY        ST Assembly Language Workshop. Chapter 3.

     C               Richard Harvey. C Tutorial Part 2.

     GFA             Various font routines.

     STOS

     MISC            NVDI Guide Information.
                     Icon images.

     ----------------------------------------------------------------------
                                   EDITORIAL
                                   =========
     DELAYS
     ------
     I should apologise if this disk is a little late but I have been on my
     hols and 'her indoors' wouldn't let me come back early to prepare this
     issue (some people are so inconsiderate).

     FEEDBACK
     --------
     As usual we would like to hear  some feedback on the programs and code
     provided on the disk as this will be very helpful to the contributors.
     ----------------------------------------------------------------------
                                 CORRESPONDENCE
                                 ==============
     To: *.*
     From: L. Maule-Cole.

     Please would some kind person Beta  test  my  Garden program (in the C
     folder).  This is my first attempt at  writing an application and as I
     am entirely self taught (with the  help  of  a few books) I would very
     much appreciate some helpful comments.  One of the problems I couldn't
     solve for myself was - how do you move the mouse pointer on the screen
     without moving the  mouse?   Some  sample  code  in  C  would  be very
     helpful. The program in the GARDEN  folder  is my Demo version.  Apart
     from the annoying label  that  pops  up,  the  demo version limits the
     number of labels that can be  entered  to 100 otherwise every function
     should work.

     */ We did publish some code  (in  machine  code)  to do this some time
     ago, perhaps someone could send in a version in C.  ICTARI  /*
     ----------------------------------------------------------------------
     To: Scott Stringer
     From: Jason J Railton
     Re: CACE demo

     The STOS demo looked fine on my 2.5Meg STFM, but it sounded awful. All
     I got was a horrid buzzing sound.  Clearly a demo specifically for STE
     owners (or the hard of hearing).  Sorry.  I'm sure it sounds lovely on
     DMA playback...

     To:    Everyone
     From:  Jason J Railton
     Re:    Maze demo

     Thanks to everyone who tried my 3D  maze demo.  It's inspiring to know
     that it's appreciated by other  people.   Now,  what should I do about
     the controls?  I'd rather not use  a  joystick because I would have to
     program in a fixed rotation/movement  speed.   This  is then either in
     small units, which makes movement  slow,  or  large units, which makes
     movement difficult to control accurately.  I  intend to stick with the
     mouse.

     I appreciate that the right button  would  be  better used as a  'walk
     forwards' button, so I'll probably  move  the  sidestep control to the
     keyboard.  Personally, I like having  the  sidestep  on the mouse, but
     with a fire  button  as  well  (later...),  I'm  running  out of mouse
     buttons.  So what do you want the mouse buttons/keyboard to do?

     With doors working now,  I  also  need  an  'operate'  button.  At the
     moment, this is achieved by clicking  the right (sidestep) button.  If
     the 'walk' or 'fire' button doubled as  this purpose, it could lead to
     mistakes when playing -  operating  things  when  the  intention is to
     shoot or run away. So, I  either  put  the 'walk' or 'fire' control on
     the keyboard (Alt and Shift keys are  the  easiest to read), or I have
     two keyboard keys for  'sidestep'  and  'operate/open'.  Then again, I
     could even have sidestep left/right on  the  two mouse buttons and all
     the other controls on the keyboard.

     How about if you just  move  the  mouse  forward, and you keep walking
     until you pull the mouse back  again?   (To walk backwards though, you
     have to keep moving the mouse as  before,  so you don't have to centre
     the mouse exactly to stop walking forward, just pull it back until you
     start to back up)?

     To: Everyone
     From: Jason J Railton
     Re: More demos

     The stuff I sent in last  month  didn't  arrive  in time to make it to
     disk 36, so  it  may  be  floating  around  on  this  disk  with a few
     messages.  Either that or Peter just thought  it was a load of rubbish
     and binned it... Who knows? Anyway,  I've  sent in my two-player TANKS
     game, but it is about 200K so I  don't  know if that will appear for a
     while.

     I've included a new mouse/raster routine for Peter, who wanted rasters
     on specific lines of the screen.   I  suggest  you print out the whole
     source listing and go through it with  a red biro, making notes on how
     it all fits together.  There  are  loads  of  comments  in the code to
     help.  The interesting twist on the  last two mouse/raster listings is
     that I actually have four different raster interrupt routines now, and
     each one installs the next one  on  the  fly.  The spacing varies too,
     but you have to control that one interrupt in advance.

     Note that the raster routines can  do this because the system hardware
     causes all interrupt routines to run in Supervisor Mode.

     Also I've sent in a demo of  how  I  fill  all those polygons in my 3D
     maze.  Basically, I just draw the  top  edge  of each polygon and then
     smudge the screen down, overlaying each line on the line below.  Close
     objects (lines high up the screen) then obscure distant objects (lines
     further  down  the  screen),   so   all   the  depth-sorting  is  done
     automatically.  The top and  bottom  halves  of  the  screen are exact
     mirror images, so one is simply a copy of the other.  (NOTE: I did not
     hack into SubStation for  this!   I  figured  it  out myself, although
     those streaky walls were a  bit  of  a  clue.)  I've included a simple
     demo of this principle, and also the  source code of this demo in STOS
     basic.

     I'll go into the 3D maths  in  detail  at  a later stage, but for now,
     look at the graphical technique.

     Of course, I use machine code for mine  (not STOS), but the code is so
     specialised that it's unreadable.   In  addition  to  the STOS demo, I
     draw my lines ANDed with one of several coloured stippled patterns, so
     the line darkens as it  goes  down  the  screen.  This makes the whole
     wall (when the line is smeared  downwards  to  make a solid wall) look
     shaded.  I also smudge the lines  of  the  screen in twos, to preserve
     the stipple instead of making it streaky.

     I still haven't seen this SubStation  running  by the way, only static
     screen shots.  Anyway, bye for now.   I'm  off  on me hols.  I've just
     been to the fair, and  I'm  tired,  but  I'm  still trying to get this
     finished. I got two plushies  (sorry  -  technical term there.  I mean
     'cuddly toys') from the fairground grab-cranes,  so I'm in a happy (if
     tired) frame of mind.  I can supply tips on getting results from these
     machines too, if anyone's interested.   It's a perfect chat-up though,
     if you go into a pub with  an  armful of cuddly toys...  just stick to
     the right part of town. Oh, what am I saying?  It must be bed time.  I
     hope Peter has the sense to edit all this waffle out...  We'll see.

     */ In the Maze Demo,  could  you  not  have  a  row of icons along the
     bottom of the screen for moving  in any direction with additional ones
     for fire, open door,  attack,  or  whatever  (i.e.  similar to Dungeon
     Master). This would make the  screen  area  slightly smaller but would
     give more scope for other controls.

     The files you sent are on this disk  although I don't seem to have the
     TANKS game and I can't quite remember whether it was on the last disk.
     Perhaps you could send me another  copy  if  you  think it would be of
     interest to other members.

     Thanks for the raster code, I will  study it in detail shortly and let
     you know how I get on in due course.   PDH /*
     ----------------------------------------------------------------------
     To: All
     From: Mrten Lindstrm

     NVDI
     ====
     Beginning of this year I wrote to 2B  and asked for NVDI info, but - I
     told you a few months ago - I got  no reply. Well, I just now HAVE got
     a letter from Wilfried Behne (apologies  to  him) together with a disk
     with the NVDI Programmer's Guide. By  unfortunate coincidence I got it
     only after it was published in Ictari  36, but since the version I got
     directly from Germany is newer - it covers NVDI 4.1 - I send it in.

     (As I suspected, character  mapping  mode  2  now  stands for Unicode;
     1=ASCII+Atari and 0=direct indexing as appearing in font file.)

     NOTE TO PEOPLE WHO HAVEN'T YET LOOKED AT THE GUIDE: It covers not only
     NVDI-specific functions and features, but  is  a  complete list of all
     VDI functions, including the old VDI and (Speedo)GDOS ones. And with a
     number of useful tips on how to tackle common problems.


     WDIALOG
     =======
     On the same disk I got  an  AUTO-folder program WDIALOG.PRG. Just like
     the VDI Enhancer provides some  of  NVDI's  VDI extensions to non-NVDI
     users, WDIALOG will make available  MagiC  AES extensions to non-MagiC
     users. The terms are identical,  i.e.  WDIALOG  is in principle freely
     distributable as long as no  profit  is  made from it. (If distributed
     with commercial programs of value more  than  50 DM  22, the written
     consent of 2B is required.)

     Unfortunately I have not yet had the time to look any further into it,
     but the functions of WDIALOG seem aimed to simplify the implementation
     of window dialogs (= non-modal dialogs)  as  well as of list boxes and
     non-standard fonts, and apparently other  non-standard objects too, in
     dialogs. WDIALOG does NOT give  3D  appearance  on older TOS versions,
     but DOES use 3D effects on those AES versions that support them.

     There are sample executables (with C source code) to give a quick idea
     of what extras WDIALOG  can  help  you  with  (you  only  need to copy
     WDIALOG.PRG into  your  AUTO-folder  first).  Plus  there  are  screen
     snapshots (in IMG and 16-colour XIMG format) both on an old TOS (1.04)
     and with a modern AES (MagiC 4) - to give an even quicker idea.

     The documentation is (unlike the  NVDI  Guide) in untranslated German.
     If I get the time, I might  translate it into English later (if no-one
     else volunteers to do it).

     I send both the NVDI Guide and WDIALOG in the form I got them - as two
     LHZ packed files. Since  they  contain  quite  a significant number of
     files - including example source files and, not least, space-demanding
     images - I suspect that Our  Editor  will have to keep them compressed
     (or maybe just  extract  the  main  text  documents  + the WDIALOG.PRG
     file?).

     German news and views
     =====================
     I just bought a copy of the  German "ST Computer". It's a double issue
     - July/August 96 - and yet less than half (62 pages) of what it was in
     the good old days (I did for  a  period subscribe to it). On the other
     hand, though it for a while was  trying to extend itself to both Atari
     and Mac users, it has now at least reverted back into being a pure and
     unpolluted  Atari  magazine.  And   the   pages  there  are,  provided
     interesting reading - among other things:-

     New AESs
     --------
     Julian Reschke is still writing his  Atarium, this time concerned with
     new AESs. There currently seems to  be  two projects in progress, both
     with the aim  of  creating  a  freeware  multitasking  GEM system: one
     Britain-based "XaAES" and one  Swedish  "oAESis". Anyone with Internet
     access who wants to participate  in  this  (or is just curious) should
     visit the following addresses (according to Reschke):

       For XaAES:    http://www.i-way.co.uk/~c_graham/home.html
       For oAESis:   http://www.mdstud.chalmers.se/~d2cg/oaesis/

     Beta versions and source files should be available.

     But then there is of course the brand new and ready COMMERCIAL system,
     N.AES, from the German company  Overscan.  Apparently, N.AES beats the
     old MultiTOS in both speed and stability, and adds a few tricks in its
     functionality too.

     Needless to say, all of these  new  AESs  are  based on MiNT (the "new
     GEMDOS") and compatible with MultiTOS.
     MagiC, on the other hand, does from what I understand lag behind a bit
     in its MiNT support, and though  Geneva, in its latest version, should
     work with MiNT, Julian Reschke hasn't seen it - has any Ictari member?

     HADES
     -----
     There is also an extensive review of the new super TOS computer Hades,
     in  its  maximum  configuration  with  a  60MHz  68060,  and  a  crude
     experiment (running some matrix calculations)  seemed to indicate that
     it is about 3 times faster  than  a  90MHz Pentium PC. Then again, you
     will have to pay about 1900 or so for it, which could buy you quite a
     powerful PC. (Equipped  with  a  "humble"  64MHz  68040,  the price is
     "merely" 3675 DM or slightly less than 1600.)
     Like a PC, Hades  has  slots  for  both  ISA  and  PCI cards and comes
     equipped with a PCI graphics card. Its  OS is a TT TOS (3.06) modified
     to cope with the Hades hardware, and its memory can be expanded beyond
     any practical limits (the test machine had 40 Mb RAM).
     Most programs tried by the Germans  seemed  to run OK, though they had
     some problems with a few  older  programs,  some  of which using self-
     modifying code. MiNT (and  N.AES),  however,  is  apparently not liked
     well by Hades - though  work  is  in  progress  to rectify this. Since
     MagiC won't work  either,  the  only  current  multitasking  option is
     Geneva.

     GNU C++
     -------
     Recently GNU C++ was apparently upgraded to  v 2.72. Don't ask me what
     this means practically, but it shows  that someone is at least keeping
     the Atari version up-to-date (v2.72  is  the  most recent Unix version
     too, that I have seen).
     I could see a CD with  this  GNU  C++  advertised, though I presume it
     must be possible to get  via  some  Internet address too (does someone
     know?) or through a conventional PD floppy disk library.


     To: Stephen Bruce
     From: Mrten Lindstrm

     Supervisor mode
     ===============

     ==> Q: When do you need it?

     ==> A: Whenever  you  access  absolute  addresses  below  $800 (system
     variables)  or  in  the  intervals  $FF8000-$FFFFFF  -  or  $FFFF8000-
     $FFFFFFFF - (the hardware  addresses).  Otherwise  you  will get a Bus
     Error exception (two bombs).

     You also need it in order to execute a few "privileged" instructions:-
     RESET and  (allowing  access  of  the  User  Stack  Pointer  even from
     Supervisor mode) MOVE USP,An and  MOVE  An,USP  - but most importantly
     any  instruction  (including  RTE)  that   accesses  the  full  Status
     register.
     The LOW byte of the Status  register  - containing the condition flags
     and the X-bit - can be accessed  from USER mode using an operand "CCR"
     (for Condition Code Register). It  can also, usually more effectively,
     be accessed implicitly by  any  instruction  that  affects these flags
     (e.g. MOVEQ #1,D0 will clear all flags except the X-bit).

     The FULL 16-bit Status register can  be  accessed with an operand "SR"
     (it will also be  loaded  from  the  stack  by  an  RTE - "ReTurn from
     Exception" - instruction) but ONLY FROM SUPERVISOR MODE.
     The most probable reason you would want  to  do  it  - if ever - is to
     turn off the interrupts, which you can do with the instruction:
        ori  #$700,SR    (or move #$2700,SR)
     Or possibly (for advanced colour  trickery  on  the screen) to turn ON
     the HORIZONTAL BLANK, which normally is off. Do that with:
        move #$2100,SR
     If you try to do anything of  the  above  in  user mode you will get a
     "Privilege Violation" exception (four  bombs).  Restore the interrupts
     with:
        move #$2300,SR
     Or save SR before you change it and then restore it.


     ==> Q: Could it cause problems to run "user-mode code" in supervisor
       mode?

     ==> A: Anything that can be done in user mode should, in principle, be
     possible to do in supervisor  mode  too.  One  exception is AES calls,
     which require special precautions if they  are  to be made from super-
     visor mode, but that is just because of  the weird habit of the AES to
     write on  both  stacks  (other  system  functions  write  only  on the
     current, = supervisor, stack).


     ==> Q: How big is the speed increase if system calls can be skipped?

     ==> A: From the TOS listing  in  Atari  ST  Internals I could count an
     overhead for  BIOS/XBIOS  calls  of  roughly  60+  microseconds  (ON A
     STANDARD ST), and similar figures  can  probably  be assumed for other
     system calls. This means that  direct  hardware accesses are often, or
     even USUALLY, many times faster than  system calls. On the other hand,
     even if we count 100 s per  call,  we  can  make 10 system calls in a
     millisecond and 1000 calls in just a tenth  of a second. So if we make
     a finite number of system  calls,  I  think  it  safe  to say that the
     overhead is indeed negligible. Then again, if system calls are made in
     a loop, that is run hundreds or thousands of times per second, then we
     are in a different situation obviously.

     The periodical interrupts are a special  case. The VBL runs between 50
     and 71 times per second, and  the system interrupt 50 times/second, so
     speed optimization could mean  something  here.  More importantly, all
     interrupt routines (and other exception routines) ALWAYS run in super-
     visor mode anyway (even  in  an  otherwise "user-mode program"), which
     make it natural to make  direct  hardware  accesses from these. (Clean
     GEM programs should in  any  case  avoid  installing any interrupts of
     their own, preferably leaving this to AUTO-folder programs.)
     If a HBL routine is used,  it  must,  needless to say, not contain any
     system call, since it is called more than 10000 times/second.

     */ I seem to remember reading somewhere (although I can't put my hands
     on it at the moment) that  application programs should normally be run
     in User mode (except where  the  program  needs  to access a protected
     memory address) because the  Supervisor  stack  memory is fairly small
     which severely limits the  application  program's  stack memory. It is
     possible to change the Supervisor stack address within the program but
     the programmer must remember to restore  it before leaving the program
     or the system will crash on  exit.  I  can't see any real advantage in
     using Supervisor mode for a whole  program since it is relatively easy
     to switch to Supervisor mode and then back to User mode when required.
     If anyone has any more thoughts, please let us know.  ICTARI /*
     ----------------------------------------------------------------------
     To: C programmers & Mrten Lindstrm
     From: Jim Taylor

     LOW-LEVEL VDI CALLS   (Ref: The VDI Enhancer - Ictari 34)
     -------------------
     My thanks to Mrten Lindstrm for  the corrections to my conversion of
     his  GFA  enhancer  code  to  C++.   I  am,  however,  left  with  one
     outstanding problem.

      ie. how to implement the vdi() call.

     You say, Mrten, that  the  simple  vdi()  function  (or similar) will
     hopefully be defined somewhere in your C  libraries. If not, it can be
     defined based on the following small assembly routine:

     _vdi:  move.l  #_VDIpb,D1
            moveq   #115,D0
            trap    #2
            rts

     Well, so far I cannot find anything similar in the HiSoft Lattice C++
     libraries and have not been able  to  figure out how define it myself.
     There is some information in the manual which is supposed to show you
     how to implement assembler code  from  C  but  so  far I have found it
     incomprehensible.  It would be handy  if  there was a suitable routine
     in HiSoft's Lattice C, but it would also be very useful to know how to
     call assembler from C.

     I have had several attempts based on  the  example in the manual but I
     cannot make them work.  There  is  obviously  something I am missing -
     for example  do  you  have  to  write  the  assembly  routine  with an
     assembler such as MONST, compile it to object code first before it can
     be used from C ?  This  indicates  my fundamental lack of knowledge in
     this area of programming and once  again  I  look to fellow members of
     ICTARI to help me out.

     I have had a  look  through  the  ICTARI  index  for topics on calling
     assembler from C but could find nothing.
     ----------------------------------------------------------------------
     To: Ictari members
     From: John Oakes

     Bad news has come, in the way  of  the  only magazine on offer has now
     ended. ST Format issue 86 quotes -

     "This  is  the  final  issue,  we're  sadly  closing  down.  Don't  be
     disheartened though - there are loads  of  ways in which you can still
     keep up to date with what is happening  in the world of ST, Falcon and
     Jaguar, including disk magazines,  bulletin  boards,  the Internet and
     via various software companies".  Nick Peers.  Editor.

     I feel that having taken over Atari  User,  ST Review and ST World you
     are left with no competition to  work  against. Hence you stagnate and
     eventually suffer. Like most things in life, people like to see what's
     on offer. It may seem doom and gloom  but I do hope there is a Phoenix
     from the flame soon.

     */ See letter from Martin Milner below for your Phoenix.  ICTARI /*
     ----------------------------------------------------------------------
     To: All
     From: Stephen Bruce

     Re:     ST Format demise

     I've just bought ST Format issue 86  only to discover that this is the
     last issue. This concerns me for two reasons.

     1) The selfish reason:
             Without ST Format I have no news of Atari or its
             products. I know much information can be gleaned on
             the 'net but I don't have a modem & I'm not sure I
             want one. We do have an Internet cafe in Aberdeen
             which I could use but there is so much info out there
             I don't know where to look.

     2) The business reason:
             Without ST Format there is nowhere to advertise
             products, leading to lost sales & possibly resulting
             in many companies dropping Atari support. No reviews
             of new products leads to a similar situation.

     What I want to know  is  if  there  are  any other publications on the
     market either in the U.K. or  overseas (preferably printed in English)
     which carry out a similar role  to  ST Format. Diskzines would be okay
     as long as the content was well supported by the users (as in Ictari).
     One  possible  solution  would  be  to  expand  Ictari  to  include  a
     news/reviews section for the  more  important  information & releases.
     Apologies to Peter  Hibbs  if  this  increases  your  workload unduly.
     Perhaps we could  establish  a  system  of  shared information between
     Ictari & other disk magazines, forming a network of contacts providing
     info that is published on all of the diskzines.

     Any comments from other users? I've had to keep this short as I'm late
     in posting this disk & hope for feedback next issue. Maybe I will just
     have to save for a modem & the ensuing bills, but I hope not.

     */ Sorry, I would not have enough  time  to expand ICTARI but see next
     letter anyway.  PDH /*
     ----------------------------------------------------------------------
     To: *.*
     From: Martin Milner.

     Thought you might like to  know,  (if  you  didn't already) that a new
     Atari magazine will be being  launched  in  the next couple of months.
     Below are some brief details:-

     Mike Kerslake, a  magazine  publisher  with  4?  years  experience has
     signed up Frank Charlton, ex  features  editor  for  ST Format and Joe
     Connor, ex Reader Disk/Public Arena  editor  for  Atari World as joint
     editors for a NEW printed Atari magazine called Atari Computing.

     Atari Computing Issue 1 will feature 60 pages of A4 monochrome crammed
     with quality editorial wrapped in  a  glossy cover. We're delighted to
     welcome  contributions  from  respected  and  well  known  journalists
     including Graeme Rutt, Jon Ellis, Denesh Bhabuta and Kev Beardsworth.

     Atari Computing Issue 1 will be  launched  at the forthcoming shows on
     Saturday September 28th in  Birmingham  and  Sunday  September 29th in
     London,  for  more   details   about   the   shows   contact:  Goodman
     International, Telephone 01782 335650.

     The shows are still going ahead,  despite  the demise of ST Format. If
     anyone would like more info  or  better  still  would like to indicate
     their wish to subscribe when  the  mag  comes  out, (the price will be
     about 3 pounds an issue, I believe), write to me at 1 Portland Avenue,
     Burton on Trent, Staffs. DE14 3GD. England or email me at:-

     manifold@cix.compulink.co.uk.

     and I'll either send you more detailed  info or pass your intention to
     subscribe on to the appropriate people.

     */ Perhaps you could keep  us  informed  about  future progress on the
     magazine. This project sounds very  interesting,  the problem, I would
     have thought, is that if  there  are  not  enough  readers to keep the
     glossy magazines going,  are  there  going  to  be  enough  for  a new
     magazine to survive for long. I  believe that ST Applications is still
     publishing but even they seem to be struggling with different formats.
     Time will tell I suppose.  ICTARI /*
     ----------------------------------------------------------------------
     To: ICTARI
     From: Peter Brewster
           Alien Technologies
           36 Markenfield Road, Jennyfields, Harrogate, HG3 2TR

     Following the recent demise  of  ST  Format  and  the  general lack of
     corporate interest in the Atari computers, I felt it is long past time
     that some attempt is made  to  keep  a  good old workhorse (no offence
     intended!) out of the knackers yard.

     Please allow me to introduce  myself.  I  am  currently an employee of
     Marpet Developments, you will  almost  certainly  have come across our
     Xtra-RAM Deluxe at some  point  and  no  doubt  probably torn out some
     amount of hair installing your first ever 'deluxe'. I have worked with
     Ataris for some time, being a  home  computer user going right back to
     those heady 8 bit days of programs  on audio tapes and wonky black and
     white pictures on a spare TV set.  My  hope  is to be able to continue
     some of the service provided  by  Marpet  for  the Atari community and
     extend this further by being  foolish  enough  to develop new products
     for ST's, STE's and Falcons. It  is  also  my intention to continue to
     supply the Xtra-RAM Deluxe and the FMCII.

     To get the ball rolling  I  will,  with immediate effect, be supplying
     Deluxe kits at a special price, working  from home with no overheads I
     am aiming to supply (genuine) Marpet kits for about 10-15 (details to
     be finalised and somewhat dependent  on  response to this mailshot). I
     will also be offering replacement  floppy  drives and taking in repair
     work.

     Possibly the deciding factor in  this  is  you  and  the user group to
     which you belong. Suggestions are encouraged, what can I do for you ?

     I hope that you take this with  same dogged stubbornness that has kept
     the Atari going! We're on our  own  now!  I look forward to your reply
     and am available most nights on 01423 500861, please get in touch.

     ------------------------------ End of file ---------------------------
