Tabakal@UB.CC.UMICH.EDU (10/20/90)
Well, Apple may have given up (to be determined) on the GS, but
some people haven't. That's why I'm glad to pass on yet another
report from the field with Tony Fadell, the designer of the
25Mhtz 65816 chip. This report was in response to Jawaid
Bazyar's (sp?) work on developing a multitasking OS:
The algorithm and method sound great ... the only problem is
that the '816 by Mensch.. the Abort doesn't work correctly
for 4 instructions. So therefore no abort could be judged as
correct with out alot a external logic to implement it
correctly. AE tried using the pin but found the same
problems we ran into with Mensch's 816. What Jawaid is
asking for is not at all difficult. Here is an update... Our
second rev. has been layed out.. and the masks are being
made... Looks like we will have parts the first week of
November to test.
The other thing is that we added a new pin to the 816 to
replace the E pin if necessary.. it is the Page mode pin.
This pin alerts you when you will jump from aaaaxx to aaabxx
or greater. This can give the GS tremendous speed increase
because there is no need from extrnal bank select logic.
Tony.
So, keep the faith. If Apple is only interested in producing a slow
//e emulation card, the market will prove them wrong. Supply and
Demand -- basic Economics. Schools can't afford to buy lots of LC's
with cards at $3K a piece, even at $1.8K, the probable discounted price.
And, the home market isn't going to be excited by the product. The
future for the Apple ][ is in upgrading current owners. Apple
should realize this. Obviously, not for free. And, obviously,
the product will change over time. But, super fast cpu's will keep
me from moving to a 386.
-----------------------------------------------------------------------------
Todd A. Bakal All snappy sayings aside,
U of M Apple User's Group !Index will be updated
Ann Arbor, Michigan ASAP or my name's not...
Internet: Tabakal@ub.cc.umich.edu FTP: ummts.cc.umich.edu
Tab@terminator.cc.umich.edu 35.1.1.43 (PC5:)
UUCP: ...!uunet!ub.cc.umich.edu!tabakal BITnet: Tabakal@UMICHUBjb10320@uxa.cso.uiuc.edu (Desdinova) (10/22/90)
In article <6397165@ub.cc.umich.edu> Tabakal@UB.CC.UMICH.EDU writes: >Well, Apple may have given up (to be determined) on the GS, but >some people haven't. That's why I'm glad to pass on yet another >report from the field with Tony Fadell, the designer of the >25Mhtz 65816 chip. This report was in response to Jawaid >Bazyar's (sp?) work on developing a multitasking OS: ^^^^^^ You are correct! You win the prize! What prize? I dunno... > The algorithm and method sound great ... the only problem is > that the '816 by Mensch.. the Abort doesn't work correctly > for 4 instructions. So therefore no abort could be judged as > correct with out alot a external logic to implement it > correctly. AE tried using the pin but found the same > problems we ran into with Mensch's 816. What Jawaid is > asking for is not at all difficult. [November- yeah- my '020-eater GS becomes Reality!] Which four instructions? Are you saying that you corrected the functioning of the Abort pin? If so, then it would be no big deal for people who wanted to use my OS (whatever that may become) would just need to lay down a few $$$. But... The Abort pin is not vital to having a multitasking OS. Processes that try to access memory out of their assigned ranges can still be killed by using the IRQ or NMI signals instead of Abort. What Abort *IS* needed for is Demand Paging, which is something I really don't think is necessary on a GS. But it's the only good way to get around the 16MB memory limit on the '816. I've been checking out the Motorola '451 chip, which is a Memory Management device used with the 68000. It would hook up to the '816 with very little trouble, but it's limited to 32 segments (basically 16 processes, under a scheme I'm considering). I have yet to locate documentation for the '551, which is the spiffy new memory management chip for the 68K series. This will hopefully add some features I want (segment tables in Main Ram for an "unlimited" number of segments is one. This would work great if I designed my own VMEM chip, since a Transwarp's cache would take the place of an otherwise necessary and expensive associative register file). More news as soon as I have it... > The other thing is that we added a new pin to the 816 to > replace the E pin if necessary.. it is the Page mode pin. > This pin alerts you when you will jump from aaaaxx to aaabxx > or greater. This can give the GS tremendous speed increase > because there is no need from extrnal bank select logic. Uhh.. Is this pin a "bank address won't change, don't worry 'bout it" pin?? For implementing a sort of high-speed block memory access? Or am I not grokking this? > Tony. ^^^^ Truly a name that will be respected for decades to come. [stuff about apple/LC/IIe etc removed] >----------------------------------------------------------------------------- > > Todd A. Bakal All snappy sayings aside, > U of M Apple User's Group !Index will be updated > Ann Arbor, Michigan ASAP or my name's not... > > Internet: Tabakal@ub.cc.umich.edu FTP: ummts.cc.umich.edu > Tab@terminator.cc.umich.edu 35.1.1.43 (PC5:) > UUCP: ...!uunet!ub.cc.umich.edu!tabakal BITnet: Tabakal@UMICHUB -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! Apple II Forever! | (B O'Cult) Comp.Sys.Apple2- Home of the Unofficial Apple II Developer Support Team (DST)
bh1e+@andrew.cmu.edu (Brendan Gallagher Hoar) (10/24/90)
This is an article tha Desdinova@uxa.cso.uiuc.edu replied to that did not make it to this system The reply was Re: More ASIC news... Does anyone have a copy of the original article mentioning the possible pin changes that the ASIC Ent. 65816 clone will have available to forward to me? I'd appreciate it! Much thanks in advance! Brendan G. Hoar bh1e+@andrew.cmu.edu Carnegie Mellon, Inc.