INFO-ATARI16 Digest Mon, 20 Nov 89 Volume 89 : Issue 679 Today's Topics: atari ABC yea or nay ???? BUG in FWRITE (LATTICE C) Downloading, Help Me Gadgets by Small - Possible new '030 add-on board! Need help with Gulam/MX2 Ram Disks Terminator archive Vapourware!!! ---------------------------------------------------------------------- Date: 20 Nov 89 10:38:38 GMT From: uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!uxf.cso.uiuc.edu!rjk 752@psuvax1.cs.psu.edu Subject: atari ABC yea or nay ???? /* Written by suhonen@tukki.jyu.fi in uxf.cso.uiuc.edu:comp.sys.atari.st */ Much text deleted intermittently >The MC68000 is FAR from RISC!!!! It is absolutely a CISC processor! Not true. See below. < I am a month from graduation as a computer engineer, and.... >if only I where you professor, I'll would kick you out of the University!! >Almoust draduated computer engineer, and does not know NOTHING about >processors... Where is the word goning to????? Isn't there some sort of error in logic there ? Because I haven't programmed the 68000 and one of my statements about it was technically incorrect, I know NOTHING about processors. I know quite a bit about processors (I won't bore everyone by putting it in). The University of Illinois is in fact one of the best Colleges in the United states in the field of Computer Engineering, and I will graduate in December. However, they tend to concentrate on theory. I have had little experience with the hardware currently on the market. I don't see any smiles in your text. If you want to get personal with colorful insults, then please use mail. Your message is in very poor taste. There is enough bashing going on here, we don't need to start flame wars as well, do we ? I heard about the 68000 architecture from a friend at the University here (I haven't actually programmed it myself). Here is what he said: (Note that I now admit the 68000 is considered CISC) "Actually, the 68000 is considered CISC, because of the fact that YOU, the USER cannot write programs in its "basic" set. I am *quite* sure that at the very *heart* of the 68000 is a RISC ALU which executes a VERY small program (which is stored in the on-chip memory) which reads the instructions from memory and decodes them. So overall, the 68000 is in fact CISC, but it is run by a RISC heart. And yes, I am quite sure of this. I got this info from a (very informative) article on CPU architecture in Byte magazine (a special issue on architecture sometime in the last 14 months or so) -- they were doing a specific comparison of the basic operation differences between the 80x86 and the 680x0 families." Hopefully that will clear up any confusion that you or I created. ------------------------------ Date: 20 Nov 89 09:19:50 GMT From: eru!luth!sunic!mcsun!inria!loria!wiener.crin.fr!domen@bloom-beacon.mit.edu (Eric Domenjoud) Subject: BUG in FWRITE (LATTICE C) I'd like to report a bug I found in the function FWRITE of the library GEMLIB.BIN of LATTICE C. Writing 0xFF to a file causes an error. I've included the code of this function with some comments so that everybody can see the bug is. Did somebody already notice it? Does this bug really exist or only in my version ? (would be very strange) Anyway, be carefull when using this function. Eric ---------------------------------------------- FHANDLE = 20 ; file handle BLKCNT = 16 ; number of blocks to be written BLKSIZE = 12 ; block size BADDR = 8 ; address of the current byte BLKWR = -4 ; blocks written BYTEWR = -8 ; bytes written THEBYTE = -12 ; current byte FWRITE: link A6,#-12 clr.l -4(A6) ; no block written NEXTBLK: move.l -4(A6),D0 cmp.l 16(A6),D0 bge.s ALLDONE clr.l -8(A6) ; no byte written NEXTBYTE: move.l -8(A6),D0 cmp.l 12(A6),D0 bge.s BLKDONE movea.l 8(A6),A0 ; If the byte to be written is 0xFF move.b (A0),D0 ; D0 = 0xFF ext.w D0 ; D0 = 0xFFFF ext.l D0 ; D0 = 0xFFFFFFFF addq.l #1,8(A6) movea.l 20(A6),A0 move.l 8(A0),D1 subq.l #1,D1 move.l D1,8(A0) move.l D0,-12(A6) tst.l D1 bmi.s BUFFULL ; branch if the file buffer is full movea.l (A0),A1 ; Otherwise ... addq.l #1,(A0) move.b D0,(A1) ; D0 still contains 0xFFFFFFFF ext.w D0 ; ext.l D0 ; bra.s ONEDONE ; LOOK ... | BUFFULL: | move.l 20(A6),-(SP) | move.l -12(A6),-(SP) | jsr _FLSBF | addq.l #8,SP | | ONEDONE: V addq.l #1,D0 ; D0 now contains 0 ! bne.s NOERROR ; and we have an error !!!!! move.l -4(A6),D0 unlk A6 rts NOERROR: addq.l #1,-8(A6) bra.s NEXTBYTE BLKDONE: addq.l #1,-4(A6) bra.s NEXTBLK ALLDONE: move.l -4(A6),D0 unlk A6 rts ---------------------------------------------------------- ------------------------------ Date: 20 Nov 89 10:38:40 GMT From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso .uiuc.edu!uicbert.eecs.uic.edu!dillenbu@tut.cis.ohio-state.edu Subject: Downloading, Help Me Help ! How do I download a file from the Terminator archives to my ST ? I tried using binary ftp to d/l a file to my school computer and then binary kermit from there to my ST but I keep getting BAD Header and BAD checksum errors when I try to de-arc the files. Thanks, John Dillenburg ------------------------------ Date: 20 Nov 89 07:03:19 GMT From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!hudson!asts un.astro.Virginia.EDU!gl8f@tut.cis.ohio-state.edu (Greg Lindahl) Subject: Gadgets by Small - Possible new '030 add-on board! In article <3795@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >I exspect the Gadgets board to help a lot with Spectre and do almost >nothing for TOS. Hm. I thought the FaST Tech board was a 16mhz 68000 with a write-through 32k cache. So if you do lots of reading in a row, you get a big win. Now if you essentially mounted a 16mhz 68030 with a 16 bit data path onto the same board, and somehow get around the Fline problem, then you'd have something that would speed things up more than the Turbo16. Right? It wouldn't be as good as a 32-bit data path with no speed decrease on writes, but still better than a 68000 at 16mhz. Of course, I don't know if the '030 can handle different bus widths. My Moto books aren't that recent. The way that it wins over the PAK68 is that Jim Allen has partially decoupled the processor speed from the video speed. > The ST is a closed machine; a compatible, faster >redesign is pretty exspensive. But the TT *is* a compatible redesign with 32-bit everything, right? It will be interesting to compare the TT to other similar '030 boxes, when/if it arrives. ------ Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice. ------------------------------ Date: 19 Nov 89 15:05:49 GMT From: agate!saturn!ucscg.UCSC.EDU!dstr012@ucbvax.Berkeley.EDU (10003012) Subject: Need help with Gulam/MX2 Help!!! I just downloaded the Gulam shell and MX2. For some reason, MX2 can't seem to perform background tasks correctly. Every time I try to do a background download, it seems to refuse to send checksums back to the sender and it just eventually quits. I tried setting the priority higher but it still did not work. Has anyone gotten the MX2 kernal to work efficiently? Roman Baker dstr012@UCSCG.UCSC.EDU ------------------------------ Date: 20 Nov 89 08:31:24 GMT From: agate!saturn!ucscg.UCSC.EDU!dstr012@ucbvax.Berkeley.EDU (10003012) Subject: Ram Disks Is it possible or is there already out there a RAM disk program that could increase it's size as more and more files are put into it? I would really be great because I keep running out of space on deArcs. Roman Baker ------------------------------ Date: Mon Nov 20 11:35:00 UTC+0100 1989 From: VCD51661%DS0RUS54.bitnet@jade.berkeley.edu Subject: Terminator archive Hi there, last week i tried to access the terminator archive via mail and via ftp. I used the internet adress atari@terminator.cc.umich.edu and got the message "unknown host" using ftp. My mails remained without reply. Does anybody know whether the terminator archive is still working, or what else could be wrong? Thanx alot. /* ** Benno Salzgeber ** Institute for Computer Applications ** University of Stuttgart ** VCD51661@DS0RUS54.BITNET */ -- FOOD FOR THE LITTLE LINEEATER -- FOOD FOR THE LITTLE LINEEATER -- FOOD -- FOOD FOR THE LITTLE LINEEATER -- FOOD FOR THE LITTLE LINEEATER -- FOOD ------------------------------ Date: 20 Nov 89 10:37:12 GMT From: eru!luth!sunic!mcsun!inria!laas!ralph@bloom-beacon.mit.edu (Ralph P. Sobek) Subject: Vapourware!!! In article <13200@s.ms.uky.edu> phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: | In article <480035@hpdml93.HP.COM> rona@hpdml93.HP.COM (Ron Abramson) writes: | >I've seen the NEXT machine. It is very real. | I've seen the NeXT machine. It is very slow. | :-) | (Display postscript... bleah...) | - R'ykandar. Well, all that depends... I've seen other machines which display PostScript on the screen, and they were much slower for that than th NeXT! All this is like comparing apples (no pun intended) and oranges. Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU =============================================================================== Upon the instruments of death the sunlight brightly gleams. -- King Crimson ------------------------------ End of INFO-ATARI16 Digest V89 Issue #679 *****************************************