7800 vs.....

[malducci]

Speaking of the GameGear, I firmly maintain that its technical similarity to the SMS helped the SMS have a much larger library. Even though the SMS essentially died in North America around the time of the GameGear's introduction, companies could quickly create SMS versions of GameGear titles and release them in Europe where the market was very viable. In the end, I think there are something like 2 or 3 euro SMS games that were never out in North America ... yet will play on a North American system.

 

The support by Tec Toy in Brazil probably helped as well, indirectly. Have you seen some of the GG to SMS converted roms (hacks)? I remember there was one of Aleste, but the palette was cut down to SMS. Still looked pretty good.

 

 

Though, if you really want to be picky, the GBC has not a Z80, but an enhanced 8080 architecture

I didn't find that out until last year. Funny as I had coded GBC demos in assembly back in '99, all the long thinking it was a z80. I had no clue about the shadow registers. But yeah, that's why I put 'variant' in there The GBC's sprite per scanline limit is nice though, even more so considering the ratio of sprite pixels to screen res limit. I thought it was a great little system. Smurfs, albeit difficult, was an impressive GBC game.

[Gorf]

The video on the SMS looks alot cleaner. I think the SMS handled larger sprites

a little cleaner than the NES.....all classic consoles for the most part have flicker

but the NES video is not really all that great to begin with and the flicker tends

to be a lot more noticeable. Im going by comparing the two on the same television

set. The SMS just seems a bit more robust in the color and the crispness department.

 

You can do games on the SMS which will look much better than NES games, since you have the whole 15 colour attribute palette for each sprite and another 15 colour attribute palette for the background, without those 8x8 pixel 3 colour attribute restrictions like the NES. Both have almost the same resolution (the SMS lacks a few lines which is not really a problem) and can actually display the same amount of sprite pixels per line. The only thing which the NES can do better is sound (well, compared to the European/American SMS, some japanese Sega Mark III consoles have a Yahama YM2413 FM chip, which is quite nice). The SN76489 (which is also in the Colecovision) can only have 4 square waves plus noise, while the NES has 2 square waves with variable pulse width, triangle waveform, 2 types of noise (short and long period - short period can be used to make a "dink" sounding noise), plus a DPCM channel.

 

 

Well whatever the actually technical reasons might be, I just never liked the video quality of the NES.

The SNES was really nice. SNES 'Smash TV' was a really good port. The Sega Genny port was quite

disappoining in comparison....it did not even use the whole screen.

[Vigo]

Well whatever the actually technical reasons might be, I just never liked the video quality of the NES.

 

You mean "quality" as in "graphics capability" or the artefacts of the composite video output?

 

The SNES was really nice. SNES 'Smash TV' was a really good port. The Sega Genny port was quite

disappoining in comparison....it did not even use the whole screen.

 

