gwyn@smoke.BRL.MIL (Doug Gwyn) (05/25/90)
In article <1675@batman.moravian.EDU> nicholaA@batman.moravian.EDU (Andy Nicholas) writes:
-One of the 'other' first WDM instructions I vote for is a reduced cycle-count
-MVN/MVP that really DOES work across bank boundaries. Next, I vote for
-a reduced cycle-count move instruction which can move more than 64k.
-I have also wanted [sr,S],y for a long time.
I didn't think there were any opcodes left..nicholaA@batman.moravian.EDU (Andy Nicholas) (05/25/90)
In article <12990@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > -One of the 'other' first WDM instructions I vote for is a reduced cycle-count > -MVN/MVP that really DOES work across bank boundaries. Next, I vote for > -a reduced cycle-count move instruction which can move more than 64k. > -I have also wanted [sr,S],y for a long time. > > I didn't think there were any opcodes left.. Go back and look at the data sheet. WDM is there for future expansion in future WDC microprocessors. It's to be used as a prefix code for a new instruction set. This is what i was wishing for. andy -- Yeah!
rhood@pro-gsplus.cts.com (Robert Hood) (05/26/90)
In-Reply-To: message from gwyn@smoke.BRL.MIL > In article <1675@batman.moravian.EDU> nicholaA@batman.moravian.EDU (Andy Nicholas) writes: > -One of the 'other' first WDM instructions I vote for is a reduced cycle-count > -MVN/MVP that really DOES work across bank boundaries. Next, I vote for > -a reduced cycle-count move instruction which can move more than 64k. > -I have also wanted [sr,S],y for a long time. > > I didn't think there were any opcodes left.. WDM is a pseudo-opcode; it doesn't do anything. This is the path Mensch chooses for expandability: two-byte opcodes. +--------------------------+--------------------------------------------------+ | Robert Hood - programmer | InterNet: rhood@pro-gsplus.cts.com | | RH 880 | ProLine: rhood@pro-gsplus (or) pro-gsplus!rhood | +--------------------------+--------------------------------------------------+
lbotez@pro-sol.cts.com (Lynda Botez) (09/24/90)
I recently was told that Nintendo will be utilizing a faster 65816 in their new 16-bit Nintendo machine that will be coming out in the near future. Nintendo is a BIG customer; certainly more important than Apple (in volume, that is). Who knows, perhaps the Apple IIGS will benefit from this. Lynda
chuckie@pro-odyssey.cts.com (Chuck Schul) (03/05/91)
now that nintendo came out with there 16 bit machine based on 65816.will software houses port over games to the gs?sim city etc? s ---- ProLine: chuckie@pro-odyssey Internet: chuckie@pro-odyssey.cts.com UUCP: crash!pro-odyssey!chuckie ARPA: crash!pro-odyssey!chuckie@nosc.mil
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (03/06/91)
>now that nintendo came out with there 16 bit machine based on 65816.will >software houses port over games to the gs?sim city etc? > >s >---- >ProLine: chuckie@pro-odyssey >Internet: chuckie@pro-odyssey.cts.com >UUCP: crash!pro-odyssey!chuckie >ARPA: crash!pro-odyssey!chuckie@nosc.mil No. Why should they? They now have a system that is supported by its manufacturer, is not an embarrassment to its board of directors and has superior speed, graphics and sound to most other game machines on the market. There is no reason to support the GS any more now than before. If anything fewer GS titles will be ported, most of the 65816 people will have to be moved to the Nintendo to get the games out the door. On a side note..... very few games work well with a hard drive on the GS. They either have a copy protection scheme seen on no other system, or if they are hard drive installable, do not quit to the Finder. Electronic Arts is particularly bad, they have manual protection on their Mac and IBM games, but disk protection on their GS and II games. DAMN ANNOYING!!! And unfair. Bitter? Nah, just drunk. :) UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com