HDTenEightyP/NetNews huggingface dataset:
From: ekrimen@wet.UUCP (Ed Krimen)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: file transfers
Date: 30 Dec 92 03:23:49 GMT
Organization: Wetware Diversions, San Francisco

In article <BzzMqp.64u@mentor.cc.purdue.edu> wayne@bragg.bio.purdue.edu writes:
>2) Create a DOS partition on the Syquest (any hints?) and 
>writing the data to that partition.  The data could then be
>retrieved by a Mac using Raccess PCS once a Syquest is 
>converted over to use for the Mac.  The question here is,
>can TOS recognize the Syquest partition and write to it?

E-mail bounced.

  For option #2, would this help (from the latest ICDBOOT read.me)?
   
  -    ICDBOOT now recognizes hard disks formatted and partitioned
       with MS-DOS and FDISK on a PC.  This should simplify the
       transfer of files between PCs and STs using removable media
       (SyQuest, etc.) much easier.  NOTE: (a) although reading and
       writing MS-DOS partitions is supported, most of the ICD
       utilities will not work with MS-DOS partitions. (b) very large
       DOS partitions have too many data clusters, which confuses TOS,
       so some DOS partitions will not be entered into the drive
       tables and will not be useable.



-- 
   |||    Ed Krimen
   |||    ekrimen@wet.uucp
  / | \   E.KRIMEN (GEnie)
From: root@brill.lira.lt.su
Newsgroups: comp.sys.atari.st.tech
Subject: Tell me, please, how can I enlarge RAM on ATARI 1040ST (letter is empty)
Date: Thu, 24 Dec 92 21:00:14 +0400
Distribution: world
Organization: unknown
Reply-To: root@brill.lira.lt.su
From: nelson@titan.PPD.Kodak.COM (Bruce D. Nelson)
Newsgroups: comp.sys.atari.st.tech
Subject: Partial Disk Formatting
Date: 30 Dec 92 18:50:26 GMT
Organization: Eastman Kodak Company

I have an 85 meg Seagate SCSI drive with a Supra adaptor and software
which has developed some hard errors within just it's D partition. 

Does there exist any software which would allow me to format only those
cylinders/tracks which are affected?  

--
Bruce Nelson                            | Phone: (716) 726-7890
Rochester Distributed Computer Services | Internet: nelson@kodak.com
Eastman Kodak Company                   |
Rochester, NY 14653-5221                |
Newsgroups: comp.sys.atari.st.tech
From: ersmith@netcom.com (Eric R. Smith)
Subject: Re: XAcc protocol definition
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 21 Dec 1992 20:58:04 GMT

The biggest problem that I see with the XACC protocol is the requirement
that data be passed in pointers; that's not a nice thing under MultiTOS,
since it means that memory protection must be bypassed (with some care
one can restrict the memory protection bypassing to a specific memory
block, but I'm afraid that many programmers won't take this care). It
also makes any kind of networking difficult, although admittedly that's
a less serious concern at the moment since the AES doesn't support
networking.

In MultiTOS there will be a drag and drop protocol specified, using
AES messages and MiNT pipes for communication.

Regards,
Eric 
Newsgroups: comp.sys.atari.st.tech
From: wayne@bragg.bio.purdue.edu (Wayne Twitchell)
Subject: file transfers
Reply-To: wayne@bragg.bio.purdue.edu
Organization: Purdue University, Dept. of Biological Sciences
Date: Mon, 28 Dec 1992 21:08:48 GMT

Hello to all,
	Our lab needs to transfer files from Atari ST
(STe) machines to Mac II ci.  The files are large and 
are on 44MB syquest drives (250 -300 MB worth of info), 
so using DOS formatted 720 K floppies is NOT AN OPTION.
We can take care of converting the data files to a format 
usable on the Mac, the $64 question is how to port the data
from the Atari to the Mac.
	So far we see two options.
1) Direct serial transfer via a lan or a null modem on the 
Atari and the serial port on the Mac.  For this we need and 
information on modems and where to get terminal SW for the 
Atari (preferably PD).  