The SNES is another quirky architecture. Great effects (I just LOVE the color add/subtract modes), really advanced sound, but a pain-in-the-ass CPU, which is simply too slow to handle all the advanced stuff the graphics are capable of. The 65816 is not really a full 16bit CPU. I've been told it has in fact a 16bit ALU, but I simply don't understand for what, since it has an 8 bit data bus (an opcode like adc #$1234 takes 3 bus fetches, so the first result of the addition can be computed while the high byte of the argument is fetched), and the CPU can not perform an ALU operation on 2 registers (a case where a 16bit ALU could be of use on an 8 bit bus). Plus, all those rep #$30, sep #$30 (to set/reset 16bit registers) are really annoying, which makes it almost impossible to write a decent disassembler.

 

The only way to achieve smooth games is to use the DMA controller whenever possible, to transfer graphics.

Edited August 31, 2008 by Vigo

[Gorf]

You mean "quality" as in "graphics capability" or the artefacts of the composite video output?

 

What I mean is what my eyes see on the TV when I play.

 

 

The SNES is another quirky architecture. Great effects (I just LOVE the color add/subtract modes), really advanced sound, but a pain-in-the-ass CPU, which is simply too slow to handle all the advanced stuff the graphics are capable of. The 65816 is not really a full 16bit CPU. I've been told it has in fact a 16bit ALU, but I simply don't understand for what, since it has an 8 bit data bus (an opcode like adc #$1234 takes 3 bus fetches, so the first result of the addition can be computed while the high byte of the argument is fetched), and the CPU can not perform an ALU operation on 2 registers (a case where a 16bit ALU could be of use on an 8 bit bus). Plus, all those rep #$30, sep #$30 (to set/reset 16bit registers) are really annoying, which makes it almost impossible to write a decent disassembler.

 

The only way to achieve smooth games is to use the DMA controller whenever possible, to transfer graphics.

 

 

I never liked the idea that Nintendo used a 65816( a 6502 with a few added 16 bit instructions for all practical purposes.)

I think the 68k would have been a much better choice and then they could have trully called the SNES a 16 bit system in

their marketing 'ploys'. I don't necessarily consider the SNES and 65816(from what I understand about it) a 16 bit

SYSTEM.....CPU...maybe....but like you say the bus is 8 bits data. I think they used this just to be different than Sega.

Nintendo seems to go out of there way to be different....which is not always a bad thing.

 

I feel the same about the 8088...yeah it has 16 bit instructions but the multiplexed 8 bit data bus kinda makes the 16 bits

moot. If only the IBM enginneers were listened to...our PC's would at least be 68k based ones.....a much better CPU line

than the Intel line it and WE were eventually cursed with.

 

IF only the ST/TT line did better in the market... I'd have loved a TT with a 68060...or even by now possibly a PPC.

[Vigo]

I never liked the idea that Nintendo used a 65816( a 6502 with a few added 16 bit instructions for all practical purposes.)

I think the 68k would have been a much better choice and then they could have trully called the SNES a 16 bit system in

their marketing 'ploys'.

 

The 65816 is probably a relic from the time when the SNES was supposed to be NES compatible. If you compare the register spaces between the SNES & NES, while not compatible, they are identical ($2xxx & $4xxx), another hint at the intended backward compatibility. Plus, the 65816 is a much smaller design than the 68000, they tried to save cost by integrating all components into as few chips as possible.

 

I don't necessarily consider the SNES and 65816(from what I understand about it) a 16 bit

SYSTEM.....CPU...maybe....but like you say the bus is 8 bits data

 

If the 65816 has a 16bit ALU, it is by definition a 16bit CPU, although I kind of doubt it is actually the case. The CPU bus of the SNES is 8 bits, but the graphics bus of the SNES is actually 16bits (the 64K VRAM is connected to both PPU's via a 16bit bus).

 

. I think they used this just to be different than Sega.

Nintendo seems to go out of there way to be different....which is not always a bad thing.

 

They did it because they wanted the SNES architecture to closely resemble the NES architecture. Otherwise, SNES & Genesis have more similarities than you might think. Both have a dedicated sound CPU and both have seperate CPU & video buses, unlike unified memory architectures. They both access VRAM by writing/reading an access port.

 

The only saving grace of the SNES are the sound & graphics and if you know where the weak spots of the design are, and design your game around it, you can achieve actuelly achieve great looking and sounding results. Just compare the horrendous slow "Super R-Type" with the magnificient "R-Type 3".

 

I feel the same about the 8088...yeah it has 16 bit instructions but the multiplexed 8 bit data bus kinda makes the 16 bits

moot.

 

The 8088 was meant to be a low-cost version of the 8086, which has a full 16bit data bus. The key word is compatibility, not speed or elegance.

 

If only the IBM enginneers were listened to...our PC's would at least be 68k based ones.....a much better CPU line

than the Intel line it and WE were eventually cursed with.

 

The problem was that at the time of the PC's introduction (1981), the 68000 wasn't readily available from Motorola and it was expensive. But otherwise, I couldn't agree with you more... When I was 15, I coded a Commodore 16 emulator for MS-DOS in x86 assembly language together with my friend, using the good old TASM. And it was always like: I want my Amiga back! So few registers, and the Real Mode addressing model... Eugh!

 

IF only the ST/TT line did better in the market... I'd have loved a TT with a 68060...or even by now possibly a PPC.

 

There was a 68060 card available for the Falcon. I personally own an Amiga 1200 with 68060/PPC accelerator. I wish I would stumble upon a Falcon one day, it's the only Atari from the ST series which interests me.

Edited August 31, 2008 by Vigo

[malducci]

I don't necessarily consider the SNES and 65816(from what I understand about it) a 16 bit

SYSTEM.....CPU...maybe....but like you say the bus is 8 bits data.

 

That's the first I've ever seen anyone have that opinion about the SNES. Regardless of its bus, it definitely has a 16bit ALU.

 

What really hurts the SNES is that WRAM (work ram) has wait states that bring the overall speed down. Even when in 3.57mhz mode. WRAM is 8 *master* cycles for the memory fetch/write part of the opcode if in WRAM, instead of 6. The 8bit bus isn't so much a hindrance as is the clock speed. It should have been 7.16mhz (which is faster than the 68k @ 7.16mhz - IMO).

 

16bit is somewhat of a generic term for consoles. Generally, it more pertains to the 'prowess' of the graphics capabilities The PCE/SGX are regarded as 16bit consoles because of their graphic processors, when they in fact have an 8bit CPU (8bit ALU, 21bit BUS). The SGX has two 16bit graphic processors. If I remember correctly, the VDP in the Genesis/Megadrive is actually an 8bit IC internally. Not that it really matters, they're all more or less a 'state machine' than a processor.

 

 

Another reason probably why the SNES didn't use a 68000 is that they were still expensive back then. And Motorola didn't license its 68k core for custom packages like WDC did at the time ('88-89)

 

However, it was still faster than competing 8-bit microprocessors, because the 68008's internal architecture was more powerful and efficient.

Gotta love wiki The 8bit bus *really* hurts cycle times of the 68k instruction set, as if they weren't slow already. Maybe faster than the z80 or 8080 <_<;

Edited August 31, 2008 by malducci

[Gorf]

The 65816 is probably a relic from the time when the SNES was supposed to be NES compatible. If you compare the register spaces between the SNES & NES, while not compatible, they are identical ($2xxx & $4xxx), another hint at the intended backward compatibility. Plus, the 65816 is a much smaller design than the 68000, they tried to save cost by integrating all components into as few chips as possible.

 

IT was still a pretty impressive machine. The availability of a 68k was probably along side cost.

If I remember, it was a pretty expensive chip, where the 65816 was probably much cheaper at

the time and was similar to the NES 6502, probably with the thought of making code easier to port.

 

If the 65816 has a 16bit ALU, it is by definition a 16bit CPU, although I kind of doubt it is actually the case. The CPU bus of the SNES is 8 bits, but the graphics bus of the SNES is actually 16bits (the 64K VRAM is connected to both PPU's via a 16bit bus).

 

I looked at the 65816 back in the day but don't remember enough about its design. I do remember

I was not overly impressed. I'd have rather had a straight up 6502 with a wider address range and

obviously an extended address register.

 

They did it because they wanted the SNES architecture to closely resemble the NES architecture. Otherwise, SNES & Genesis have more similarities than you might think. Both have a dedicated sound CPU and both have seperate CPU & video buses, unlike unified memory architectures. They both access VRAM by writing/reading an access port.

 

Yeah I never liked the port written VRAM writes/reads. Just let me straight at the vid memory.

I suppose that's from being an Atari 8 bit'er and a vic-20'er....I then went on to learn Z-80

on the Astrocade, ZX81 and the Mattel Aquarius...I think I wrote one small test prog on the

Aquarius and realized that at even the 30 or so bucks I paid for it, it was'nt worth it.

 

So I went and got a Timex/Sinclair 2068...not a whole lot better but at leat the graphics

were a bit more interesting and hi res....I was a sucker for the z80 machines. All those

extra registers were wonderful. No wonder why I like the J-RISC's so much....it seems like

there isn't enough registers sometimes...even with the two x 32 banks. The stall issues

make all those registers come in handy to avoid stalls AMAP.

 

The only saving grace of the SNES are the sound & graphics and if you know where the weak spots of the design are, and design your game around it, you can achieve actuelly achieve great looking and sounding results. Just compare the horrendous slow "Super R-Type" with the magnificient "R-Type 3".

 

Yeah you can definitely see an improvement between the two...man that was many moons ago since I

got my ass handed to me in those games.

 

The 8088 was meant to be a low-cost version of the 8086, which has a full 16bit data bus. The key word is compatibility, not speed or elegance.

 

I believe the whole Intel line before the 8086 was intended for motor control or other such small

devices. 8086....Segmented memory? Yikes!

 

 

The problem was that at the time of the PC's introduction (1981), the 68000 wasn't readily available from Motorola and it was expensive. But otherwise, I couldn't agree with you more... When I was 15, I coded a Commodore 16 emulator for MS-DOS in x86 assembly language together with my friend, using the good old TASM. And it was always like: I want my Amiga back! So few registers, and the Real Mode addressing model... Eugh!

 

 

Yeah well that and I think also because Gates had DOS ready to go ( you know, the sad excuse of a wannabe

CP/M) for the 8088 so IBM, who could have waited a few more years to enter the PC market, went ahead with

it....we are cursed to this day with probably the worst line of OS's ever marketed, WinDOS.

 

My ST line of machines crashed becasue I coded it wrong...usually it never crashed....once in a very rare

while, maybe.

 

There was a 68060 card available for the Falcon. I personally own an Amiga 1200 with 68060/PPC accelerator. I wish I would stumble upon a Falcon one day, it's the only Atari from the ST series which interests me.

 

 

Yeah I know about the accelorators but a machine in either line with the 060 as the CPU would have rocked.

 

Me and Scott were toying around with buying up a couple surplus 060's and hooking them up to a Tom&Jerry,

IDE and 8megs of ram......unfortunately its hard to get him to do anything anymore..... his new job has pretty

much sealed any Jag games or other platforms fate of not getting done. He was the tech coder. Im the AI

and game logic coder....I used to do my own tech coding...probably high time to get back to it.

[malducci]

I looked at the 65816 back in the day but don't remember enough about its design. I do remember

I was not overly impressed. I'd have rather had a straight up 6502 with a wider address range and

obviously an extended address register.

 

6502? Or do you mean 65c02? The 65816 can drop down in and out of 8bit register at anytime. You can make some optimization routines for this too. My only thing with the SNES version of the 65816 is that it's missing the added instructions that Rockwell defined for the 65CS02. WDC later added these in. The 65816 has a 16megabyte address range, though. It's segmented similar to the x86, but perfect for games.

 

Super R-Type is an example of bad coding, while Super Darius Twin and other shooters are better examples of knowing how to code for the cpu.

 

For homebrew, the SNES makes for a perfect setup. There's nothing more fun than pushing a system to it's max, that people believed otherwise wasn't possible. In case of the SNES, that would be speed.

[Vigo]

I don't necessarily consider the SNES and 65816(from what I understand about it) a 16 bit

SYSTEM.....CPU...maybe....but like you say the bus is 8 bits data.

 

That's the first I've ever seen anyone have that opinion about the SNES. Regardless of its bus, it definitely has a 16bit ALU.

 

Yes, you read everywhere that the 65816 has a 16bit ALU, but from an engineer's point of view, it doesn't make any sense, and I'll explain why:

 

Let's take any ALU opcode (EOR, AND, ORA...), i'll pick ADC #imm.

 

ADC #$1234

 

Decodes in 16bit mode as:

 

69 34 12

 

So due to its 8 bit bus, the 65816 needs 3 bus cycles to execute the opcode. With an 16bit ALU, you fetch the opcode, the 2 bytes of the argument and then perform the addition. Note that the 16bit ALU can only perform the operation after the high byte of the argument has been fetched.

 

With an 8 bit ALU however, you can first add the low byte of the argument in cycle 2 and then the high byte of the argument in cycle 3. Exactly as fast as a 16bit ALU.

 

There is NO case in the 65816 where a 16bit ALU is needed! Another example:

 

lda $1000,y :y is 16bit

 

1st cycle: fetch opcode

2nd cycle: fetch low byte of address, add low byte of y register using 8 bit ALU, save carry

3rd cycle: fetch high byte of address, add high byte of y register with carry using 8 bit ALU

 

Can all be accomplished using an 8bit ALU. So, why should I assume that the designers of the 65816 effectively wasted precious logic gates on the chip by implementing an 16bit ALU, which is always idle in 1 cycle?

 

Even the direct page registers indexed addressing modes add 1 cycle when the index register is 16bit.

 

Can you follow me?

 

What really hurts the SNES is that WRAM (work ram) has wait states that bring the overall speed down. Even when in 3.57mhz mode. WRAM is 8 *master* cycles for the memory fetch/write part of the opcode if in WRAM, instead of 6. The 8bit bus isn't so much a hindrance as is the clock speed. It should have been 7.16mhz (which is faster than the 68k @ 7.16mhz - IMO).

 

Yeah, I basically agree with you. Most problems of the SNES could have been fixed if the CPU would have been twice as fast. But I always thought that WRAM accesses take 6 master cycles, and that the 65816 is just halted the first few cycles per rasterline to refresh it.

 

16bit is somewhat of a generic term for consoles. Generally, it more pertains to the 'prowess' of the graphics capabilities The PCE/SGX are regarded as 16bit consoles because of their graphic processors, when they in fact have an 8bit CPU (8bit ALU, 21bit BUS).

 

21bit ADDRESS BUS. Normally, the generic term "bus size" refers to the data bus size. Otherwise, the 6502 would have a 16bit bus.

I would disagree that the PC-Engine is a 16bit machine for the same reasons I personally disagree the Jaguar is a 64bit machine. But let's not start the discussion again about that. I just brought it up to make the point here that I am consistent in my views (and have absolutely no grudges against the Jaguar), and if the 65816 would have an 8bit ALU, it would be a 8bit CPU, which would, from my view, again make the SNES an 8bit machine, no matter if the PPU's fetch 16bit of graphics.

 

Note again: bitness != power of machine!

 

The SGX has two 16bit graphic processors. If I remember correctly, the VDP in the Genesis/Megadrive is actually an 8bit IC internally.

 

No, it has a 16bit data bus, sorry.

 

Not that it really matters, they're all more or less a 'state machine' than a processor.

 

A CPU is also a state machine. For something to be worthy of being rated as a CPU, it must:

 

1. Being able to execute programs.

2. Be Turing complete.

 

Another reason probably why the SNES didn't use a 68000 is that they were still expensive back then.

 

Yes, plus they take much more logic than the 65816. Remember that the 65816 is integrated into the SNES chipset. The chip which contains the SNES CPU also contains other elements like the DMA engine.

 

And Motorola didn't license its 68k core for custom packages like WDC did at the time ('88-89)

 

Another point.

 

However, it was still faster than competing 8-bit microprocessors, because the 68008's internal architecture was more powerful and efficient.

Gotta love wiki The 8bit bus *really* hurts cycle times of the 68k instruction set, as if they weren't slow already. Maybe faster than the z80 or 8080 <_<;

 

And here, I agree with you, too. The fact that all 68k instructions are encoded in 16bits is another negative factor. It would perform better than a Z80, but the 6502 could be faster in many cases than the 68008.

[Vigo]

I looked at the 65816 back in the day but don't remember enough about its design. I do remember

I was not overly impressed. I'd have rather had a straight up 6502 with a wider address range and

obviously an extended address register.

 

Like malducci said, you can switch the accumulator or the index registers of the 65816 to 8bit or 16bit using the rep & sep commands. The 65816 also adds 24bit addressing space, which is kind of segmented, but can also be accessed in a linear fashion using 24bit addressing modes (lda $123456, jmp $123456).

 

Yeah I never liked the port written VRAM writes/reads. Just let me straight at the vid memory.

I suppose that's from being an Atari 8 bit'er and a vic-20'er....I then went on to learn Z-80

on the Astrocade, ZX81 and the Mattel Aquarius...I think I wrote one small test prog on the

Aquarius and realized that at even the 30 or so bucks I paid for it, it was'nt worth it.

 

It has some benefits. During active display, the graphics chip can access ALL memory cycles for gfx fetches without stopping the CPU, which runs in parallel on its own bus. The disadvantage is, VRAM access only in the VBLANKS (except the Pc-Engine).

 

I don't know much about the aquarius, I also come from machines which have unified memory architecture (C64, Amiga). I can however, understand why many console designers preferred the external VRAM bus design of the 9918. They just have to cope with the question: how much time should the CPU spend on game logic and graphics manipulation? How should it be divided?

 

The only saving grace of the SNES are the sound & graphics and if you know where the weak spots of the design are, and design your game around it, you can achieve actuelly achieve great looking and sounding results. Just compare the horrendous slow "Super R-Type" with the magnificient "R-Type 3".

 

Yeah you can definitely see an improvement between the two...man that was many moons ago since I

got my ass handed to me in those games.

 

I think R-Type 3 holds up quite well, one last breath of excellence from IREM. (I am right they went bankrup after R-Type 3?) My guilty pleasure on the SNES is also Parodius...

 

I believe the whole Intel line before the 8086 was intended for motor control or other such small

devices. 8086....Segmented memory? Yikes!

 

Intel at first never gave the CPU business much attention, that's why Frederico Faggin, the main designer of the 4004,8008 & 8080 started his own company Zilog and worked the 8080 design into the Z80, and designed one of the most succesful CPU architectures in history. The 8086 is a very unimpressive design compared to other 16bit architectures like the 68000. Intel never saw the 8086 as their main market (that changed only later with the success of the IBM PC), their main target at the time was the unsuccesful i432 architecture, a heavily microcoded cisc cpu design:

 

http://en.wikipedia.org/wiki/Intel_iAPX_432

 

Yeah well that and I think also because Gates had DOS ready to go ( you know, the sad excuse of a wannabe

CP/M) for the 8088 so IBM, who could have waited a few more years to enter the PC market, went ahead with

it....we are cursed to this day with probably the worst line of OS's ever marketed, WinDOS.

 

MS-DOS, the CP/M rip-off. I know that there was a version for the 68k, but I am unsure when it was released. It would have been an interesting question what OS IBM would have used if they took the 68000.

 

My ST line of machines crashed becasue I coded it wrong...usually it never crashed....once in a very rare

while, maybe.

 

On the Amiga, it depends on the Operating System version. Everything below 2.0 is VERY buggy & unstable, but from 2.0 on, it is a truly great OS for its time. But on the other hand, for a long time, the Amiga was much more expensive than the ST.

 

Yeah I know about the accelorators but a machine in either line with the 060 as the CPU would have rocked.

 

The 060 has a slight advantage over the Pentium 1 in integer performance. I really wished Motorola would have continued the design. Yeah, okay, there is the Coldfire, but it isn't fully binary compatible to the 68k architecture. And the death knell for ever writing a fast library which emulates the missing 68k instructions,providing 100% compatibility, is the fact that 1 quite important instruction uses the same opcode, but behaves differently, so you can not trap it with an exception handler. I have to look up again what instruction that was...

 

Me and Scott were toying around with buying up a couple surplus 060's and hooking them up to a Tom&Jerry,

IDE and 8megs of ram......

 

The more interesting question is: where do you get Tom & Jerry chips?

 

unfortunately its hard to get him to do anything anymore..... his new job has pretty

much sealed any Jag games or other platforms fate of not getting done. He was the tech coder. Im the AI

and game logic coder....I used to do my own tech coding...probably high time to get back to it.

 

Too bad, because it sounds quite interesting. I think Atari used a MIPS R3000 CPU in the Cojag arcade system based on the Tom & Jerry chipset.

Edited August 31, 2008 by Vigo

[+MattelAquarius]

....I then went on to learn Z-80 on the Astrocade, ZX81 and the Mattel Aquarius...I think I wrote one small test prog on the

Aquarius and realized that at even the 30 or so bucks I paid for it, it was'nt worth it.

 

 

Please see my response here.

[Artlover]

Aquarius

Isn't that a tank people keep fish in?

[+MattelAquarius]

Aquarius

Isn't that a tank people keep fish in?

 

 

If there was an emoticon for anguish, it would appear here --->

[malducci]

Yeah, technically the PCE and SGX are not 16bit in CPU bitness, but that's not what the term really signifies. At least for consoles. A 16bit system signifies the era/generation the system belongs to - because of it's abilities. At least here in the States. NES/SMS belonged to the 8bit generation, the PCE/SNES/GEN belonged to the 16bit generation. For the Jaguar - it would be in the 32bit system from the 32bit generation - 3DO, Jag, PS1, Saturn.

 

 

So due to its 8 bit bus, the 65816 needs 3 bus cycles to execute the opcode. With an 16bit ALU, you fetch the opcode, the 2 bytes of the argument and then perform the addition. Note that the 16bit ALU can only perform the operation after the high byte of the argument has been fetched.

 

Interesting. If the 65x had 16 bit support (with paired 8bit registers), it would be the same number of steps as the 65816 for ADC #$1234

 

cycle 1 fetch opcode

cycle 2 fetch operand

cycle 3 perform operation / fetch operand

cycle 4 perform operation and fetch next opcode

 

But your forgetting INC. If we apply the rule that the 65x and 65816 can do one ALU operation and memory fetch in one cycle, then INC A would be 3 cycles on the 65816. But it is in fact 2 cycles on the 65816 in 16bit mode.

 

I wouldn't doubt that the 65816 might have chained 8bit ALUs, but that's essentially the same as a single 16bit ALU. (They work together in a single cycle). That would make dropping down into 8bit mode much less work on the architecture side. I believe the original z80 (or was it 8080) had chained 4bit ALUs.

 

 

No, it has a 16bit data bus, sorry.

 

Nope - it's a byte size bus. You can write a word and it will count as two bytes. Set the incrementor to something other than 1 and write a word. The upper half of the word will be n amount of bytes from the lower half. The VRAM 'address' is byte based as well.

Edited September 1, 2008 by malducci

[Vigo]

Yeah, technically the PCE and SGX are not 16bit in CPU bitness, but that's not what the term really signifies. At least for consoles. A 16bit system signifies the era/generation the system belongs to - because of it's abilities.

 

That may work for console magazine readers, but it doesn't work for me, and it is not really correct to misuse this term that way. Gamers should always look at the games, and not argue or measure with something they do not understand. Note: I wasn't implying you belong to this group, quite contrary.

 

At least here in the States. NES/SMS belonged to the 8bit generation, the PCE/SNES/GEN belonged to the 16bit generation. For the Jaguar - it would be in the 32bit system from the 32bit generation - 3DO, Jag, PS1, Saturn.

 

And where does the Dreamcast & PS2 belong to?

 

But your forgetting INC. If we apply the rule that the 65x and 65816 can do one ALU operation and memory fetch in one cycle, then INC A would be 3 cycles on the 65816. But it is in fact 2 cycles on the 65816 in 16bit mode.

 

Good thought, but I have an explanation for that.

 

An increment operation doesn't need an ALU, because you can achieve it by simply toggling the flipflops based on the state of the previous bits.

 

Let's take the program counter (PC). It doesn't need the ALU to increment itself because of the reason I posted above (otherwise, the 6502 would not be as cycle efficient as it is). It has 2 functions: increment & load. On the 6502, page boundaries take 1 additional cycle, on the 65c02 this does not apply. They probably did this in the 6502 to make the incrementing logic smaller.

 

But anyway, as the PC is implemented this way, the A, X, Y registers are probably implemented the same way. They can load a value and increment/decrement themselves. From a design point of view, 6 simple increment/decrement commands (INC A, DEC A, INX, DEX, INY, DEY) do not warrant a fully fledged 16bit ALU with all kinds of operations (ADC, SBC, AND, OR, EOR...). 1 of the main goals of designing chip designs is: make them small and efficient. That's why for example, the Atari engineers implemented almost every counter in the 2600 using LSFR's.

 

I wouldn't doubt that the 65816 might have chained 8bit ALUs, but that's essentially the same as a single 16bit ALU.

 

What I proposed is not 2 chained 8 bit ALUs, but just one single 8 bit ALU with 2 multiplexers connecting all 8bit portions to the ALU. You only need to save the carry for a full 16bit add/sub operation on 2 cycles.

 

(They work together in a single cycle). That would make dropping down into 8bit mode much less work on the architecture side.

 

If it has a 16bit ALU, it would certainly be divided into 2x8 bit parts. But I really doubt it because it doesn\\\'t make sense to me to waste that amount of logic.

 

I believe the original z80 (or was it 8080) had chained 4bit ALUs.

 

As far as I know, it also has 1 single 4bit ALU, which makes sense considering the Z80 takes 2 cycles between memory fetches.

 

Nope - it\'s a byte size bus. You can write a word and it will count as two bytes. Set the incrementor to something other than 1 and write a word. The upper half of the word will be n amount of bytes from the lower half. The VRAM 'address' is byte based as well.

 

Both VDP's connect to the memory via a 16bit DRAM data bus, 7 bit multiplexed DRAM address bus (315-5309) and a 24bit unmultiplexed address bus (315-5364). It is a full 16bit system.

 

Check it out yourself:

 

http://www.emu-docs.org/Genesis/mega1.png

 

Referred in the schematics as "V ADDRESS" and "V DATA"

Edited September 1, 2008 by Vigo

[malducci]

Both VDP's connect to the memory via a 16bit DRAM data bus, 7 bit multiplexed DRAM address bus (315-5309) and a 24bit unmultiplexed address bus (315-5364). It is a full 16bit system.

 

http://cgfm2.emuviews.com/txt/vdppin.txt

 

It has an 8bit data bus connected to 'vram' 64kx8 memory interface (two 64kx4). Not sure what you mean by "Both VDP's". There's only one VDP (video display processor) in the genesis.

 

That may work for console magazine readers, but it doesn't work for me, and it is not really correct to misuse this term that way. Gamers should always look at the games, and not argue or measure with something they do not understand. Note: I wasn't implying you belong to this group, quite contrary.

 

It isn't a misuse of the term. It was term used to separate and define the newer generation from the previous one - the speed of the system in general. It's just that, a term. Same with '16bit graphics'. On a PC is refers to bits per pixel, on a console it's generic and has a broad specification. If we were to be too strict, then the Colecovision is a 16bit console. And you know that doesn't fit. Then you have to start adding exceptions -blah blah blah. The PCE has 8bit CPU but two 16bit graphic chips (4 for SGX since it has another VDC and a 16bit VPC priority mixer). How does that fit in? That's the problem with using the term '16bit' and '8bit' specifically/narrowly.

Edited September 1, 2008 by malducci

[Vigo]

My fault, I looked at the wrong schematics. Here are the right ones:

 

http://www.emu-docs.org/Genesis/mega2.png

 

The Genesis does indeed only have an 8bit graphics bus. Thank you for pointing me to that information!

Edited September 1, 2008 by Vigo

[Vigo]

There is something fishy with those DRAM's... The "AD" pins on the VDP are connected to the address pins of the DRAM, but also to a mysterious 4 bit port (marked I/O), right next to the data port. I have a feeling that this address bus is multiplexed several times... I'll continue my research.

 

Ah, now I understand, it's a dual port VRAM not a standard single port DRAM. That's why they only used an 8 bit data port, because this ram can be read-out very fast (30ns)

Edited September 1, 2008 by Vigo

[Gorf]

I don't know much about the aquarius,

 

You not missing much either. Im mean it was 'cute' and a simple way for someone to get around a simple machine

but I still liked my zx81 better...talk about a challenge.

 

I think R-Type 3 holds up quite well, one last breath of excellence from IREM. (I am right they went bankrup after R-Type 3?) My guilty pleasure on the SNES is also Parodius...

 

Paroduis...I think I rented that one....side scroller/shooter as well?

I used my SNES for a few months then the Jag was released. I gave

my entire NES collection to my niece As she was a big NES fan. The

SNES was stuff away to make room for the Jag stuff.

 

Intel at first never gave the CPU business much attention, that's why Frederico Faggin, the main designer of the 4004,8008 & 8080 started his own company Zilog and worked the 8080 design into the Z80, and designed one of the most succesful CPU architectures in history. The 8086 is a very unimpressive design compared to other 16bit architectures like the 68000. Intel never saw the 8086 as their main market (that changed only later with the success of the IBM PC), their main target at the time was the unsuccesful i432 architecture, a heavily microcoded cisc cpu design:

 

I was disappointed when I looked at the intel chip specs...I was far more impressed with the 6502

and Z80.

 

MS-DOS, the CP/M rip-off. I know that there was a version for the 68k, but I am unsure when it was released. It would have been an interesting question what OS IBM would have used if they took the 68000.

 

I think they were foolish not to go with the 68k and CP/M68. It would not have mattered

what chip they used...as IBM was the only thing people needed to hear at the time.

However, I think they should have done us all a favor and stuck to mainframes.

 

On the Amiga, it depends on the Operating System version. Everything below 2.0 is VERY buggy & unstable, but from 2.0 on, it is a truly great OS for its time. But on the other hand, for a long time, the Amiga was much more expensive than the ST.

 

The few things that kept me from getting the Amiga was its cost and the ST had Midi ports out of the box.

Musician sold! I had TOS 1.5 for a while which severd me well. I eventually upgraded to 2 dot something.

 

which emulates the missing 68k instructions,providing 100% compatibility,

 

Yeah we also looked at the Coldfire. All the builtin communications and peripherals

would have made needing to use the emulation worth it. The one chip we were looking

at was like 204 MIPS. Lots of timing to think about. Nightmare even.

 

The more interesting question is: where do you get Tom & Jerry chips?

 

I think it was Best that had T&J chipsets....knowing a few SMT masters dont

hurt either. I used to work at a electronic medical device manufacturer and

the SMT people there did not need SMT solder stations. They were petty

amazing with a small tip solder pencil and a microscope.

 

Too bad, because it sounds quite interesting. I think Atari used a MIPS R3000 CPU in the Cojag arcade system based on the Tom & Jerry chipset.

 

They used the 68EC020 and later on replaced those with the MIPS R1000/3000.

Then we also have the nets to Tom and Jerry if we really wanted to go crazy.

Some one has been converting the nets to FPGA...actualy he was working

on the Oberon chip, the new Tom for Jag II....Puck never got coded.

 

The new Jerry(Puck) was to have an RGPU, which was another J-RISC

Core with its own internal Cache that would be used instead of the 68k

in newly designed Jag II games.

 

One of these days I want to get me an Area 51 boardset. I really

dont want the whole machine though.

[+MattelAquarius]

I don't know much about the aquarius,

 

You're not missing much either. I mean it was 'cute' and a simple way for someone to get around a simple machine

but I still liked my zx81 better...talk about a challenge.

 

 

 

This obvious insult gets a pass, because you acknowledge the renowned cute qualities of the machine. Its placid blue keys lay out before the user like tranquil ripples radiating across a blue tropical lagoon. And they're small and rubbery. The keys gently squish beneath the press of your finger, like a satisfying poke into the belly of the Pillsbury Doughboy. "Hoo hoo," indeed.

 

However, you should know that velvet daggers are not beyond the detection of THIS Aquarius guardian.

[Gorf]

I stand by my previous statements and offer NO appologies.

 

I do still OWN my MA, BTW.

[Gorf]

My fault, I looked at the wrong schematics. Here are the right ones:

 

http://www.emu-docs.org/Genesis/mega2.png

 

The Genesis does indeed only have an 8bit graphics bus. Thank you for pointing me to that information!

 

 

Was the 68k in the Genny a 68008?(An 8 bit data bus?)

I dont remember.

Edited September 3, 2008 by Gorf

[+MattelAquarius]

I stand by my previous statements and offer NO appologies.

 

I do still OWN my MA, BTW.

 

 

Your lack of compassion fills me with immense sorrow. I beg you to soften your heart and cast off the bonds of prejudice and intolerance. Come now, it won't hurt. Look at your Aquarius. Take it up into your arms and gaze upon it without malice. Allow the smile to naturally take form upon your jaded and world weary face. The heretofore unloved Aquarius will win your heart, sir. This I know to be true. You can now be born anew in its splendor. Use it. Code it. Take good care of your Aquarius, and in return, it will give you decades of blissful happiness.

 

 

If one thing is clear after these Aquarius intervention posts, it is that we all may have some serious soul searching to do. Let us endeavor to not let hate permeate within us.

 

Let the healing begin.

[CV Gus]

Actually, Vigo, you just cannot expalin things properly, and you are just too arrogant to admit when you do not know something. You can babble all you want, but you just don't know. And judging how quickly you gave up on 7800 programming, you'll never know. I read your threads, and gave up trying to sort useful info from drivel. Note how that programmer I contacted not only knows more than you do, but how to expalin it. So he has you beat on two counts right there.

 

Note that I had the good taste not to send that pregrammer cyber-copies of your posts. Maybe I should have- he could no doubt use a good laugh.

 

A comparison of specs- along with a brief explanation of what's what- would give one a decent idea of what each can do. For example, in the case of the 5200, it could show 200(V)X320(H) and 256 colors- but it would have to be mentioned that it cannot do both at the same time. For example, what resolution can it show at least 16 colors?

[malducci]

200(V)X320(H)

 

I'd still like to know the source of representing resolution like that. I don't think I've ever seen it like that officially (manuals, docs, patents, etc).