🚀 go-pugleaf

   ----- Transcript of session follows -----
mail11: %MAIL-E-LOGLINK, error creating network link to node SAMPO
mail11: -SYSTEM-F-INVLOGIN, login information invalid at remote node
550 <sampo::tripmgr>... User unknown

   ----- Unsent message follows -----
Received: from santra.UUCP (santra.ARPA) by hila.UUCP (4.12/4.7)
        id AA05370; Sat, 7 Mar 87 11:15:15 GMT
Received: by santra.UUCP (5.51/6.4.TeKoLa)
        id AA00760; Sat, 7 Mar 87 11:14:25 +0200
From: <santra::SCORE.STANFORD.EDU::INFO-ATARI16@santra.UUCP>
Message-Id: <8703070914.AA00760@santra.UUCP>
Received: by fingate Sat Mar  7 11:14:21
        from MAILER@FINHUTC.BITNET via rscs BSMTP.
Received: by FINHUTC (Mailer X1.23b) id 6763; Sat, 07 Mar 87 11:05:24 FIN
Date:         Wed 4 Mar 87 18:08:29 PST
Reply-To: santra::Score.Stanford.edu::Info-Atari16
Sender: "Atari ST users forum (INFO-ATARI16)" <FINHUTC::INFO-A16@santra.UUCP>
Comments:     To: "Distribution List: ;" <INFO-ATARI16>
Original-From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject:      Info-Atari16 Digest V87 #111
To: <atari520@fingate>, <sampo::fingate::tripmgr>
Original-To: <atari520@fingate>,<tripmgr%sampo.fudec@fingate>

Info-Atari16 Digest   Wednesday, March  4, 1987   Volume 87 : Issue 111

This weeks Editor: Bill Westfield

Today's Topics:

                 Re: An external RAM disk for the ST
                   Anyone got Microsoft Write Yet?
            Saving to ram disk (was: Saving the desktop )
                         hardware 'upgrades'
                      Re: MINIX - STD EXTENSIONS
                          degas print driver
                    Re: Drive C as RAMDISK - (nf)
                           Re: Interesting
                      Re: MINIX - STD EXTENSIONS

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

Date: 1 Mar 87 04:48:16 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrcae!usceast!tech@sdcsvax.ucsd.edu  (Bill Wood)
Subject: Re: An external RAM disk for the ST
To: info-atari16@score.stanford.edu

In article <587@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>A question to Bill Wood on the PolyDisk ramdisk cartridge:
>   Bill, I've heard a few rumors that the documantation included with the
>PolyDisk includes enough hardware documentation to allow extending the
>amount of ram in the cart.  Is this true and if so, how difficult does
>it look?  Is there any indication as to what will need to be changed in the
>driver to have it support the extended memory?

Hello!
    Well! I must say the interest in the ramdisk cartridge is most
amazing. In answer to your question, no they don't supply information on
how to extend memory nor do they supply driver source. I called and
talked to them when the unit came in and they were not real excited
about releasing source. This is stupid since the driver is less than 2k
long and is not going to be to much of a problem to sort out. I am
having problems getting dissasm the disassembler posted a while back to
do it for me. I haven't checked into it very well but am suspecting that
the dissassembler either doesn't like the fact that the driver does not
allocate any space for the bss or else it is upset about the super calls
in the code since it will dissassemble itself.
    I don't have the circuit figured out completely yet either so
the following is possibly subject to change.
    The Polyram has a 4-meg address space. That is they (I think)
support 32 64k blocks. Memory reads are performed in the first bank of
the cartridge address space and they map the second bank of the
cartridge for the writes. I am not sure yet how they are doing this.
The 4-meg above came from a conversation with their engineers.
    There is a way according to them to piggy-back more rams onto
the board but it requires cutting traces and they were not interested in
telling me how.
    The circuit consists of 31 IC's of which 16 are 256k dram. Five
