Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 085
=========================================================================
INFO-ATARI16 Digest Tue, 23 Jan 90 Volume 90 : Issue 85
Today's Topics:
AES help needed
Hacker Support
Help Needed with Atari H/W interfacing.
TOS 1.0,1.09,1.2,1.4,1.6
ZMDM 1.63 Failure Explained More
----------------------------------------------------------------------
Date: 23 Jan 90 15:22:35 GMT
From: ncrlnk!ncrcam!system!mike@uunet.uu.net (mike reiss)
Subject: AES help needed
Message-ID: <563@system.Cambridge.NCR.COM>
My son needs some help with a routine he is writing. He is much more familiar
with GEM programming than I am. The ST is considered HIS at our house.
Anyway, he has a question and I have the net access. Any help you can
give will be appreciated. Send replies to me, and I will make sure he gets
the info.
By the way, I believe that he is using Personal Pascal for this project if
that makes a difference. He does speak C for other things so don't let
the language stand in the way.
Me, I get to do Unix(tm) at work ... lucky me ???
thanks,
mike
------------------------from Joe--------------------------------------------
I've been working on a little (okay, NOT so little) workaround.
This essentially involves the rewriting of the AES form_do() routine to
allow for text objects to have wraparound text entry. Unfortunately,
I need to use the AES routine objc_edit(). The problem? Incredible lack
of adequate documentation.
Does anybody have any idea how to properly make use of objc_edit()? I
would _really_ appreciate an example of this function used in working
code. Any assistance whatsoever would be useful. Send any comments
or code segments to the net address above.
=========================================================================
_________
| |__) Some people call it pessimism; I call it realism!
\_!OE | \EISS
`---
------------------------------
Date: 20 Jan 90 14:01:20 GMT
From: mcsun!sunic!kullmar!pkmab!daniel@uunet.uu.net (Daniel Deimert)
Subject: Hacker Support
Message-ID: <2652@pkmab.se>
In article <1966@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>So, my argument comes full circle:
>
>Z4648252@SFAUSTIN.BITNET (Z4648252) writes:
>| Speaking of hacking...I am disturbed that Atari engineers feel that
>| the home computer hacker, the guy who wants to software/hardware
>| hack on his machine, no longer exits as a whole.
>
>I rest my case that information distributed via networks such as Usenet
>can become mangled and twisted. I was the Atari engineer responsible for
>the Usenet articles claiming that Atari could not afford to support the
>average hacker at the level they need. One of my points was that the
>more stuff went out via "unofficial" channels, the greater the chance
>of it being warped.
This is just another proof of the importance of written articles, that
will distributed as such, and not by word. _NOONE_ tries to tell his
friend a 200 page documentation file over the phone.
Just look at the Hitchhiker's guide to the BIOS. I know it's developers'
stuff, but I also know it's avaiable on most BBSs. No corrupt information,
perhaps a bit out of order, but that's Atari Corp.'s own fault. [ :-) ]
Even a two or three-page article won't be spread by re-typing, it will
most presumably be spread by sending the file further. It's the easiest
and most efficient way.
And as soon as it has left the people who has a modem and is circulating
"out there" it will BE COPIED FROM DISK TO DISK - not re-typed!
This is my experience. (as with the article about the STE from the
German ST Magazine -- it is spread further from USENET in Sweden, by
me further to a lot of people, then after a while it reached one of the
larger ST stores in Stockholm. A lot of thanks to Ralph Haglund for
translating to english!)
Of course, there will always be missunderstandings. There are a lot
of them, anyway, though Atari don't say anything. People claims that
you say that, and that, depending on the phase of the moon. Nothing
could be done about that, that's human nature!
>Hopefully, Atari can come up with some reasonable guidelines for
>professional developers so that the information they have may be freely
>shared with the hackers who want it.
I cannot say that I think Atari's latest step was an approchment. Isn't
it true, thats's it's now illegal to "disclose information"? Sounds
weird to me.
>In the meantime, I and other Atari engineers will do what we can to
>give out what information we can here on the nets, despite the fact
>that it gets more distorted the longer it's out there. Sigh.
Thank you.
--
NOTE: This is by no means intended as some kind of flame against
Ken B. or anyone else at Atari Corp. PERSONALLY. It is just
my humble (?) opinion!
--
Daniel Deimert, Fridstavagen 4, S-715 94 Odensbacken, SWEDEN
Internet: daniel@pkmab.se
UUCP: ...?uunet,mcvax?!sunic.sunet.se!kullmar!pkmab!daniel
------------------------------
Date: Tue, 23 Jan 90 13:25:00 EST
From: U009%CCIW.bitnet@ugw.utcs.utoronto.ca
Subject: Help Needed with Atari H/W interfacing.
Message-ID: <90Jan23.132911est.57468@ugw.utcs.utoronto.ca>
mcsun!ukc!harrier.ukc.ac.uk!gos.ukc.ac.uk!shc1@uunet.uu.net (S.H.Cogheil)
writes:
> My problem lies in the fact that the cartridge port has no R/W line,
> and that the GLUE chip does not allow you to write to ROM space anyway.
> (Hence I cannot use the Rom3/Rom4 lines as dummy R/W lines)
oliveb!pyramid!athertn!alex@apple.com (Alex Leavens)
replied:
> There was an article in START (like the first or
> second issue), which discussed a novel way of writing
> to the cartridge port; basically, it involved having
> some decode logic in the cartridge which took an
> address read by the user program, and turn it into
> an outgoing data byte.
I wrote the article in question. If you want to add something like a
'LS138 decoder to a few of the higher address lines, then you can do
what you want. reading from addresses FB00xx writes device '0' with data
xx (note the simplification in my design - the data is actually offset
by one bit since A0 doesn't exist on the cart. I later found out that
-UDS can be used as A0). Addresses FB01xx could then access device '1'
etc. The '138 will decode 3 address lines to 8 chip selects (0-7).
If you need more, cascade them or use 4 to 16 line decoders, etc.
Unfortunately, I can reach neither of the writers from here. I think
the information may be of interest to other hackers on the net, so I
am posting the reply and suggesting further discussion take place here
for the benefit of all.
Regards, Stu Beal, VE3MWM, (U009@CCIW.BITNET),
National Water Research Institute,
Burlington, Ontario, Canada.
The future lies ahead... and behind us lies... lies... lies.
------------------------------
Date: 20 Jan 90 13:36:13 GMT
From: mcsun!sunic!kullmar!pkmab!daniel@uunet.uu.net (Daniel Deimert)
Subject: TOS 1.0,1.09,1.2,1.4,1.6
Message-ID: <2651@pkmab.se>
In article <4221@csv.viccol.edu.au> gjocc@csv.viccol.edu.au (Greg O'Sullivan,
Senior Systems Administrator) writes:
>
>
> Wouldn't it be nice if the ST had 256K of low power battery
> backup up static RAM which could be write protected, instead of TOS ROMs.
>
> [stuff deleted...]
> Are there any technical problems that would stop you designing
> a add in board to replace the TOS ROMs in this way?
Sure. And every virus programmer in the whole world would instantly
buy a ST!
The idea as such is great, and I think it has been used. Wasn't it
COMPAQ who created some kind of RAM BIOS for an AT clone? I don't
know if it ever was avaiable on the market, but I remember reading
something about it in the swedish magazine "Datavarlden".
BUT, there are viruses... A lot!
--
Daniel Deimert, Fridstavagen 4, S-715 94 Odensbacken, SWEDEN
Internet: daniel@pkmab.se
UUCP: ...?uunet,mcvax?!sunic.sunet.se!kullmar!pkmab!daniel
------------------------------
Date: 21 Jan 90 00:33:23 GMT
From: mcsun!hp4nl!ruuinf!cs.ruu.nl@uunet.uu.net (Piet van Oostrum)
Subject: ZMDM 1.63 Failure Explained More
Message-ID: <2313@ruuinf.cs.ruu.nl>
In article <480eb0b0.14a1f@force.UUCP>, covertr@force (Richard E. Covert)
writes:
`
`and it continues like this until the SENDER gets tired and hangs up.
`So, ZMDM163 definitely fails, and is reproducible. ZMDM163 does not
`fail on EVERY FOREM ST board, but on the boards that it does fail,
`it fails everytime.
`
I experience failures with ZMDM (sorry, I don't know which version, I have
to find out.). At work we have Ataris connected to a Unix system at 9600 or
19200 bd, and there zmdm works fine in both directions. At home however I
use the same zmdm at 2400 bd (modem connection) and there only downloads
work. Uploads get aborted with an error (I don't believe it ever comes
further than the first block, if at all).
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')
------------------------------
End of INFO-ATARI16 Digest V90 Issue #85
****************************************