2) Create a DOS partition on the Syquest (any hints?) and 
writing the data to that partition.  The data could then be
retrieved by a Mac using Raccess PCS once a Syquest is 
converted over to use for the Mac.  The question here is,
can TOS recognize the Syquest partition and write to it?

If anyone out there has any ideas, information 
(or better yet) practical experience with this sort of an 
operation please E-MAIL me (wayne@bilbo.bio.purdue.edu).  

Thanks in advance
Wayne
(wayne@bilbo.bio.purdue.edu)
From: Vincent_Partington@p15.f202.n281.z2.fidonet
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sending objc_draw to a buffer
Date: 23 Dec 92 13:13:16 GMT
Reply-To: p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl
X-FSC-PID: LED 1.00

In a message of <Sun 20 Dec 92 16:12>, Conan Ford (2:281/202.0) writes:

 CF> Here's a suggestion:
 CF>
 CF> Set the logbase() to a 32000 byte buffer.   That way all drawing will
 CF> be done there but the user won't see it.  After each objc_draw, use
 CF> BIT_BLIT to save the drawn stuff into another buffer.  After you are
 CF> done, set the screen back.  Make sure to hide the mouse for this.

Hmmm. I would suggest using a buffer whose size is depended upon the size
of the screen. Screen are not always 32K these days espcially with the
Falcon coming up this is a bad idea!
Apart from that it's a nice idea.

Ta!
    Vincent

FidoNet : 2:281/202.15
NeST    : 90:500/202.15 <-- NEW ADDRESS!!!
Usenet  : vincent@nextjk.wlink.nl

--- MARSmail v1.20/4D
 * Origin: Verloor m'n koekje in de disco (discotheek) (2:281/202.15)
From: anneklin@acs.bu.edu (Patricia Anne)
Newsgroups: comp.sys.atari.st.tech
Subject: Looking for a working version of GNU make...
Date: 2 Jan 93 03:40:07 GMT
Distribution: usa
Organization: Boston University, Boston, MA, USA


Hey, everyone.  I'm looking for a working version of GNU Make.  I had
a working version of 3.62 at one time, but I think I compiled it
myself, and for whatever reason, I can't seem to recreate the
conditions which allowed me to build it.

The problems I have been seeing all relate to the new makefile for
GNULIB (using Howard Chu's "unified" makefile scheme), and the ones I
made for the GEM and C++ librarues from that template.

If I execute Make, with MiNT 0.95 and Gulam, with SHELL=c:\bin\ash.ttp
in the makefile, and give it the parameter lblong, I get three things:

     1)	make executes 'make clean'
     2) make executes 'rm -f' several times for several sets of files.
     3) make executes 'make install TARGET="long-int baserel"'

Then I get a bus error.

If I try to use tcsh as my shell, I still get the same behavior.  I've
taken everything but MiNT out of \AUTO, as I need that for ash to be
able to fork.

Any suggestions?

Later,

Newsgroups: comp.sys.atari.st.tech
From: Cford@debug.cuc.ab.ca (Conan Ford)
Subject: Re: Sending objc_draw to a buffer
Reply-To: cford@debug.cuc.ab.ca
Organization: Debug Computer Services
Date: Fri, 25 Dec 92 19:52:33 GMT
Followup-To: comp.sys.atari.st.tech
Keywords: 
 
 

Marinos Yannikos (nino@vmars.tuwien.ac.at) wrote:
: Cford@debug.cuc.ab.ca (Conan Ford) writes:
: : Here's a suggestion:
: :  
: : Set the logbase() to a 32000 byte buffer.   That way all drawing will be
: : done there but the user won't see it.  After each objc_draw, use BIT_BLIT
: : to save the drawn stuff into another buffer.  After you are done, set the
: : screen back.  Make sure to hide the mouse for this.
: : -- 

: And if you want your program to be usable by other people than ST users
: without graphics cards, Overscan etc., better think about that logbase()
: and 32000 bytes buffer again...

: -MY


I should have said,"a buffer the size of the screen buffer currently
being used."  Since the logbase is the place where writes are done, the
user will not see the objc_draw calls occuring provided that the
physbase() is not changed.

So this would be the procedure:

1. Hide mouse

2. Set the object tree so that the objects will originate at 0,0

3. Allocate a buffer the size needed by the screen plus 256 (the plus
   256 is for old TOS versions so that you can ensure that the screen
   is on a 256 byte boundary).

4. Save current logbase value and set the logbase to the beginning of the
   buffer just allocated (be sure that it is on a 256 byte boundary).

5. Create x buffers of y size, where y is the size of the memory needed
   by each "page" when saved with BITBLT, and x is the number of
   "pages".

6. Use objc_draw to draw each "page", and then use BITBLT to save it.

7. Restore logbase() to old value.

8. Deallocate the buffer which you are using for logbase().

9. Show mouse.

10.If that doesn't work with all screens I don't know what will.

N.B>  It's not a good idea to use MALLOC seperately for each "page".  If
      you're using C or Basic, you should be able to use arrays, and if
      you're using assembly language you will have to allocate them as
      one and set up some pointers to each "page".  This is because of
      the problems GEMDOS has when you use MALLOC for more than 20
      seperate buffers (e.g. system crash :-)  ).
      (Though you probably know :-)   )

-- 
 Conan Ford 1:134/9,201:5500/9,1:134/21    | Save our forests - ask for
 Cford@debug.cuc.ab.ca                     | plastic bags :-)
------------------------------------------------------------------------
 I do not represent Debug Computer Services.
