Copy Link
Add to Bookmark
Report

Info-Atari16 Digest Vol. 90 Issue 214

eZine's profile picture
Published in 
Info Atari16 Digest
 · 26 Apr 2019

  

=========================================================================

INFO-ATARI16 Digest Fri, 16 Feb 90 Volume 90 : Issue 214

Today's Topics:
Becoming an Official Atari Developer!
Fine scrollin'
Hard Drive Information
New Atari ST keyboard
OK, so they sell the STe in Europe...
Phantom Typist
The 'PHANTOM TYPIST'
----------------------------------------------------------------------

Date: 15 Feb 90 16:15:33 GMT
From:
zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!irscscm!
root@tut.cis.ohio-state.edu (Admin)
Subject: Becoming an Official Atari Developer!
Message-ID: <1990Feb15.161533.13008@irscscm>

In article <489b42d9.14a1f@force.UUCP> covertr@force.UUCP (Richard E. Covert)
writes:
[Some stuff deleted]
>The Developer MUST be developing a COMMERICAL product for the ST. The
>Developer MUST submit 3 copies of said product to Atari Corp. the Developer
MUST
>re-register annually.

I think those 3 MUSTs are both to the developer's and Atari's
advantage.

> The packet I received said a LOT about what the Developer
>must do, but very little about what the Developer receives for his $250.00.
>
>Basically, all the Developer gets for his $250.00 is some mailing lists from
>Atari Corp. And the option of having his products (demos thereof) being
distributed
>by Atari Corp to all Atari dealers.
>

Having a mailing list of all Atari ST registered buyers and all
authorized Atari dealers can be a great thing to have for a developer.
And having a demo distributed to dealers sounds like good marketing to
me.

[more stuff deleted]
>And it doesn't even include the MWC C compiler. It contains the OLD OLD Alycon
>C compiler, which I have heard is VERY VERY bad.
>

Alycon C isn't VERY VERY bad. It's just not as good as MWC.

[more stuff deleted]
>don't want the Alycon compiler, and I don't like the $250.00 price tag. I do
some part
>time C programming at home, and don't plan to market a commerical product. So,
where
>does that leave me?? Out in the cold I believe.
>

It depends on how one looks at it. I see you as an Atari customer rather
than a developer.

>I wish that Atari Corp would try to help their customers more, and this new
DEvelopers
>program is not a good way to start a new decade.
>

It's a developer's program, not a customer's program.

Marshall Lake
mlake@irscscm.UUCP

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

Date: 16 Feb 90 16:33:46 GMT
From: pasteur!cory.Berkeley.EDU!soohoo@ucbvax.Berkeley.EDU (Ken "nmi" Soohoo)
Subject: Fine scrollin'
Message-ID: <22178@pasteur.Berkeley.EDU>

[Article related the woes of attempting to fine scroll using a full
screen blit, through both VDI and LineA]

Jeff,
First of all, if you want to see fine scrolling of the entire screen
done smoothly and well, take a look at NEOSHOW...

I've been toying with writing games and other such nonsense on the
ST for quite some time, and the ways to fine scroll are various and
sundry, but they amount to this:
1) You MUST double buffer -- i.e. draw to a second screen while you
show the user another screen, then swap the two when you have a
new screen created.
2) It's much better if you want to vertical scroll and NOT horizontal
scroll, 'cause you can word align your blit area.
3) If you want to horizontal scroll, the fastest way is to pre-shift
the entire playfield that you're scrolling, and word-align blit
the rasters into your double buffer.
4) You can keep a gigantic map elsewhere and blit sections of it to
a "window" within your screen, scrolling within the screen, so
that you avoid the hit to scroll the entire thing.
5) Generate your scrolling screen on the fly by blitting lots of little
pre-shifted squares (16x16 is the usual choice), using your own
bit blit routines.
6) If you don't need the functionality of the logic operations from the
VDI and LineA routines, then write your own blit routines.
If you're using 16x16 sprites, even a bitblit written in C will
outstrip the system (I know, I wrote one for grins).
Larger areas must have assembly.
7) Use the blitter if possible.
8) Buy an STE, they have hardware support for fine horizontal and vertical
scrolling, and darn if it ain't pretty to see!

Hope my ramblings help ;-)

