HDTenEightyP/NetNews huggingface dataset:
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Extended characters with printf()
Date: 8 Nov 92 14:27:30 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

marco@sys6626.bison.mb.ca (John Perry) writes:

>Does anyone know how to use the extended character set with printf()? For 
>example, how would I go about printing the "arrow" symbol?

As far as I know this is not possible. The control-chars (<32 ?) and the 'high'
ascii chars (>127 ?) are just 'non-printable characters'.
If I'm mistaken (which I surely hope :), let someone please correct me.

--
Hendrik Jan Veenstra    hjv@phil.ruu.nl  *  How can I save my dreams
Dept. of Philosophy                      *  in the nightmare, in the flood
University of Utrecht                    *  But I try.
The Netherlands                          *
Newsgroups: comp.sys.atari.st.tech
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st.tech
Organization: Atari Corp. Scand. AB (Norway)
Subject: Re: Falcon BUS..
	<721060362.188@minster.york.ac.uk>
	<1992Nov11.203921.11068@rmece49.upr.clu.edu>
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Thu, 12 Nov 1992 08:53:52 MET

In <1992Nov11.203921.11068@rmece49.upr.clu.edu>, Ricardo Hernandez writes:
[stuff deleted]

>  So the Falcon can't do any processing when a DMA is taking place?

The 68030 has a cache, so it might do some processing while DMA occures on the
bus!

>[more deleted]



-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------
Newsgroups: comp.sys.atari.st.tech
From: richard@star.ic.ac.uk (Richard Syratt )
Subject: Compiling mintlib with a bug ridden Sozobon2 (was: Re: Cross Compiling Sozobon 2.0)
Keywords: bugs
Organization: Imperial College, London University
Date: Fri, 6 Nov 1992 11:49:19 GMT
X-Posted-From: op.ph.ic.ac.uk
NNTP-Posting-Host: sol.ctr.columbia.edu

If you've ben following this then you'll know I was having problems with
the sozobon 2.0 link editor (ld).  I *think* it's finally sorted out...

ld was failing to pick up uninitialised variables from a library, definitely
a bug.  I believe this can be fixed by changing line 297 of syms.c (ld source).
It was something like:

	if (sp->flags == EXTREF || sp->flags == COMMDEF)

This is definitely wrong, since there are other bits of code whcih check
for COMMDEF which can never be reached as things stand.

change it to:

	if (sp->flags == EXTREF)

Although this might not be the answer, it works as far as I can tell,
(why was it there in the first place???)  but since I'm cross compiling, I
havn't actually checked to see if the executable actaully is. (executable).
Can't see why not though.

