Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!kth.se!sunic!mcsun!unido!ipsi!wallmann From: wallmann@ipsi.UUCP (Georg Wallmann) Newsgroups: comp.sys.atari.st Subject: Re: Graphics on the STE - v. generally speaking... Message-ID: <1563@ipsi.UUCP> Date: 15 Apr 91 14:01:05 GMT References: <1991Apr3.051045.1894@ns.network.com> <1991Apr03.150135.26529@chinet.chi.il.us> <40922@cup.portal.com> <1991Apr5.231704.19657@jato.jpl.nasa.gov> Reply-To: wallmann@bern.UUCP (Georg Wallmann) Organization: GMD Darmstadt (MSD/NAT) Lines: 74 This comes a little late but... [In resonse to H.CHus Color graphics board] I've been thinking about the same thing too, but my calculations always came up with "too expensive". Of course if you think 16 MB isn't expensive ... as you do in your post. While thinking about it I had this great idea for a new RAM technology, which unfortunately (then unbeknownst to me) already existed as dual-port RAM. Even then the bus width needed and the cycle speed is just about too ridicolous for a home computer. Personally I'd be happy with 640*400*16bit colors at 70Hz and some hires in mono. That would be monetarily feasible, I only want color for the games anyway, and some hires for programming. I as a lowly long-time Atari customer, would indeed be already happy over some _small_ improvements. How about Player/Missile Graphics for at least the *&^% mouse cursor, I can not believe that in the nineties we still got to erase the cursor, draw something, turn it on again, erase the cursor draw something , turn it on again (*) Not neccessarily Atari specific: Floating point is done in hardware (What %age of the user crowd actually uses floating points (me NEVER!!) ?), but the stuff you'd really need is done in software (probably in compiled Alcyon C to boot) Programs like EZ-draw would definetely profit from a hardwired draw routine for example. How about a microprogrammable stupid CPU, that you'd just give instructions like FOR(;;) ;; this is some mix between IF IRQ pending ;; english, basic, lisp C and ML GRAB BYTE from PORT0 ;; lisp for the comments that is STUFF it into BUFFER at $XXXX ;; har har IF BUFFERP == full signal IRQ LEVEL 2 CLRIRQ END That's basically perfect for sound processing, non DMA I/O processing and maybe even so stupid tasks as memory initializing. And the 'real' CPU with it's overkill of registers and cache and what have you needn't worry about those bothersome context switches for every *%^$ little interrupt. Why is everyone so hung up about processor speed ? Sure it's nice that the compiler does it in 5 minute, if it used to grind for 15 minutes but chances are that a faster harddisk might be just as profitable in terms of speed. How often do you compile, aren't you 90% of the time just typing stuff into an editor ?? Personally I am quite happy even with a lowly 68000 @ 8Mhz. Yes you speed demons it's allrite for me, IF the rest of the hardware would do the job, I think a CPU shouldn't do like graphics, I/O and sound!! My guess it that there just aren't enough competant people in hardware R&D (anywhere for that matter) to do the job. So they put in a faster CPU and delegate the rest to a cheesy graphics card, which virtually does nothing except converting RAM to colored dots.(the one Intel or TI chip I heard about maybe an exception, but probably not). Ok this does not neccessarily apply to machines in scientific environments, where one shittily written application is layered on top of another (probably in some local LISP dialect) until the processor croaks. About every two years it gets to me and I write an article like that, that's maybe because I would like to buy a computer and don't see anything I'd like to buy. (Well that ST Notebook sounds tempting, got yet to see one though...) thanks to the readers of comp.sys.atari.st for taking it with some humor and letting the old man ramble on a bit. bye y'all Nat! (*)Probably the Amiga does that right