Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!WISCVM.WISC.EDU!MAILER-DAEMON%hila.UUCP%FINGATE.BITNET From: MAILER-DAEMON%hila.UUCP%FINGATE.BITNET@WISCVM.WISC.EDU.UUCP Newsgroups: comp.sys.atari.st Subject: Returned mail: User unknown Message-ID: <8703091340.AA12097@hila.UUCP> Date: Wed, 4-Mar-87 21:08:29 EST Article-I.D.: hila.8703091340.AA12097 Posted: Wed Mar 4 21:08:29 1987 Date-Received: Tue, 10-Mar-87 05:33:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 418 ----- 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 ... 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: 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)" Comments: To: "Distribution List: ;" Original-From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #111 To: , Original-To: , 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: 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 ************************** -------