of the chips are dual 4 to 1 multiplexers which I believe are used to
multiplex the addresses into the ram. I believe that the circuit can be
broken down into 4 major component areas: refresh timer, clock control,
address multiplexers and ram. This would make sence if they were
decoding a one meg address space as a piggyback expansion would suggest.
Another piece of evidence is that it takes 10 bits at a time for address
generation in a one meg space and they have 10 total multiplexers. They
use a ls123 timer for refresh timeout. That is they do nothing at all
about refresh when the system is running since the activity on the
cartridge address buss is enough to refresh the ram. The timer is
necessary to keep the memory alive when a reset occurs since the address
buss 'hangs' while the button is held down, and of course with a battery
backup it becomes necessary. The clock control is just a mapping of the
highest bit of the address to a clock chip expansion board. I am pretty
sure of this since their people said that you would have to disable the
clock control to go from a 2-meg space to a 4-meg space.
    The rest of the chips are simple ttl glue and a couple of byte
wide latches. I tend to think that synthesizing a write line is pretty
easy if you are willing to live with two or possibly three cartridge reads
for every write into the external address space. A base address with an
offset of 0-255 would allow the address buss to be used as a 'data'
buss, it then becomes necessary to do something similar to setup an
'address' buss and a write line.
    All in all, I think the circuit is pretty simple and elegant. I
can kind of understand their unwillingness to disclose to much since
there are sure to be several 'imatations' in the near future. I am going
to expand this one to one meg just as soon as I figure out how since I
am about 200k short of what it takes to get all of the compiler and
utilities out there that I want.
    I have not benchmarked this unit extensively but it is slower
than eternal.prg by what seems to be a factor of 2. This makes sence if
they must do two or several reads to the cartridge port to do a write.
In closing, I like this unit a lot and would recommend it to the rest of
you.
    In a related matter, I have been porting the UNIX V7 compiler
to the ST for about the past year. I have been using it for the past
several months and it seems to work. I could KILL Atari for making text
files use \c\r as a line terminator. The problems this creates are
amazing. But on with the tale, This is a true 32-bit int compiler that
as you would expect runs a little slower than say MWC if you don't
declare shorts every chance you can. It will however handle really large
programs  and will allow you to build an array that is as large as the
memory you have. I feel that 32-bit ints are necessary to port some of
the better software -- common lisp comes to mind as does gnuemacs.
    Anyway, I called ATT about this to find out what restrictions
there are on V7 and was told that I could pass this work on to anyone
with a source license to V7 or greater. Well that includes just about
any site on usenet at this point in time. What's this got to do with
you? Well...I would be willing to give this stuff away but don't quite
know how to go about it. I suppose that if demand is not to heavy I
could make a tape or two assuming that a copy of a source license came
with the tape.
    Cross compiling on a Vax has it's advantages are any of you
interested? Frankly, there is still more to be done on this, the VDI-AES
interface is not complete for instance. If you have any suggestions send
mail and I will try to figure out what to do.

            Bill Wood (!usceast!tech)

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

Date: 1 Mar 87 01:38:54 GMT
From: ihnp4!houxm!homxb!genesis!odyssey!jcs@ucbvax.Berkeley.EDU  (j.c.schwebel)
Subject: Anyone got Microsoft Write Yet?
To: info-atari16@score.stanford.edu

Has anyone used Microsoft Write yet or do  you know when it will be out???

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

Date: 28 Feb 87 01:31:26 GMT
From: tikal!transys!baron@beaver.cs.washington.edu  (Joe Portman)
Subject: Saving to ram disk (was: Saving the desktop )
To: info-atari16@score.stanford.edu

>In article <432@maccs.UUCP> gordan@maccs.UUCP (Gordan Palameta) writes:
>>I believe part of the original problem might be due to using C as the
>>RAM disk identifier.  I have heard on good authority that C is reserved
>>(to the cartridge port?), and that therefore you should never use C (or
>>A or B, obviously) for a RAM disk...

    On a related matter, when I boot a program from a ram disk, why
    can't the program see my floppy anymore? Is this normal? If thiss
    is a stupid question please forgive me, I've only had my ST a
    couple of weeks.


These are my own opinions, not those of my employer (self),
or any one connected with the company (mine)
Joe Portman (SA)                                USPS: TransSystems Incorporated
AT&T: 1-206-453-5560                                  1280 116th Avenue NE
              /-- uw-beaver!\         /-- camco!  \   Bellevue WA 98009
... ihnp4! --<               >-tikal!<             >-- transys!root
.. ihnp4! --<               >-tikal!<             >-- transys!root
              \-- microsoft!/         \-- teldata!/

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

Date: Tue,  3 Mar 87 08:34:20 PST
From: <DAVIDLI@simvax.bitnet>
Reply-To: DAVIDLI%SIMVAX.BITNET@forsythe.stanford.edu
To: info-atari16@score.stanford.edu
Subject: hardware 'upgrades'

   I've been reading the comments of people who seem quite angry that Atari
isn't instantly providing them with a means to upgrade their 520ST/1040ST to
some 'new' version.  I'd like to provide those folks with a history lesson
about the nature of 'upgrades' in microcomputing ...

   My first microcomputer was a Quest ELF.  I had to solder it together
myself.  It had a whole 256 bytes of memory, which was quite enough when you
consider that I had to key in programs in hexadecimal.  The only way I could
upgrade this machine was to purchase additional hardware.  Eventually, I had 4
kilobytes of memory, a typewriter keypad, an actual language (Tiny-BASIC) and*
a black- and-white monitor bought surplus.  My total investment was roughly
equivalent to the price of a 520ST with monochrome monitor.

   Then I spotted an Apple ][ (back in pre-color days).  I 'upgraded' my ELF by
selling it to another hacker and purchased an Apple ][+, with 16 kilobytes of
memory.  After several 'upgrades', I had 64 kilobytes of memory, a lower-case
modification, a modem (300 baud), a color TV, an Amber monitor, a printer and
lots* of software.  The investment, including software, would have paid for a
1040ST with color monitor and a (new Atari) laser printer.

   I was a BIG Apple fan. :-)

   Then the most terrible thing happened.  Apple came out with the //e.  The
ONLY way for me to upgrade to a //e was to sell my ][+ and purchase a //e.
What did I get for my upgrade?  More keys to type on, a few changes in the
operating system (which was NOT available for the ][+ in a changed ROM),
80 columns, 128K of memory ... minor changes. ALMOST ALL of the software I
already had worked well with the new machine.  This 'upgrade' would have paid
for a 1040ST with color monitor and a Color Ink-Jet printer.

   About the same time, IBM came out with their first microcomputer.  The
IBM-PC had 16K of memory, upgradeable to 64K of memory.  No, I didn't ever
purchase an IBM, but since that time I've seen the rise of the IBM-PC mark II,
with up to 512K on the motherboard, the XT, the AT.  NONE of these machines
was upgradeable.  You sold your old one and bought a new one.  But, funny
thing, most programs that would run on an IBM-PC would also run on an IBM-XT.
Some even run on the IBM-AT.  Hardware changed, but the software stayed
generic enough to cross over to the new systems.  IBM has been doing very well
with their microcomputer line.  If software on the PC didn't run on the XT (and
vice-versa), that particular computer line would be an historical footnote.

   The LISA came out from Apple.  Then the Macintosh -- Apple's answer to the
IBM PC-jr.  (The Macintosh was to the LISA what the PC-jr was to the PC).
These were also the first truly expensive 'closed architecture' machines. When
Apple came out with the 'new-improved' Macintosh, at a cost LOWER than the
original Macintosh and less than a year after its initial release, well,
naturally the early owners screamed bloody murder.  And Apple obliged them by
providing a 'new-improved' motherboard for roughly 1/2 the cost of the new
machine.  This 'upgrade' would have paid for a 520ST with a color monitor.  I
understand that LISA owners (who paid upwards of $6000 for their machines)
could 'downgrade' them to a Macintosh ... the only case where you can actually
LOSE money in getting a more widely used machine. :-) & :-(

   Some other systems of note which did NOT provide such 'upgrades' include
Tandy, Sinclair, Commodore (VIC-20 to C64 to C128), Atari (400 to 800 to 800XL
to 135XE...), Data General, Grid, Epson, etc., etc., etc.

   There are two threads here.  First, the software for the truly successful
microcomputers ran across the entire computer line.  COMPATIBILITY is a key
issue.  We have every right to ask Atari to provide software compatible
machines.  Indeed, if Atari has any business sense at all they will do
everything possible to ensure such compatibility.  So should those of us who
are currently writing software.  The blitter chip/ROM upgrade is feasible, and
a wise move on Atari's part.

   Second, manufacturers are under NO obligation to provide new hardware to
purchasers of their old hardware.  For instance, there is no way that current
Macintosh owners are going to upgrade their current machines to the new color
workstations.  They'll have to buy new machines.  We shouldn't blame Atari
for not providing us with upgraded machines.  Especially when those new
machines are not even on the shelves yet...  Upgrading is OUR responsibility,
at whatever cost we feel is necessary to our health and well-being.
Personally, I can live with 2-4 megabytes stashed in a 1040ST.  I don't need
16 megabyte capability.  If I ever need that much memory, I'll consider
purchasing a NEW computer.

                                        -- David Meile

               Send interesting comments to INFO-ATARI16.

                 Send FLAMES to davidli@simvax.bitnet.

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

Date: 3 Mar 87 13:39:43 GMT
From: sundc!gouldsd!mjranum@seismo.css.gov  (Marcus J Ranum)
Subject: Re: MINIX - STD EXTENSIONS
To: info-atari16@score.stanford.edu

In article <336daeb9.9540@apollo.uucp>, hays@apollo.uucp (John Hays) writes:
> would like to suggest the following two items be considered for
> STANDARD EXTENSIONS:
>
>         1. MIT's X Window System - for those with bitmaped screens
>
>         2. KA9Q's TCP/IP (Phil Karn) implementation.  This code,
[blah,blah,blah...]

Let's be real, here, guys. From what I understand (not having had a chance to
get my minix up, running, and beaten on) there are even questions as to whether
the hard disk drivers function properly. You are talking about implementing
an awful lot of fancy stuff on some pretty brain-damaged hardware.

I am sick of seeing all this 'when I get suntools running on minix I'll post to
the net" shit. Don't waste the net's time telling us about the great things
you're going to do unless you have a beta-test version :-)

I think it might be more productive to worry (in order) about exhaustively
testing minix, and making more portable drivers for a variety of hard disk
controllers, and then maybe clearing up the odd bug here and there. TCP/IP
is really very nice, but who wants to talk to a PC anyway ? I'd never let
one on my network unless the sucker had a better security system than being
able to boot off of *ANY* floppy you choose (hence any /etc/passwd, etc).

Please wake up and smell the roses, guys. UNIX wasn't written overnight, and
it certainly wasn't written by 800 usenet messages saying "well, I'd really
like to see this implemented..." or "I plan to port all the code for KERMIT
and build it into the kernel as a local area network", blah, blah, blah...

I suggest we maybe form a talk.minix.wild.wetdream, or a comp.os.fantasy
for you guys, and the rest of us can concentrate on simpler things like
maybe making it a bit more portable, robust, and adding some of our favorite
AT&T-like tools. Ferget the TCP/IP - the basics like 'sed' and 'lex' are
a lot more likely to be missed.

--mjr();

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

Date: 3 Mar 87 20:17:28 GMT
From: pixar!mgr@ucbvax.Berkeley.EDU  (Michael Griffin Russell)
Subject: degas print driver
To: info-atari16@score.stanford.edu

I'm writing a degas printer driver for the okidata microline 82a
and I have the distinct feeling I'm re-inventing the wheel.
Can someone send me such a driver, source preferred.  Thanks.
        Mike Russell ucbvax!pixar!mgr

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

Date: 3 Mar 87 16:44:19 GMT
From: imagen!atari!dyer@ucbvax.Berkeley.EDU  (Landon Dyer)
Subject: Re: Drive C as RAMDISK - (nf)
To: info-atari16@score.stanford.edu

> Just how mauch differance between the functionality of the different
> versions of the roms (in different countries?) is there ?

Not much variation.  The only major differences are changes in
the keyboard parser, the text in resources for the various
countries, and whether to set the PAL bit in the shifter.

The ROM has some idea of "what country am I?", but the ROMs are
different and those infamous "undocumented locations" may bounce
up and down depending on what country you're in.

-Landon Dyer, Atari Corp.        {sun,lll-lcc,imagen}!atari!dyer

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

Date: 3 Mar 87 17:17:58 GMT
From: imagen!atari!dyer@ucbvax.Berkeley.EDU  (Landon Dyer)
Subject: Re: Interesting
To: info-atari16@score.stanford.edu

> If you have a bad partition, or get a bad partition on your hard disk, try
> writing a little program which does a read RWABS from boot sector zero from a
> partition of the same size and writing it to the boot sector of the bad
> partition.  If this doesn't work, try one more sector, and keep trying one
> more sector, for a few.  Chances are you will be able to recover some of the
> STuff.  I will post a program which will do this, soon (like this week).

Logical sector zero (in a partition) contains a standard floppy-like
prototype-BPB with only the fields BPS, SPC, RES, NDIRS, NSECTS and
SPF valid (see your Guide, "Boot Sectors", pp 58-60 in my edition):

    BPS    = 512
    SPC    = 2
    RES    = 1
    NDIRS    = 256+
    NSECTS    = #sectors in partition
    SPF    = (((NSECTS/2)+2)/256)+1

NDIRS is nondeterministic, but is >=256.  Word values (like SPF) are
stored in 8086 format.  16 bit FATs are always used.


The Rwabs() trick mentioned above should work unless the FATs and root
directories have been clobbered.  I supposed you could back them up to
floppy before you ran that Michtron utility....

-Landon Dyer, Atari Corp.        {sun,lll-lcc,imagen}!atari!dyer

The views expressed here do not not
necessarily reflect those of Atari Corp.    Segments are for worms.

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

Date: 4 Mar 87 02:11:54 GMT
From: madd@bucsb.bu.edu  (Jim "Jack" Frost)
Subject: Re: MINIX - STD EXTENSIONS
To: info-atari16@score.stanford.edu

In article <475@gouldsd.UUCP> mjranum@gouldsd.UUCP (Marcus J Ranum) writes:
>I think it might be more productive to worry (in order) about exhaustively
>testing minix, and making more portable drivers for a variety of hard disk
>controllers, and then maybe clearing up the odd bug here and there. TCP/IP
>is really very nice, but who wants to talk to a PC anyway ? I'd never let
>one on my network unless the sucker had a better security system than being
>able to boot off of *ANY* floppy you choose (hence any /etc/passwd, etc).

THERE IS NOT ONE SINGLE UNIX SYSTEM ANYWHERE THAT IS INVULNERABLE TO
BOOTING DOCTORED MATERIAL.  If you can set up the system in the first
place, then you can also set it up again with altered files.  The only
thing that stops most people from doing this is a locked door.  You
can just as effectively lock up a PC.  Therefore, I don't think that
the ability to boot off a diskette is a valid reason not to allow PC's
to connect to a network.

Now that that's off my chest, the rest of the arguments given in M. J.
Ranum's posting are great.  Let's not try to set up complex programs
on MINIX systems until MINIX is humming along perfectly.

                   - Jim Frost * The Madd Hacker -
UUCP:  ..!harvard!bu-cs!bucsb!madd | ARPANET: madd@bucsb.bu.edu
CSNET: madd%bucsb@bu-cs            | BITNET:  cscc71c@bostonu
-------------------------------+---+------------------------------------
"Oh beer, oh beer." -- Me      |      [=(BEER) <- Bud the Beer (cheers!)

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

End of Info-Atari16 Digest
**************************
-------