jschober@gnh-starport.UUCP (Joey Schober) (03/08/89)
"Larry W. Virden" <pnet01!crash!tut.cis.ohio-state.edu!osu-cis!n8emr!lwv> writes: >> gee - what is going to sell the Apple IIgs if there are no games, music, >> paint, word processing , spreadsheet, or database programs! Note that the >> ONLY GS specific programs for spreadsheet are AW/GS and a non-supported >> VIP from the first month or two of GS promotion. There is also AW/Classic >> but it isnt GS specific... Ah, but it is! Somewhat, anyway. AW 2.0 and higher definitely uses GS Memory Manager calls to allocate memory; I dunno if it does any of the spreadsheet calculations in 16-bit mode. But... so WHAT? AppleWorks works, it's been working for 5 years, and everyone loves it... why should people stop using it on the GS just because it doesn't support the mouse and a desktop environment? You're doing something common: confusing "GS-specific" with "desktop based". I personally write a lot of "GS-specific" software (that is, software that runs in the 16-bit native mode of the 65816, uses tool calls, etc...), but most of it isn't running in the desktop environment. Now, I agree with you: if the biggest thing the GS has to offer is more memory in Classic AWorks, people are going to go buy the cheaper, faster //c Plus instead. The super-hi-res desktop environment is one of the GS'es biggest features. It's also one of its biggest liabilities: PROCESSING that huge graphics bitmap is what slows down the system so much! The optimum solution would be, of course, to speed up the computer; in fact, that's the only thing I really really REALLY want to see in a GS+ -- a 7 or 8 MHz clock. But I also wish some software authors would go for power instead of aesthetics all the time -- aesthetics has its place, but not in applications like word processors, spreadsheets, etc, IMHO. I really think that if we had more programs like APPLEWORKS (classic), PROSEL, and PROTERM, as some examples, there'd be many less complaints... <the never-ending debate continues.......> Joseph F. Schober, Sysop, StarPort BBS [703/931-0947 - 3/12/2400] ProLine..: gnh-starport!jschober@pro-novapple ALink PE: JSchober InterNet.: gnh-starport!jschober@pro-novapple.cts.com UUCP.....: ...crash!pro-novapple!gnh-starport!jschober SnailMail: 3528 Pinetree Terrace, Falls Church, VA. 22041 * Sent by StarPort BBS at 3/ 9/89 1:44:45 AM
lwv@n8emr.UUCP (Larry W. Virden) (03/13/89)
In article <8903111538.AA24748@crash.cts.com> pnet01!pro-ascii!pro-charlotte!pro-novapple!gnh-starport!jschober@nosc.mil writes:
-->Ah, but it is! Somewhat, anyway. AW 2.0 and higher definitely uses GS Memory
-->Manager calls to allocate memory; I dunno if it does any of the spreadsheet
-->calculations in 16-bit mode. But... so WHAT? AppleWorks works, it's been
-->working for 5 years, and everyone loves it... why should people stop using it
-->on the GS just because it doesn't support the mouse and a desktop environment?
-->You're doing something common: confusing "GS-specific" with "desktop based". I
Nope - I am not confusing GS-specific with desktop based. I was just unaware,
since I dont own AppleWorks, that they had special code in it that said "If
you are on a IIgs, go allocate memory from the memory manager". Thus,
it does work better in the GS environment than I had thought. I still
say that having only ONE such program is a sure sign of a declining environment.
-->instead. The super-hi-res desktop environment is one of the GS'es biggest
-->features. It's also one of its biggest liabilities: PROCESSING that huge
-->graphics bitmap is what slows down the system so much! The optimum solution
What I dont understand is if processing the minimal bitmap slows down this
machine so much, then why in heaven's name are all those other machines which
process bitmaps so fast? Is it perhaps not so much the bitmap, but the
code that is DOING the refresh / manipulation the thing that is slow? Or
is it indeed that the HARDWARE implementation of the bitmap subsystem that
is designed to run so slowly? I am just trying to understand. I have
seen a SE/30 and it SCREAMS! Now of course, the CPU is faster - but
everyone keeps telling me in voice talks that it isnt the GS's CPU that
is slowing down the GS, its because its doing everything in graphics.
--
Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817
75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP)
osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET)
The world's not inherited from our parents, but borrowed from our children.dseah@wpi.wpi.edu (David I Seah) (03/14/89)
>What I dont understand is if processing the minimal bitmap slows down this >machine so much, then why in heaven's name are all those other machines which >process bitmaps so fast? Is it perhaps not so much the bitmap, but the >code that is DOING the refresh / manipulation the thing that is slow? Or >is it indeed that the HARDWARE implementation of the bitmap subsystem that >is designed to run so slowly? I am just trying to understand. I have >seen a SE/30 and it SCREAMS! Now of course, the CPU is faster - but >everyone keeps telling me in voice talks that it isnt the GS's CPU that >is slowing down the GS, its because its doing everything in graphics. Larry, the Apple IIGS graphics screens reside in "slow RAM". The memory devices involved can read/write data at the old 1Mhz speed of the Apple II+. So, everytime you try to put something on the screen, the 65816 gets slowed down from 2.8MHz (assumption) to 1Mhz during those write cycles to the video buffer. The IIGS super hires video buffer is also 32K in size, 4x the size of the Apple II hires screen buffer. On the 1Mhz Apple II+, we couldn't display a clean screen transition using assembly language without using page flipping. The mind boggles at what is required to update a 32K SHR screen without the use of an extra display page, thoughtfully left out of the IIGS memory map! urrghghgh! I feel another flame coming on! Those other machines (like the Amiga) not only run twice as fast as the GS, they also (in the case of the Amiga) have specialized hardware that is designed to move graphics bitmaps to the screen VERY fast. Beats the pants off of the Apple. It is interesting to note that the Amiga text screen is actually a graphics mode, using alphanumeric bitmapped graphics! So, they have us beat in speed AND resolution. AND they can truly multitask with enough memory. With a hard disk drive, the Amiga's cruddy OS actually functions well, despite its graphic inelegance. About the Mac SE/X (or SE/30). According to Byte, not only is the CPU faster, the video memory is implemented using dual-port video RAM. Applying what scrawny knowledge I have gleaned from this school, I think this releases restrictions on the machine about synchronously refreshing the memory with the video hardware, AND the video display hardware can access this memory without any bus contention (because there are two "ports", two separate masters can access this memory). I am interested too in why the GS graphics hardware is so...limited. I have been told that, "Oh, the slowdown is requires to maintain compatibility with mumble mumble", but no-one tells me why. My guess is that the Mega II was incapable of running at higher speeds. Why use 1MHZ DRAMs anyway unless the Mega II couldn't handle anything faster? Gee, no flames! I'm maturing! Yay yay yay whee whee whee whoop! | <<<<<(((((( DAVE SEAH ))))))>>>>> | Internet: dseah@wpi.wpi.edu | Worcester Polytechnic Institute | Bitnet: dseah@wpi.bitnet | Computer Engineering Class of '90 | ALink PE: Omnitreant
lwv@n8emr.UUCP (Larry W. Virden) (03/15/89)
In article <1300@wpi.wpi.edu> dseah@wpi.wpi.edu (David I Seah) writes:
-->Larry, the Apple IIGS graphics screens reside in "slow RAM". The memory
-->devices involved can read/write data at the old 1Mhz speed of the Apple II+.
-->So, everytime you try to put something on the screen, the 65816 gets slowed
-->down from 2.8MHz (assumption) to 1Mhz during those write cycles to the video
-->buffer. The IIGS super hires video buffer is also 32K in size, 4x the size of
-->the Apple II hires screen buffer. On the 1Mhz Apple II+, we couldn't display
Hey Apple, here is an idea - is there a way to NOT slow down is accessing the
SHR buffer but slowing down if accessing the HR or DHR buffer? That way,
Apple II[e|c] mode programs get what THEY want and GS owners get what THEY
want!
--
Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817
75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP)
osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET)
The world's not inherited from our parents, but borrowed from our children.gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/17/89)
In article <8903151433.aa16916@SMOKE.BRL.MIL> ALBRO@NIEHS.BITNET writes: >(The reason the new code can't give both the same 16-bit CRC and the >same 24-bit CRC as any other block of code lies in the non-linear >nature of a CRC and the effect of byte order on a CRC.) This is simply wrong. Clearly setting aside 5 extra 8-bit bytes which are tailored to make the CRCs come out right is theoretically sufficient. Actually computing their contents efficiently requires use of Galois field theory, which is probably beyond the abilities of most hobbyist hackers. The amateur would probably resort to brute-force searching over all combinations, which would take far too long on an Apple to be practical.