Still on the subject of bugs in sozobon2, nm needs a fix,
the easiest thing to do is change tools/nm.c in subroutine dosym
(about line 185):
		...
	int n;

	if (havex == -1)	<-- add these
		reuse = 0;	<-- two lines
	if (reuse)
		reuse = 0;
	else {
		...


Do I have to use snail mail (even when it does go by air) to contact sozobon?

Hope this is actually useful to someone... Scott?

Other things you need to do to get mintlib compiled are:

- Apply the relevant patches found with the current sozobon mint libraries.
	some of these are no longer necessary.
- Change patchlev.h so that it uses ' instead of " for the #define bits -
	(another problem with sozobon ...), and change the ~ in ident.c to
	' as well.
- In files such as fscanf.c there are typedefs that sozobon doesn't like,
	I think you can delete these and any references to the things they
	were defining ... parameter passing defaults to type int doesn't it?

I think that's it - there's probably a few warnings you might like
to fix (uncast mallocs etc).

I'll test it over the weekend, probably find I've got it all wrong :-(

Richard Syratt
From: mhughes@comtch.spk.wa.us (Mark Hughes)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: 680x0 vs. 80x86...
Date: 6 Nov 92 23:54:49 GMT
Organization: Waffle BBS at CompuTech Spokane, Washington

michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith) writes:
>  m> A 32MHz 68030 Mac is at roughly the same speed as a 33MHz 386dx.  I
>  m> know the TT is a bit slower at some things, maybe 25MHz 386dx
>  m> equivalent. I have no idea about the 68040 or the 486.
> 
> Hmm... I'm not too sure on that one - I use (& code for) a 386DX33 with a
> 387 at work, and my code seems (I say seems, I haven't timeed it) to run
> somewhat more snappily on my TT than the DX... and as a rule TOS seems to be
> a little quicker on drive/file operations.
> 
> However, there are a large number of other considerations here ... (screen
> I/O, genearl responsiveness, my bias, etc 8)

  Well, my estimate of TT speed is as compared to 32-bit Unix on a 386dx. 
Under DOS, you're looking at the TT being somewhat faster - not to 
mention more capable.  OS/2.0 would be faster, except for that silly PC 
video bus crippling it.
 
 - Mark Hughes (Caves of Steel 509-624-2078)  mhughes@comtch.spk.wa.us
From: jeff.molofee@outlan.ersys.edmonton.ab.ca (Jeff Molofee) 
Newsgroups: comp.sys.atari.st.tech
Subject: Falcon specs
Date: 5 Nov 92 09:01:00 GMT
Reply-To: jeff.molofee@outlan.ersys.edmonton.ab.ca (Jeff Molofee) 
Distribution: world
Organization: Outland BBS  UUPCB  403-475-9588

Pick up the November issue of ST Format I believe it has a complete
breakdown of the DSP in the Falcon.
From: baffoni@phakt.usc.edu (Juxtaposer)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon BUS..
Date: 13 Nov 1992 18:28:00 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: phakt.usc.edu

In article <1992Nov13.224528.5855@prime.mdata.fi> paetau@mits.mdata.fi (Rasmus Paetau) writes:

>Do you mean to say that the Falcon really only has 2 channels? What's
>all the talk about 8-channels then? Even the STe has 4 channels if I
>have understood correctly, at least my STe plays soundtracker modules
>with 4 channels.

	No.  The Falcon has 8 internal channels that mix to two channels on the
output (1/8" mini jacks), but it handles the 8 channels independently 
internally.  If you wish to input more than the 2 channel input, you need to 
use an external AD(and probably DA for separate output) and connect it to the
DSP connector (which can then interpret/redirect/process the information).
Oh, and they decided to be backward compatible so you have 8bit sound available
for those soundtracker modules (Lord knows I have enough to worry about that
too :).

>--
>-----------------------------------------------------------------------
>| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
>-----------------------------------------------------------------------
					  Waiting for a Falcon that will not
					  just replace a TT, but surpass it.

-MikeB


Newsgroups: comp.sys.atari.st.tech
From: sanders@sci.kun.nl (Sander Stoks)
Subject: Re: Falcon BUS..
Organization: University of Nijmegen, The Netherlands
Date: Mon, 9 Nov 1992 12:31:56 GMT

In <1992Nov5.114927.14711@dcs.warwick.ac.uk> leo@dcs.warwick.ac.uk (Leo Hendry) writes:

>I asked questions similar to these a month or two ago, but nobody answered.
>Perhaps somebody knows the answers now.

>1) What is the speed of the Falcon's memory (Somebody said it had 0 wait
>states which seems to imply 16MHz, but they may have been wrong)
>2) How does the DSP access the main memory (Somebody said it is not connected
>to the data bus, in which case I suppose it must be some kind of serial link)
>3) Does the TOS V4 use the DSP to speed up things (for that matter does it
>make intellegent use of the Blitter?)
>4) Is the data bus between the memory and the 68030 16 or 32 bits wide (There
>seems to be an argument going on about this).
>5) Why does the benchmarks that I have seen posted here only indicate an
>approx 3x speed increase and real-world tests (excluding any disk access)
>only twice as fast?  If the data bus is twice as wide, the memory twice as
>fast, the processor at least twice as efficent and running at twice the clock
>speed it should be more like 10 times the speed.

Most of the things you ask I cannot answer, but I can see your last
point is not quite right. If every wheel of a car runs twice as fast,
the whole car runs twice as fast, not eight times. The double clock of
the 68030 in the falcon as opposed to the ST gives a factor 2 ONLY if
the memory is twice as fast too. Now the 68030 is indeed more
efficient (check out those bit shifts in QIndex...!) and it is said to
run at 3.84 MIPS. The ST is considered approx 0.8 MIPS, so there
should be a factor of about four. Add the fast shifter (but more
complex graphics, so not too big a difference), and the DSP which can
cut short some very CPU-intensive tasks. This should give a real-life
average speed factor of about 4-5. And include disk access; if there
really is a throughput of 3M/s (!!!) and an average access time of 12
ms (!!!) we could see some humongous speed increases here. (And
virtual memory swapping to disk would be really smooth...)


>Thanks,
>Leo

Sander SToks
sanders@sci.kun.nl
Newsgroups: comp.sys.atari.st.tech
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: Raster Copy [for window scrolling]
Keywords: raster-copy, window, scroll, fast
Reply-To: kim@vax.mpiz-koeln.mpg.dbp.de
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Wed, 11 Nov 92 13:37:28 GMT

In <H.KtV1EXXhvs6@elfhaven.ersys.edmonton.ab.ca> mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget) writes:

>In short (long?) I would be grateful to anyone who could share with me the
>secrets of window scrolling.  The faster, the better.  To keep things legal,
>though, I imagine only VDI calls should be used.

It seems to me that you should use the VDI(109)  function,  which
seems  to  be called vro_cpyfm() in standard C libraries. I don't
know though,  whether  this  function  will  work  properly  with
overlapping  rasters,  that  is,  whether you'll have to copy the
raster to some buffer first and then copy it from the  buffer  to
its  destination, or you can copy blocks directly from source tor
destionation.
To be prepared for new tos versions, you should restrict  use  of
this  method  to  the  top  window. I've seen that with MultiTOS,
background windows still have arrows, and I imagine it's horrible
if  you're  trying  to  devise an algorithm that tries to use the
blocks that wades through  a  rectangle  list,  trying  to  reuse
available  fragments  by block copying and filling in the gaps by
drawing.

>I have also heard that the speed of output to the window can be increased
>by aligning the window on a sixteen bit boundary?  How would this be done?

I never did it, but I figure you could do (in GFA):

PROCEDURE align_window(w_handle&,flags&)
  LOCAL x&,y&,w&,h&
  ~WIND_GET(w_handle&,4,x&,y&,w&,h&)
  x&=(x& MOD 16+1)*16
  ~WIND_CALC(0,flags&,x&,y&,w&,h&,x&,y&,w&,h&)
  ~WIND_SET(w_handle&,5,x&,y&,w&,h&)
RETURN

This should align the  workspace  of  the  window  by  a  16  bit
boundary.  By  manipulating  w& the same way as x& above, you can
force the window width to be a  multiple  of  16,  which  can  be
convenient with windows containing text.

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
Newsgroups: comp.sys.atari.st.tech
From: micro@imada.ou.dk (Klaus Pedersen)
Subject: Re: Falcon Bus
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Tue, 10 Nov 1992 18:00:14 GMT

grier@bnr.ca (Brian Grier) writes:
>If you chose a memory configuration where all of the bits for a given pixel
>are contained in the same word the number of memory access is greatly reduced.
>Therefore if Atari had choosen a different implementation, 8bits/16 bits per
>pixel with all the bits for a given pixel in the same word MOST applications
>would run much faster.

Atari have chosen a similar implemention of the true-colour mode, it uses
1 word/pixel.

>So why would anyone implement video memory the way Atari did? The best reason
>would be CAD/CAM packages, where your drawings exist in many different planes.
>I can only guess at Atari's reason, so I wont. This memory organization does
>have other benefits. Software blitting of sections of the screen will be faster,
>horizontal lines can be drawn 16 pixels at a time, and polygons can be filled
>with amazing speed.

The interleaved bitplanes are pretty fast for most things, for example sprite
drawing. And I guess that the most important thing - seen from Ataris point
of view have been that the screen-paint routines is the same, no matter how
many bit planes that are in use.

But I don't think that any 16 bitplane h-line or sprite routine is faster than 
good 1 word/pixel implementations.
(I wonder, does the Falcon have the same Sample-and-hold logic as the TT?
 Does it work in the true-colour mode?)


-Klaus
Newsgroups: comp.sys.atari.st.tech
From: doing@brahms.udel.edu (David Allen Doing)
Subject: Atari ST for sale
Organization: University of Delaware
Distribution: usa
Date: Wed, 11 Nov 1992 23:47:09 GMT

For Sale:  old Atari 520st with panasonic printer
              also included:
                      Hayes Smartmodem 1200

this is the 520st with no internal disk drive, however I do have the
external 3.5" dd, also I have the sc1224 monitor.
-all software is included at no extra charge

If interested, please email me at this address:

doing@brahms.udel.edu

-- 
-----------------------------------------------------------------------
David Allen Doing                               e-mial addresses:
Undergraduate Student                          doing@brahms.udel.edu
University of Delaware                         dbq49459@udelvm.udel.edu 
Newsgroups: comp.sys.atari.st.tech
From: clyde@hitech.com.au (Clyde Smith-Stubbs)
Subject: 520ST MMU pinout?
Organization: HI-TECH Software, Brisbane, QLD, Australia.
Date: Mon, 9 Nov 92 07:39:46 GMT
Summary: need pinout for 520ST MMU

Can anyone give me the pinout for the MMU in a 520ST (1986 vintage)
I want to add another RAM bank, and need to know where to get the
second bank RAS signal.

Ta muchly.
--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 300 5011
 clyde@hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 300 5246
 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
 HI-TECH Software: C Compilers for all manner of machines
Newsgroups: comp.sys.atari.st.tech
From: nino@vmars.tuwien.ac.at (Marinos Yannikos)
Subject: Re: MiNT and *.XFS files
Organization: TU Wien, Vienna, Austria
Date: Fri, 13 Nov 1992 11:23:19 GMT

grier@bnr.ca (Brian Grier) writes:
: When I downloaded MiNT 0.95B from GEnie a couple months ago
: the README file mentioned that it will load files with the
: extension "XFS", from the "/mint" directory, at initailization.
: From this I can assume these are supposed to be extensions to MiNT.
: 
: Basically what ".XFS" modules are available in the public domain?
: Also what is the basic template for creating a ".XFS" file?
:
  The "template" for .XFS files is described in the MiNT documentation
(filesys.doc, filesys.h) quite extensively. If you want to write a 
loadable file system, you should check out the Minix.XFS source code,
and TOSFS.C, BIOSFS.C, PROCFS.C, PIPEFS.C, SHMFS.C in the MiNT source
code...

-MY

Newsgroups: comp.sys.atari.st.tech
From: max@knuth.cba.csuohio.edu (Max Polk)
Subject: New idea regarding X-windows for the ST
Organization: Cleveland State University
Date: Thu, 12 Nov 1992 19:02:51 GMT

We have terminals.  They were designed to read and write text
characters that would control the host.  You can edit text, run
programs, transfer files, and so on.

Terminals got better.  They did fancy escape sequences so that you
could clear portions of the screen, use scrolling on portions of the
screen, and even process special characters, some of which were
"line-drawing" characters to make boxes and lines.  This is like the
VT52, VT100, etc.

Terminals got even better.  They began to use graphics escape sequences
to draw lines from any point to any other point, mix it with text,
scale and rotate the text, etc, as early as the VT125, and Tektronix.

Now we are at a day when many personal computers can emulate terminals,
and we have workstations networked together instead of a central
computer with dumb terminals.  Furthermore, we have X-windows and such
where you can open up any number of windows on a workstation where each
window represents a terminal, a game board, a picture, a notebook, a
drawing tablet, or basically anything you want.

Because X-windows is free from M.I.T., and because it is so successful,
and because it is so flexible, and popular, I suggest that we implement
X-windows for the ST (and other computers as well).

X-windows function calls are standard, and there would be compatibility
between any system (you could paint a picture with the same commands on
an ST as well as a PC as well as a DECstations 3100).  Because it can
be implemented via modem (I know, modems are quite slow when it comes
to drawing graphics remotely), you could call up a host, and it would
run it's chess program on your screen: you enter the keystrokes or
mouse clicks, and it draws on your screen the results.

If you could define a chess "font", where the letter "A" is really a
pawn, where the letter "B" is really a knight, etc., then the host
running your chess game need only send 64 characters to completely
describe the board.  In this case, fantastic graphics via modem is
achievable.
Newsgroups: comp.sys.atari.st.tech
From: mh1@irz215.inf.tu-dresden.de (Michael Hohmuth)
Subject: Re: MiNT and *.XFS files
Reply-To: hohmuth@freia.inf.tu-dresden.de
Organization: Dept. of Computer Science, TU Dresden, Germany
Date: Wed, 11 Nov 1992 15:23:48 GMT


In article <1992Nov10.181544.15794@bnr.ca>, grier@bnr.ca (Brian Grier) writes:

> Basically what ".XFS" modules are available in the public domain?
> Also what is the basic template for creating a ".XFS" file?

Currently, there's one file .XFS module available which lets you use a Minix
file system under MiNT. Look for mfs???.zoo.

Michael
--
Internet: hohmuth@freia.inf.tu-dresden.de

Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: MiNT, TCSH, CoNnect, Warp9...what they have in common?
Organization: SAR Systems Development & Processing, JPL
Date: Fri, 6 Nov 1992 17:37:21 GMT

In article <1dd85mINNlra@skat.usc.edu> mbaffoni@skat.usc.edu (Michael Baffoni) writes:
>	My journey in search of a system with MiNT, TCSH, Warp9, and CoNnect
>working very happily together has been a long one with both ups and downs,
>and strange sights indeed!  Let me exemplify:

Which version of MiNT?
>
>	When I load _just_ MiNT and TOSwin(1.1), I am completely, utterly
>unable to run another GEM program - PID errors and such.

Mebbe you should get the Toswin 1.4 that Eric Smith recently put on a.a.
>
>	If I load _just_ MiNT and TOSwin and have something "INIT="ed,
>it says "leaving MiNT" just before it drops me into the desktop, nothing
>running, and every .acc except TOSwin is loaded.  I can't run .prgs.

If you specify an INIT in your MINT.CNF file then it ordinarily will not
make it to the GEM desktop, so TOSwin is irrelevant then. The "leaving MiNT"
message means your INIT program exited, so MiNT shuts down. TOSwin is
absent from the resulting desktop because it only installs itself if MiNT
is active.
>
>	If I load Warp9 (as well as all the rest of my junk), MiNT, TOSwin,
>Warp9.acc, then everything has the new font, but I still can't run any
>.prgs. Warp9.acc is accessible, no bombs.

Strange. Warp9.acc almost always caused a lockup for me. I've only installed
the patch for 3.71 tho, I'm not up to the current (3.73?) yet.
>
>	If I load Warp9 (as well as all the rest of my junk), MiNT, TOSwin,
>Warp9.acc and have ConNect set to autorun (from the inst app of GEM), it runs 
>at bootup, just like it should, Warp9 is active, MiNT and TOSwin are active,
>and I have no problems whatsoever accessing the Warp9.acc.  In fact I can
>quit CoNnect, it puts me at the desktop, I can run most of my .prgs (including
>the old, original First Word!) and both Warp9 and TOSwin accs are accessible.
>No bombs.  This would be idyllic....EXCEPT EVERY ONCE IN A WHILE IT SEMI-LOCKS
>UP!

I've noticed that the Warp9 screen saver tends to lock up my MiNT sessions.
I haven't figured out how to disable the screen saver yet.

I also have problems with a lot of programs when BIOSBUFfering is active.
Uniterm exits with a bus error when it detects the CONNECT string after
auto-dialing a number. Big pain, haven't been able to track it.
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
Newsgroups: comp.sys.atari.st.tech
From: pyr579@oz.plymouth.edu (Technoid)
Subject: Alert Boxes in C
Reply-To: pyr579@oz.plymouth.edu (Technoid)
Organization: Plymouth State College - Plymouth, N.H.
Date: Sun, 8 Nov 92 23:05:21 GMT

Hello,

	I have just recently started doing GEM stuff with Sozobon C and
have created an alert box program, very simple, it just displays an
alert box and you click the button to end the program. I was hoping that
it would not exit from the desktop though. I run Neodesk and when I use
this program, Neodesk unloads, the alert box pops up on its own blank
screen, I click the button, and the Neodesk reloads. This is not what I
want, it takes time to do the above and I want to place this programs
icon on the Neodesk desktop and be able to call it up when doing other
things just to quickly see it. How do you create and alert box that will
simply display itself but no cause the desktop to go away?
	And, since I'm already here. Does anyone have any idea how to
place a graphic on the newdesk desktop and manipulate it? I do not
have any books for the ST and programming what code I have produced has
been largely through trial and error and looking in ancient ST log mags
with Clayton Walnums C articles. Any help with either would be great and
I'll try to post anything that I manage to create that is neat. Please
E-mail.

Thanks,

	Stephan

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Slick...
  	       Newts Are Neato-van...    Chameleons Are Cool...
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Newsgroups: comp.sys.atari.st.tech