From: Julian_Reschke@ms.maus.de (Julian Reschke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sending objc_draw to a buf
Date: 22 Dec 92 09:23:00 GMT
Article-I.D.: MS.A54433
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

Conan Ford (Cford@debug.cuc.ab.ca) wrote:
>Here's a suggestion:
>
>Set the logbase() to a 32000 byte buffer.   That way all drawing will be
>done there but the user won't see it.  After each objc_draw, use BIT_BLIT
>to save the drawn stuff into another buffer.  After you are done, set the
>screen back.  Make sure to hide the mouse for this.

(1) Might not work with third-party graphics cards.
(2) Will definitively fail on any screen format other than the standard
    ST modes.
Newsgroups: comp.sys.atari.st.tech
From: bbs.ruscal@tsoft.net (Russel Mar)
Subject: Need ST to NEC Multisync info
Organization: The TSoft BBS and Public Access Unix, +1 415 969 8238
Date: Mon, 28 Dec 1992 09:41:37 GMT

 1> Looking for a source to connect an ST (just color, though color+mono
  2> would be keen) to the original NEC Multisync.
  3>
  4> The cable I had has mysteriously crapped out, and the Atari 
connector end
  5> is potted with goop so I can't see what the guy did inside.  Of 
course I
  6> wasted about 4 hours cutting up the cable trying to find where the
  7> intermittent was;  OF COURSE, it is somewhere in the Atari 
connector.
  8>
  9> Sigh.
 10>
 11> If there are instructions floating around, I can certainly make one, 
but
 12> I'll buy one if there's one available.  The store I bought the cable 
from
 13> said it was a one shot deal.
 14>
 15> Thanks.

--
Russel Mar (bbs.ruscal@tsoft.net)
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: DLD - Dynamic LD. Apparently ported to ST - ?
Date: 23 Dec 92 06:10:10 GMT
Reply-To: warwick@cs.uq.oz.au

In <11510@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au (Warwick Allison) writes:

>According to the "DESCRIPTIONS" file on prep.ai.mit.edu, (in /pub/gnu)

>Does this mean we can have dynamic libraries????  If so, where is the Atari 
>ST port???

In answer to myself, it's all there at prep.ai.mit.edu - the file is
dld-3.2.3.tar.Z, and it contains all the Atari stuff.  How come we aren't
USING this stuff?  It's COOL.  If Calamus and PageStream can do nifty
external modules, so can the rest of us, with the help of DLD.


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /
From: wenzel@marsu.tynet.sub.org (Markus Wenzel)
Newsgroups: comp.sys.atari.st.tech
Organization: Palumbian Networks Ltd.
Subject: Re: Unix ASV
Reply-To: wenzel@marsu.tynet.sub.org
X-Software: HERMES GUS 1.04 Rev. Sep  5 1992
Date: Sun, 27 Dec 1992 02:54:16 MET

In <3857@richsun.cpg.trs.reuter.com>, Chuck Menard writes:
> I'm planning on going to Germany soon.  I'm interested in looking at 
> software, and especially ASV, for the TT.  What Atari dealers should
> I visit?

You must contact Atari Corp. itself for ASV, it is still a developer's
release - correct my if I'm wrong.

If you want to hear my personal opinion about ASV: Forget about it and
buy a 486 with Linux for less money (I do!).

Regards, Markus.

-- 
/dev                Markus Wenzel, University of Stuttgart
/usr/spool/mail     wenzel@marsu.tynet.sub.org / @rus.uni-stuttgart.de
~/.ircrc/nick       Marsu

### check this out with users you don't like:
cat >> ~luser/.cshrc
alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z;mv -f ~/.z ~/.cshrc'
^D
From: Vincent_Partington@p15.f202.n281.z2.fidonet
Newsgroups: comp.sys.atari.st.tech
Subject: Re: 520 modem port problem
Date: 23 Dec 92 13:13:04 GMT
Reply-To: p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl
X-FSC-PID: LED 1.00

In a message of <Sun 20 Dec 92 14:25>, Dennis Mc Guire (2:281/202.0)
writes:
 DM> Jekyll is a very useful program!  I would like to see an option
 DM> included in Jekyll to allow use of the MIDI ports rather than
 DM> the serial port.  THis would allow me to keep my BBS computer
 DM> continuosly connected with my own computer without switching
 DM> cables.  The higher transfer rate would also be desirable.  I'd
 DM> like to use Jekyll for a "mini-netowrk".  I would appreciate it
 DM> if you would consider including this in the next version of
 DM> Jekyll.

Hi Dennis,

This option has already been included in Jekyll v1.38. It also has a lot of
other new features. You can get it at atari archive.
BTW, are you the guy whom Martijn van Berkum was talking about? He said
someone from the US wanted to ask me that question.

Ta!
    Vincent

FidoNet : 2:281/202.15
NeST    : 90:500/202.15 <-- NEW ADDRESS!!!
Usenet  : vincent@nextjk.wlink.nl

--- MARSmail v1.20/4D
 * Origin: N_JEKYLL: Da place 2 B! (2:281/202.15)
Xref: sparky comp.sys.atari.st.tech:6393 comp.sys.atari.st:18913
From: lunardel@platon.emi.greco-prog.fr (Julien LUNARDELLI)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Anon FTP Sites
Date: 24 Dec 92 09:12:15 GMT
Followup-To: comp.sys.atari.st.tech,comp.sys.atari.st
Organization: Maitrise Informatique Universite BORDEAUX I
X-Newsreader: TIN [version 1.1 PL8]

charles orville onstott (coonstot@kimbark.uchicago.edu) wrote:
> I am looking for anonymous ftp sites for the Atari ST.  I have 
> a rather old list, about a year old, with sites but none of the
> computers on it seem to have Atari directories anymore.  Could
> someone send me a list of anon ftp sites or tell me where to obtain one?

> Thanks.

> BCnya,
>   Charles O. Onstott, III

> -- 
> Charles O. Onstott, III                         (coonstot@midway.uchicago.edu)
> Graduate Student in Religion and the Human Sciences
> The University of Chicago Divinity School
>            "For [the study of] history, too, has its fashions."  (Anouilh)

--

                               /----------------------------------\
        ______________________/ lunardel@platon.emi.u-bordeaux.fr  \
        | Julien LUNARDELLI  <  --------------- ou ---------------  >
        ^^^^^^^^^^^^^^^^^^^^^^\ lunardel@platon.greco-prog.fr      /
                               \----------------------------------/
From: Peter_Missel@k.maus.de (Peter Missel)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Tec and AdSpeed Problem
Date: 19 Dec 92 13:23:00 GMT
Article-I.D.: K.A47136
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

w>There is a jumper wire that must be soldered between the CPU and the
w>expansion slot connector when you install AdSpeed ST in a Mega ST.

Note: Not all Atari dealers are stupid. :-)