--Kenneth "kens" Soohoo (soohoo@cory.Berkeley.Edu)
Atari Hacker (Atari's Hacker...)
"It could be worse, you could get hit by a bus..."
My opinions are my OWN, _not_ necessarily Atari's. But "hey", who knows?

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

Date: 16 Feb 90 15:26:32 GMT
From: timewarp.eng.ohio-state.edu!bks@tut.cis.ohio-state.edu (Brian K Smith)
Subject: Hard Drive Information
Message-ID: <77220@tut.cis.ohio-state.edu>

I am looking to hook up am IBM type hard drive to my ST. Does anyone
know which type of drive (MFM, RLL, SCSI) is best for this application, and
have information or schematics on how to build an interface?

Thanks...


-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
And we'll have fun, fun, fun 'til our grade point takes the money away...
bks@cis.ohio-state.edu Brian K. Smith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

Date: 14 Feb 90 18:01:45 GMT
From: bnrgate!bnr-fos!bmers58!atreus!andrewm@uunet.uu.net (Andrew Moizer)
Subject: New Atari ST keyboard
Message-ID: <1369@bmers58.UUCP>

In article <20795@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven
W. Klassen) writes:
>>In article <2048@ultb.isc.rit.edu> clf3678@ultb.isc.rit.edu (C.L. Freemesser)
writes:
>>>
>>> Well, there aren't any REAL replacement keyboards for the ST. You can
>>> buy those awful spring-things to stiffen up the keyboard, but they don't
>>> work.
>
>This may sound strange, but I personally, like the keyboard on my 1040ST
>much better than the keyboards which come standard with an IBM AT, PS/2,
>or (much worse) PC.

I must concur. I like the light touch of the ST keyboard. I can also touch
type
and find some of the IBM keyboards (especially the 'XT') type terrible to use.
I
also don't like the click that so many people seem to require.

About the only improvement would be some marking of the 'home' keys (f & j) as I
sometimes get going 'out of sync'

for what it's worth
Andrew


NO .sig yet. Standard disclaimers apply
Robert Andrews
Bell-Northern Research
?uunet!attcan!?utgpu!bnr-vpa!bnr-fos!titan!randrews <- haven't tried this yet

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

Date: 16 Feb 90 10:38:07 GMT
From: mcsun!hp4nl!maestro!solist.htsa.aha.nl!erwinh@uunet.uu.net (Chaos
Conquerer)
Subject: OK, so they sell the STe in Europe...
Message-ID: <1505@maestro.htsa.aha.nl>

Can someone please explain how they come to the story that the market in the
States is so much bigger than the market in Europe ??
As for what I have read, the market potential of the States for Atari isn't
verylarge, as there are millions of console sold in the States.
As for Europe the number of consoles is much smaller, thus having a larger
potential for Personal Computers (I don't mean the PC here, as this computer
has sold ten times more in the States than in Europe)

I may have a wrong point here, but still this how I feel about this issue.


Erwinh

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

Date: Fri,16 Feb 90 12:17:04 GMT
From: R.D.Chafer%sysc.salford.ac.uk@NSFnet-Relay.AC.UK
Subject: Phantom Typist
Message-ID: <16 Feb 90 12:17:04 A1027E@UK.AC.SALF.C>

I have experienced the Phantom Typist a couple of times lately, only since
I bought a hard disk though (a Third Coast Technologies 45MB SCSI which I
would reccomend to anyone). The software I use is all my own and all the
keyboard interactions are via evnt_multi. No fancy keyboard tricks! Could
the use of fast DMA be affecting anything?


=========================================================================
From: Robert Chafer

FTN77 Group
Computing Centre Telephone: +44 61 745 5678
University of Salford, Fax: +44 61 745 5666
Salford M5 4WT
United Kingdom

E-mail:
JANET: chafer @ uk.ac.salford.sysc
ARPANET: chafer%uk.ac.salford.sysc @ nss.cs.ucl.ac.uk
BITNET: chafer%uk.ac.salford.sysc @ uk.ac
or chafer%uk.ac.salford.sysc%ukacrl.bitnet @ cunyvm.cuny.edu

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

Date: 16 Feb 90 15:38:09 GMT
From: cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!barry@tut.cis.ohio-state.edu
(Barry Lay)
Subject: The 'PHANTOM TYPIST'
Message-ID: <1990Feb16.153809.19595@gpu.utcs.utoronto.ca>

The issue of having to move the mouse slightly when selecting menu items
reminds me of a similar problem on my machine. I have had instances when
a double click on a program doesn't do anything until the mouse moves. It
was suggested to me that the button up packet from the Ikbd was being lost
somehow, and the GEM didn't realise that the button was indeed up until the
next packet, which was a mouse move, had the button flag cleared. I get this
happening in the desktop as well as in programs.

Having played around with writing a program which waits for all sorts of
things, I have discovered that it is not difficult at all to loose input.
You also have to be very careful about how the keyboard interrupts are
handled so that you don't overrun the internal queues when someone types
quickly. Part of the solution is realising that you are single threading
all of those inputs through evnt_multi() in a loop. Plenty of opportunity
for deadly embrace or message explosion resulting in a crash.

Barry

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

End of INFO-ATARI16 Digest V90 Issue #214
*****************************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT