Jump to content
IGNORED

I'm fine with the Lynx's CPU, but why did they pick a 6502 and not a Z80b?


Prosystemsearch

Recommended Posts

While I think that the Lynx is just fine with its 6502 CPU, and understand why it didn't get a Motorola 680, I still wonder: What made Atari and Epyx make the final decision to use the MOS 6502 rather than, say, the Zilog Z80b, Intel 8088, or one from Hudsonsoft? What, other than cost possibly, made the 6502 their pick?post-39329-0-20775900-1455156884_thumb.png

Link to comment
Share on other sites

The Lynx was not developed by Atari but by ex-Amiga engineers and then bought by Atari. Thus that Atari was familiar with the 6502 was not the reason.

I think the main reason was that the 6502 was available as component that could be integrated in your own chips what was important to reduce the number of chips in the Lynx to make it small enough. I wonder if a Z-80, 8080 or 6800 (hundred, not the 68K) were available as component at that time. The Hudson CPUs were also licensed 6502 cores with additional functionality in one chip. See also the last paragraph of this quote from the Lynx F.A.Q.:

 

 

Q. Why does the Lynx use a 6502 and not a 68000?

 

A. "Some people believe it's less of a processor than the 68000, for example. That series of chip was used in the Amiga, but it wouldn't make our machine do things any better. In fact, it would only make the unit larger and more expensive. It's also harder to write 68000 code, so we definitely made the right decision."
--R.J. Mical

"The real answer for the choice for the 6502 vs. 68000 was price. Secondary considerations (that did not really enter into the decision making process): 68000 code is very fat compared to 6502 code. An application that takes 1K of 6502 code averages 2.5 to 3K of 68000 code. The 6502 is very bus-efficient, the 68000 has lots of dead time on the bus. As for it being harder to write 68000 code, that is probably not true, and in any case was not part of the reason the decision was made."
--Stephen Landrum

Additionally, inside sources at Atari say that one major reason for the 6502 vs 68000 processor choice was that the 6502 design was available as a component that could be plugged into a custom chip design. This allowed engineers to build a chip with a 6502 and other supporting hardware around it all in one package. It is only around 1993-1994 that Motorola offered the 68000 as a design component.

  • Like 3
Link to comment
Share on other sites

A variant of 65816 are used in SNES. So it could have been possible but also more expensive. Color hand held were already pricey back in the day so... It would have been nice to see 16-bits CPU running on Lynx capable of faster gameplay and less slowdown and maybe more than 16 colors per scanline. 65816 is also 100% capatible with older 6500 code, the CPU starts in 8 bit mode at power on so...

 

 

Think someone can do a 32x-esque upgrade to Lynx with 65816 so it'd play existing games and in 16 bit mode, play something that can come close to SNES level?

  • Like 1
Link to comment
Share on other sites

Considering the limitation due to the resolution I think the Lynx does alrealy feel on the level of an SNES. The chipset is fast, we have vibrant colors (could be more of them, but then again 256 would be pointless at such a low resolution) and scaling effects en par with mode-7.

 

I would have never thought of the Lynx as a system that delivers an 8-bit-feel. Just as the PC Engine and the SNES could be considered 8-bit CPU-wise I don't see why the CPU as the only standard chip of the Lynx would make it a system feeling like 8-bit. Hell, the SNES suffered from tons of slowdown thanks to the underpowered CPU, so it is really not an example of what the Lynx could become had it been even better.

 

 

By all means, the Lynx was always meant to feel like a portable 16-bit game system and succeeded imo. It is such a vague terminology anyway, since the bits habe little to do with the audio-visual quality. But it is a device that feels at home in the generation of Mega Drive, PC Engine and SNES imo.

Edited by 108 Stars
  • Like 1
Link to comment
Share on other sites

Specious? Lynx was developed by ex-Amiga engineers, who were ex-Atari engineers, so they were very familiar.

 

No, the Lynx was designed by Dave Needle and Robert J. Mical who were both on the Amiga design team and later on the 3D0 team but did not work for Atari before. Robert J. Mical worked for Williams before and I can't find any source saying that Dave Needle worked for Atari before the Amiga. You are probably thinking of Jay Miner who designed the 2600 and 8-bit chipsets and later designed the Amiga but had nothing to do with the Lynx.

Besides my remark was not about the design team's familiarity with the 6502, but that Atari had nothing to do with the CPU's choice because Atari did not design the Lynx.

 

Robert

  • Like 1
Link to comment
Share on other sites

No, they were on the 3DO Team. :D

 

First there was audio.

Then came video.

Finally came threedeo. 3D Audio/Video. No Zero there. ;)

 

LOL, I never thought about that way.

BTW. The result from the Jaguar cart signature check must be $03D0DEAD so therefore I thought it was a zero :P

  • Like 4
Link to comment
Share on other sites

You're not pulling my leg now, are you? If that is the check, I must admit someone was pretty awesome at Atari for making that up, even if it uses a 0. :D

 

No, it is true, just disassemble the Jaguar boot ROM. The GPU does the decryption of the cart signature and stores the result. Then the 68K checks if the result is $03D0DEAD and shows the red screen if it was not. The rumors are that Dave Staugas (of Atari TOS hidden message: "Dave Staugas loves Bea Hablig" fame) is responsible for that.

 

It seems that it is even in the CoJag arcade hardware as see in this source from Mame (search for 3d0dead).

 

 

Robert

 

 

 

Edit:

Part of the boot rom source code that checks the cart. Look for 03D0DEAD near the end:

	lea	intro,a0		;copy Andy into ram
	lea	introadd,a1
	move.l	a1,a2
	move.l	#introx,d0
	move.l	#intro,d1
	sub.l	d1,d0
	lsr.l	#2,d0
	bra.s	loadi
;
;	move.w	#(introx-intro)/4-1,d0
loadintr:
	move.l	(a0)+,(a1)+
loadi:
	dbra	d0,loadintr
;
	move.l	#VBpat,$59BA		;7-Mar-94 stuff our v-blank adj
;
;
;
	move.l	#0,G_CTRL		;Stop the GPU
;
;  Zero out GPU space
;
	lea	G_RAM,a1
	moveq	#0,d0
	move.w	#$1000/4-1,d1
gpu0:
	move.l	d0,(a1)+
	dbra	d1,gpu0	
;
; Copy over the GPU program
;
	lea	RSAgpu,a1
	move.l	#GPUSTART,a0
	move.l	#GPUEND,a2
gloop:
	move.l	(a0)+,(a1)+
	cmp.l	a2,a0
	bcs	gloop
;
	lea	Public,a1
	lea	G_RAM,a2
	moveq	#68/4-1,d0
keyloop:
	move.l	(a1)+,(a2)+		;stuff in our Public key
	dbra	d0,keyloop		
;
;
;
;
;
;   Before we call Andy, we have to qualify the Kart...
;     to do that, we need to switch into Cart ROM mode
;     which may be incompatible with our boot-rom, 
;     so we ll need to finish executing out of dRAM
;
;
;
	lea	BASE,a0
	moveq	#0,d0
	move.b	ROMCONFIG,d0		;get ROM config byte
	andi.w	#%11110,d0		;just allow a few bits
	ori.w	#$1861,d0
;
	move.l	#RSAgpu,G_PC-BASE(a0)	;deRSA code starts here
;
;
;
;execRAM	equ	$4800		;for testing
execRAM	equ	$400			;for real
;
	lea	goreloc,a1		;copy our next code fragment
	lea	execRAM,a2		; into RAM before we switch on
	move.w	#(gorelx-goreloc)/4,d1	; the Kart
.gorelp:	
	move.l	(a1)+,(a2)+
	dbra	d1,.gorelp
testx:
	jmp	execRAM			;go do it in RAM
;
;
;
;  The following code is executed out of RAM
;
goreloc:
	move.w	d0,(a0)			;set MEMCON1 for our Kart
	move.l	FLAGS,d1		;get flags before start of GPU
	move.l	#1,G_CTRL-BASE(a0)	;sick the GPU on the Kart (deRSA & MD5)
;
	btst.l	#0,d1			;check bit0, (intro skip)
	beq.s	doAndy			;if normal, just start-up ANDY
;
;  Special Kart (probably diagnostics)
;
wait:
	move.l	G_CTRL-BASE(a0),d0	;wait here
	lsr.l	#1,d0			; til GPU is done
	bcs	wait
;
	move.l	G_RAM-BASE(a0),d0	;GPU is done qualifying Kart
	cmpi.l	#$3D0DEAD,d0		;is it a Good'n?
	beq.s	skipAndy		;br if so
;
;  illegal kart, let Andy kill for us
;
doAndy:
	jsr	introadd		;go do Andrew intro
skipAndy:
	move.l	JUMPVEC,a0		;get start vector
	jmp	(a0)			;Jump II Kart (wherever it wants us)
;
	nop
	nop
  • Like 2
Link to comment
Share on other sites

  • 5 months later...

The Z80 is not as efficient as the 6502 in that you need to run it at 4Mhz to get about a similar performance as the 6502 at about 1Mhz.

 

Which makes me come to another point, the 6502 on the Lynx runs at up to 4Mhz (3.6Mhz on average according to the FAQ).

Compared to f.i. The C64 at 1Mhz and Atari 8-bit home computers/5200 at 1.79Mhz this is a pretty big difference.

Already the speed between the C64 and the A8's can be pretty noticible on some games.

  • Like 2
Link to comment
Share on other sites

The Z80 is not as efficient as the 6502 in that you need to run it at 4Mhz to get about a similar performance as the 6502 at about 1Mhz.

 

Which makes me come to another point, the 6502 on the Lynx runs at up to 4Mhz (3.6Mhz on average according to the FAQ).

Compared to f.i. The C64 at 1Mhz and Atari 8-bit home computers/5200 at 1.79Mhz this is a pretty big difference.

Already the speed between the C64 and the A8's can be pretty noticible on some games.

Absolutely! This is one of the reasons why I still think cross re-compiler could work. ie. take some NES code for example, disassemble it with automatically added comments where PPU, VRAM, APU and input addressing is done, then recompile it replacing those IO calls to Lynx routines to do the same / similar functionality, and in theory because of the extra CPU power combined with Suzi, I think it would be possible to 'port' NES games to the Lynx. The C64 would be much more difficult as the hardware for graphics is very different and the C64 has more 'available' RAM. Sprites would have to be scaled down due to screen size and some manual changes would need to be done with regards to timing, input and screen resolution, but in theory its possible.

  • Like 2
Link to comment
Share on other sites

Absolutely! This is one of the reasons why I still think cross re-compiler could work. ie. take some NES code for example, disassemble it with automatically added comments where PPU, VRAM, APU and input addressing is done, then recompile it replacing those IO calls to Lynx routines to do the same / similar functionality, and in theory because of the extra CPU power combined with Suzi, I think it would be possible to 'port' NES games to the Lynx. The C64 would be much more difficult as the hardware for graphics is very different and the C64 has more 'available' RAM. Sprites would have to be scaled down due to screen size and some manual changes would need to be done with regards to timing, input and screen resolution, but in theory its possible.

 

I'd prefer A8 :) Then again.......SM on the Lynx........awwwwwwesome :D

  • Like 1
Link to comment
Share on other sites

SMS games could also be ported. It uses Z80 at 4MHz so it'd run "better" on Lynx. You'd likely need to do the main code from scratch but graphics and some sound should be easily converted to Lynx format.

 

Phantasy Star, Golden Axe, etc on Lynx please. Lynx doesn't have many RPG style games.

  • Like 2
Link to comment
Share on other sites

Some guys in the Atari 8-bit form have released Z80 to 6502 de-re-compilers and many games have been ported. The problem is, as always, the custom hardware (if any), differences in display resolution and color, and the sound hardware.

 

I briefly took a look at converting some Atari 8-bit games, and I think it's possible, but the screen size is a killer. You could probably do it easier if you scroll the screen in the horizontal, since a lot of games on the 8-bit use 160x192 resolution. I was specifically looking at Bruce Lee, I think with screen scrolling, you could even rip and res-use the graphics.

  • Like 2
Link to comment
Share on other sites

  • 6 years later...

Well i sometimes wonder if it really matters wether type of processor was choosen because whether they opted for a 6502,a 68000 or a Z80 etc,,, those whether cpu type based machines could still run those same availible games pretty well,i am happy with my atari lynx for what it is and it proves that it could run games wich were also on both the genesis & snes,the lynx with it’s amezing performances for it’s time along with certain official &
homebrew games & ports can be associated with those 16bit systems??

698CA298-6692-4CDA-9E16-C76F5C898567.jpeg

85DD3D26-E2E0-4F6A-8A5C-E510F65B6E1D.jpeg

Edited by johannesmutlu
  • Like 2
Link to comment
Share on other sites

I didn't knew about this thread.

IMO in the Lynx there is a 6502 because it has the best ratio of versatility to transistor count and it was an option at the time to embed it as a CPU core into the Mikey. Just look at the Mikey die shot:

 

obraz.png.c05acdefc19ec6f2617b165fd134a953.png

 

CPU (upper left corner) occupies only about 15% of the entire chip area. Every other reasonable CPU core would be much bigger.

 

The only drawback of using the 6502 in the Lynx I can think of is that it has inadequate addressing modes to handle Suzy's SCB efficiently - SCB is a structure that can be anywhere in the memory and 6502 can't address its fields quickly.

 

 

 

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...