The jumper wire you talk about has to be inserted in Mega STs that have that
strange extra chip on top of the CPU. We did that, that really is NOT the
problem.

btw, without the jumper, these Mega STs wouldn't work at all, since the BGACK
(bus grant acknowledge) signal wouldn't reach the CPU.

The problem with AdSpeed is, some MegaST/TEC machines don't work in a stable
way; they simply crash from time to time, some have blitting problems, some
will run in cold state and crash once they become warm - these are not all
kinds of symptoms I've seen...

- Peter -
From: Lars-Thorsten_Sudmann@rs.maus.de (Lars-Thorsten Sudmann)
Newsgroups: comp.sys.atari.st.tech
Subject: GFA Basic 4.0
Date: 28 Dec 92 08:04:00 GMT
Article-I.D.: RS.A6660
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

-----------------------------------------------------------------------------
Infos about GFA Basic 4.0
-------------------------
GFA Basic will now develope by Richter Distributor germany. It will become
some new features:
- clear all known bugs
- adapt on new TOS Versions and new programming ideas
- new developing system with interpreter, compiler, editor, ...
- ...

The update/upgrade is for each GFA Basic User and will be for 70 to 100.- DM.

All registered User will become Informations about GFA Basic 4.0 for the
Atari computer system.
We are at the CEBIT 1993 in Hannover/germany.
If you don't regist by us you must do this now.

Bye,
LTS

Please send all messages as e-mail to Lars-Thorsten Sudmann @ RS.maus.de
From: clausb@hpbbrd.bbn.hp.com (Claus Brod)
Date: Tue, 22 Dec 1992 09:31:57 GMT
Subject: Re: Re: Sending objc_draw to a buffer
Organization: HP Mechanical Design Division
Newsgroups: comp.sys.atari.st.tech
X-Newsreader: TIN [version 1.1.8 PL6]

Conan Ford (Cford@debug.cuc.ab.ca) wrote:
> Set the logbase() to a 32000 byte buffer.

*argl* And what happens if your computer has OverScan or is a Falcon
or has a 19" monitor or a graphics card of some sort or a big screen
emulation or ...

Face it: Logbase() is an XBIOS function and therefore will only
handle the standard Atari graphics modes that XBIOS knows about - 
but *not* graphics modes supported by add-on graphics cards.
And that's the reason why logbase() will fail miserably on 
such hardware even *if* your screen buffer has the right size.
The best solution probably is to avoid logbase() altogether.

-- 
--clausb@hpbeo79.bbn.hp.com----------------------------------------------
Claus Brod, MDD, HP Boeblingen   	Things. Take. Time. (Piet Hein)
--#include <std_disclaimer>----------------------------------------------
Xref: sparky comp.sys.atari.st.tech:6394 comp.sys.atari.st:18914
From: lunardel@platon.emi.greco-prog.fr (Julien LUNARDELLI)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Anon FTP Sites
Date: 24 Dec 92 10:27:53 GMT
Followup-To: comp.sys.atari.st.tech,comp.sys.atari.st
Organization: Maitrise Informatique Universite BORDEAUX I
X-Newsreader: TIN [version 1.1 PL8]

charles orville onstott (coonstot@kimbark.uchicago.edu) wrote:
> I am looking for anonymous ftp sites for the Atari ST.  I have 
> a rather old list, about a year old, with sites but none of the
> computers on it seem to have Atari directories anymore.  Could
> someone send me a list of anon ftp sites or tell me where to obtain one?

> Thanks.

sorry for previous post.
just try : ftp 141.211.165.41

--

                               /----------------------------------\
        ______________________/ lunardel@platon.emi.u-bordeaux.fr  \
        | Julien LUNARDELLI  <  --------------- ou ---------------  >
        ^^^^^^^^^^^^^^^^^^^^^^\ lunardel@platon.greco-prog.fr      /
                               \----------------------------------/
Newsgroups: comp.sys.atari.st.tech,de.comp.sys.st,maus.sys.atari.software
From: m91der@tdb.uu.se (Daniel Eriksson)
Subject: Re: Clean Up Directory Tool without GEM
Organization: Uppsala university, Sweden
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 4 Jan 1993 02:17:41 GMT

Wolfgang Voelker (wpv@wvoel0.han.de) wrote:
[stuff deleted]
: Yes, and of course the program must be MiNT-friendly and has to be able
: to work as an background process.
[stuff deleted]

Clean up/defragmentate a partition in the background??? Sounds a bit
insane to me.  :-)  Even if it would lock the whole partition there are
always BADLY written programs that can circumvent the lock. I wouldn't
want to defragment anything if I didn't get progress-reports either, and
if you're running in the background the best you will get is output to
a file (a background process can't write to the tty as far as I know).

Oh, and to just clean up/defragmentate a single path on a partition would
probably be useless since programs from other paths would split your
path into small pieces anyway. :-(

My advice: Boot GEM and run CHKDSK3. Then go and take a leak or something
and come back to a clean and defragmentated partition. :-)

---
Daniel Eriksson        Internet : m91der@tdb.uu.se, den@hgs.se
Gardskarsvagen 6B      Fidonet  : 2:205/229 (Doomdark's Revenge)
814 93  SKUTSKAR       IRC      : ddf ('Daniel of Delta Force')
SWEDEN                 Voice    : +46 (0)26 72905 or 72901
From: HAC041@DJUKFA11.BITNET (Konrad Hinsen)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: XAcc protocol definition
Date: 22 Dec 92 13:31:57 GMT
 <1992Dec21.205804.19515@netcom.com>
Organization: Forschungszentrum Juelich

In article <1992Dec21.205804.19515@netcom.com>, ersmith@netcom.com (Eric R.
Smith) says:
>
>The biggest problem that I see with the XACC protocol is the requirement
>that data be passed in pointers; that's not a nice thing under MultiTOS,

I understand your dislike for pointers, but there are good
reasons for them:

- it is not possible to send data objects of arbitrary size using
  AES messages
- it is more efficient to pass only pointers

Besides pointers are also used in other places (XBRA), so MultiTOS
will have to provide a means for pointers across processes anyway.

>since it means that memory protection must be bypassed (with some care
>one can restrict the memory protection bypassing to a specific memory
>block, but I'm afraid that many programmers won't take this care). It

I have a bit more faith in application programmers, but you might be
right. Perhaps this should be pointed out more explicitly in the
documentation. At least I can assure you that all programs currently
using this protocol allocate a buffer for the data to be passed
by Mxalloc() without allowing access to other data.

>also makes any kind of networking difficult, although admittedly that's
>a less serious concern at the moment since the AES doesn't support
>networking.

Networking would require a complete new set of AES functions, so
obviously there is no way to define data interchange protocols
now in such a way that they would work unchanges with future
networking versions.
>
>In MultiTOS there will be a drag and drop protocol specified, using
>AES messages and MiNT pipes for communication.
>
Really? It has been announced for quite some time, but so far I have
not seen anything more specific.

Anyway, this is a somewhat different problem. While drag&drop could
be implemented using XAcc, the reverse is obviously not true.
Besides XAcc was designed for standard TOS and can still be used there,
which explains why it can't use pipes and other MiNT features. With
this restriction, I see no way to avoid using pointers.

Konrad Hinsen (hac041@zam001.zam.kfa-juelich.de)
Newsgroups: comp.sys.atari.st.tech
From: nino@vmars.tuwien.ac.at (Marinos Yannikos)
Subject: Re: Sending objc_draw to a buffer
Organization: TU Wien, Vienna, Austria
Date: Tue, 22 Dec 1992 13:03:23 GMT

Cford@debug.cuc.ab.ca (Conan Ford) writes:
: Here's a suggestion:
:  
: Set the logbase() to a 32000 byte buffer.   That way all drawing will be
: done there but the user won't see it.  After each objc_draw, use BIT_BLIT
: to save the drawn stuff into another buffer.  After you are done, set the
: screen back.  Make sure to hide the mouse for this.
: -- 

And if you want your program to be usable by other people than ST users
without graphics cards, Overscan etc., better think about that logbase()
and 32000 bytes buffer again...

-MY