Md 68k and hu6280 comparison

[touko]

Hi all, i have this in mind for a while ..

How 6280 can compete with Md 68k in performance ???
Of course in case of video game consoles, not in general use(like a computer) .

It seems that in bloc transfert ,the 68k is more capable (with more code of course) ..

[Arkhan Asylum]

The 68k is more capable in that it's easier to code for, is completely C friendly, has more options, is actually 16 bit, and is faster.

but, the CPU alone doesn't make the games.   Graphics/Sound hardware comes into play.


That's why the PCE competes with the Genesis.  The color options for the Genesis just blow.

[touko]

The 68k is more capable in that it's easier to code for, is completely C friendly, has more options, is actually 16 bit, and is faster but the CPU alone doesn't make the games. Graphics/Sound hardware comes into play.

That's why the PCE competes with the Genesis. The color options for the Genesis just blow.

Yes of course, MD is limited by his 4 sub palettes, but his VPC is better than VDC in many points like :
DMA, sprites/scanline (in h40 mode), number of sprites (also in H40 mode),and you can also use the Z80 in complement..

But my questions are especially on game logic ..
IMO i think in this area,the 6280 can compete easily, but i don't know the 68k enough ..

[Arkhan Asylum]

But my questions are especially on game logic ..
IMO i think in this area,the 6280 can compete easily, but i don't know the 68k enough ..

The 68k has a faster speed, and it's actually 16 bit, with more registers (unless you want to split hairs with the zero page shit on the 6502).   Plus the instruction set is nicer than the 6502 and allows for less brain damaged coding, IMHO.  

but, game logic speed alone is a bad comparison, as the CPU is also running the rest of the system.  Even if it's faster, there are other things to consider.

the 68k is a higher end CPU in general.  It's better.  

EDIT: Just realized Md = Megadrive.  I was reading that as M as in Motorola.   Even so, the MD is still (slightly) faster than the PCE, and the code for game logic will likely execute faster because of the above stuff I just said.

[touko]

But my questions are especially on game logic ..
IMO i think in this area,the 6280 can compete easily, but i don't know the 68k enough ..

The 68k has a faster speed, and it's actually 16 bit, with more registers (unless you want to split hairs with the zero page shit on the 6502).   Plus the instruction set is nicer than the 6502 and allows for less brain damaged coding, IMHO. 

but, game logic speed alone is a bad comparison, as the CPU is also running the rest of the system.  Even if it's faster, there are other things to consider.

the 68k is a higher end CPU in general.  It's better. 

EDIT: Just realized Md = Megadrive.  I was reading that as M as in Motorola.   Even so, the MD is still (slightly) faster than the PCE, and the code for game logic will likely execute faster because of the above stuff I just said.

Thank you for the answer, and lol, yes Md is for megadrive, and i have forgot that it's genesis in us  ..

I asked this, because i thought the cycles/instruction was low compared to 6280, some instructions very used in a game like conditional tests, jump to subroutine, interruptions , and many others are faster on 6280 ..
in addition if we take into account than work in byte is in many, many case faster than word,with faster ram acces ..

And do you think that gunstar hero push more on screen than sgx version of 1941 ???

[Arkhan Asylum]

I would say Gunstar Heroes is probably busier than 1941.

It's also a better game.

[touko]

I would say Gunstar Heroes is probably busier than 1941. It's also a better game.

Yes in fun area 1941 is a little boring, but it seemed more animated, with more different sprites on screen.

maybe i was wrong..

1941 has more sprites, but it's generally less busy. Gunstar has all kinds of crap going on. It's hard to say though because they are two different types of games.

[Arkhan Asylum]

1941 has more sprites, but it's generally less busy.  Gunstar has all kinds of crap going on.


It's hard to say though because they are two different types of games.

[turbokon]

You guys are speaking a whole different language then what I can understand:)

[spenoza]

If you are willing to go the assembly route hard-core, the zero page on the 6280 is what makes the CPU. That and low wait states for memory.

[Arkhan Asylum]

If you are willing to go the assembly route hard-core, the zero page on the 6280 is what makes the CPU. That and low wait states for memory.

the zero page is also a bit braindamaged.  I'd still say the 68k is faster and more flexible.

[Tatsujin]

Doesn't have the Pce an all around higher mips counr than the MD has?
Sure that tells shit in the end about the actuall screen output.

[soop]

The 68000 was the best thing Motorola ever did.  They should have stuck to that instead of making shitty cellphones.

[touko]

The 68k is designed for workstations, this is why for exemple an interupt take 44 cycles, vs 8 for 6280 .
A jsr/rts take 32 cycles  vs 15 for 6280 ..
They are many exemples like that, and these instructions are widely used in a game .

In fact i think everything is balanced between these two CPU .

[TurboXray]

Hi all, i have this in mind for a while ..

How 6280 can compete with Md 68k in performance ???
Of course in case of video game consoles, not in general use(like a computer) .

It seems that in bloc transfert ,the 68k is more capable (with more code of course) ..

The 68k (the original 68000) processor is pretty slow. That is to say, the instruction cycle times are fairly lengthy. But it was the original; the very first model (1980 IIRC). From an hardware engineering perspective, it's a 16bit cpu (16bit ALU and hardware macro instructions, also microcoded). But a software engineering perspective, it's definitely a 32bit cpu. You have 32bit wide registers, you have opcodes read/write/modify 32bit wide data at a time, etc. The instruction cycle times are slow, but they're powerful at the same time. So it balances that out in general. Of all the old processors, the 68k reminds me a lot of the z80. Slower instruction times but a better ISA to compensate, hardware macro instructions (handling larger data element than the ALU size), doesn't hog the bus, etc.

 Anyway, the 68k is soooo easy so code for. I'd probably recommend it for a beginner cpu for anyone looking to learn Assembly language. It's almost retarded proof. The performance difference between unoptimized assembly code and optimized code, isn't that great - IMO. Not compared to processors based on the 65x or even just 8bit in general. That's a bonus. Of course larger registers, number of registers, and flat memory model make it perfect for compilers. Though I think you mean how they compare in just optimized performance, so I'm going to assuming this question is for Assembly and not C or other such languages.

 The 6280 is obviously based on and a branch of the 65xx processor. It's 2 revisions ahead and one branch off(6502->65c02->R65c02s \.. Huc6280). It's got some decent refinements. The 6280 (and 65x in general), shares some common design philosophies with RISC. Simple but fast instructions and hard wired VS microcoded. To do anything, you need to write quite a bit of code - compared to the 68k. Although that has more to do with date element sizes between the two. There's a up side and a downside to this. The up side is that you have a number of different approaches to optimizing your code because of the simpler instruction set. The downside is for the very same reason, optimization isn't so clear cut. Sure, you can do some basic rookie optimization, but I'm referring to the really crazing stuff (up to and including self modifying code). And there in lies another problem; convoluted code. Sure, it's fast but it's not very readable definitely very unflexible (complete re-write/re-design for small changes).

 Anyway, for all the advantages and luxuries the 68k has over the 6280 (flat memory model, larger register size, more data reigsters) - that means little when your optimization came down to small localized segments of code (usually less that 1k). Things that are looped hundreds or thousands at a time. That is where optimization matters and the 6280 can keep up with the 68k and even surpass it, if you're willing to write some crazy ass code. That said, I think in general, everyday, normal type of coding  - then the 68k is going to have an edge almost every time (i.e. Japanese developers really didn't optimize their code for speed. At least not from what I've seen personally, stepping through debuggers and not from what I've heard of other hackers doing NES stuffs). Great game design does not equate to efficient or optimized written code. Konami made some great games, but wrote some piss poor code.

 I've written quite a few code between the 68k and the 6280. I'm not sure I have much of it anymore, because it was really for my own curiosity. But here's a small segment that has seemed to survived: http://pastebin.com/f76e312e0 (top is 68k, middle is 6280, bottom is 65816)

 I had a discussion between Steve Snake and I, and a few others, about the 68k and 65816. The talk was about what processor could do what, better. The 6280 got an example or two, from a side discussion. In the end, the discussion only proved that really small examples out of context, really do nothing to prove or disprove the abilities of these processors over each other (the architectures are just so different). But in one example, I did prove that if you had put a 68k in the PCE - rather effects would take more cpu resource. The 68k has a very large cycle latency for interrupts (the base is 44 cycle + time to finish the instruction it's in the middle of) and RTI (hell, even RTS is slow). The 6280 is 7 cycle for the interrupt call (and must finish out the instruction, but 6280 instruction times are much smaller than 68k's) and RTI is faster too. And given the way the VDC in the pce works, you don't need to write a 16bit word to the VDC registers; they are buffer without a latch mechanism so you can update either lsb/msb at anytime. I used this on the 6280 code side to write some pretty fast code for a full screen/scanline hsync routine for both processors. 6280 came ahead with a pretty healthy lead. On the Genesis/MD, you don't use the hsync interrupt to do raster effects. There are tables in vram that you update during vblank. I can only assume because of this reason (VDP x and y must have a small timing window, since you can do column scrolling).

 A few pet peeves with the 68k; some instruction times are long. JSR and RTS both are much longer than they need to be. Indexing on the 68k isn't free like on the 6380/65x/'816. That means small fast LUTs aren't really worth it (for non linear table access). If I'm doing sequential memory access on the 68k, I just manually add the based address with the offset and do self increment or such. It's faster than indexing. Memory alignment for word and long word elements (most emulators don't care, but the deal machine will generate an internal interrupt to handle the exception). No speed benefit for using 8bit/byte size elements. I'd mention slow instruction cycle times, but the instructions themselves are usually pretty powerful, so that mostly balances out. For a processor that is register based, 7 address vectors/registers is not enough (one is reserved for the stack). I've even find myself running out of Data registers too, in some routines. Pushing and popping from the stack isn't a big deal, but for some reason I always hated having to do that (even way back when I started with x86 asm). A set of 16 and 16 would have been better.

 A few pet peeves with the 6280; wasted instructions. Clx, Cly, Cla. They save a byte, but are the exact same cycle length as simply ldx #$00, ldy #$00, lda #$00. Those instructions logic space could have been put to better use. No 16bit memory increment (would be nice for pointers, since ALL the address vectors are in ZP instead of internal register memory). No quick add; an inc by 2 and inc by 4 would be nice. And finally, at least 1 indirect long access port (self incrementing/decrementing). Not that you couldn't fix this by having it on cart or such (arcade card has four of these, at least for AC memory), but it would have been nice to have one in hardware. A few other small ones like inc A:X or such. SAX and SXY are almost useless because of the 3 cycle length. 2 cycle would made them more useful.

 Other than that, I really have no problems with the 6280. When I need clear looking code, I use my custom macros for non speed critical segments. Make the code easier to read and scroll though. I love that fact that all of ZP can be used for address vectors. Having up 128 address vectors is quite nice, although I only tend to reserve about 32 pairs of bytes for addressing. What does it matter if it's in ram or not? It's an instruction like any other address vector instruction. If you don't like numbers, give them register names with equates (I use R0-R7 and A0-A7 most of the time). Hell, I even use D0-D7 for ZP equates.


 On a related note I think the 6280 keeps up with the 68k, outside of optimization, because there isn't a real need for data elements larger than 8bit in game code. That is to say, there is a whole lot of bit testing, comparing, and branching that makes up a single frame/time slice (1/60th). The 68k receives no benefit from processing 8bit/byte wide data, but obviously the 6280 does. And so overall I think this is where you the two processors even out. Other things like adding/subbing an 8bit var to a 16bit data set, instead of 16bit<>16bit->16bit, also saves the 6280 some cycle time. The end result might need be 16bit/word based, but you save on cycles for working with an 8bit data against it.

[touko]

Wahou, very good analysis, i don't search a fight 68k vs 6280, i know that 68k is a great CPU, more flexible for multiples use than 6280, and for any one more easy to use ..
I have no problem with 6280 assembly now, and i like it ...
Of course i respect arkhan 's headaches with it ;-) ..

Tom i have already seen this interrupt code comparison on spritesmind, and I found it very interesting ..
IMO the huge interrupt cycles consumption justify the existence of the Md scroll table ..

your last sentence responds to my question, that 6280 can compète with Md 68K in game code ..
;-)

Thanks you all for trying to give me an answer.

[Arkhan Asylum]

I don't have an actual specifics, so I am speculating:

I would figure that if you're doing a lot of actual 16-bit operations, the 68k will out perform the 6280 because it's setup to do that better. 

but if you're doing a bunch of 8 bit crap, they will be roughly the same.   More so because the 6280 is superfast, compared to other 65xx variants.   Sort of like using a pickup truck to carry a carton of eggs home.  Works the same as a sedan.    Have fun getting a couch home in the sedan, though.



EDIT: Also, Tom posted while I had half this post typed and didn't finish.  He said something similar at the end.   68k doesn't benefit from processing 8 bit data.



However, depending what you are writing for a game, you will likely see >8 bit numbers in your game that you need to do things with. 

Also, doing a raw 68k vs 6280 comparison doesn't amount to much when you consider what really makes the system operate are the other chips/things that the system can use to facilitate things.

You also have to consider that the two CPUs have different instruction sets/styles, and should not be approached the same. 

If you make really contrived examples, you will probably find ways to say the 6280 is wildly faster.  But, it will be for some goofy example that isn't very practical in a game, anyway.

[touko]

I don't have an actual specifics, so I am speculating:

I would figure that if you're doing a lot of actual 16-bit operations, the 68k will out perform the 6280 because it's setup to do that better.

but if you're doing a bunch of 8 bit crap, they will be roughly the same.  More so because the 6280 is superfast, compared to other 65xx variants.  Sort of like using a pickup truck to carry a carton of eggs home. Works the same as a sedan.  Have fun getting a couch home in the sedan, though.

EDIT: Also, Tom posted while I had half this post typed and didn't finish. He said something similar at the end.  68k doesn't benefit from processing 8 bit data.

However, depending what you are writing for a game, you will likely see >8 bit numbers in your game that you need to do things with.

Also, doing a raw 68k vs 6280 comparison doesn't amount to much when you consider what really makes the system operate are the other chips/things that the system can use to facilitate things.

You also have to consider that the two CPUs have different instruction sets/styles, and should not be approached the same.

If you make really contrived examples, you will probably find ways to say the 6280 is wildly faster. But, it will be for some goofy example that isn't very practical in a game, anyway.

Psycho Arkhan you're right, i don't want a MD vs PCE, because like  you have already said, a game machine is not only a CPU, and i think also what MD is better in general ..

My goal would be to compare MD with SGX to be fair ..
I think Tom came to the same conclusion, that 6280 can compete with MD cpu even his higher frequency ..
obviously only in the case that concerns us: the game ..

And except sprite/line limit,i think, a game like gunstar hero is doable in term of sprites animation on PCE ..

[Arkhan Asylum]

even a straight 6280 vs 68k comparison isn't totally fair since the two aren't in the same league.  You'd be better off doing 65816 vs 68k, and watching the argument that ensues. 

[touko]

even a straight 6280 vs 68k comparison isn't totally fair since the two aren't in the same league. You'd be better off doing 65816 vs 68k, and watching the argument that ensues.

Of course Psycho Arkhan, but do you know a console with a 65C816 @7 mhz ?? 

[Arkhan Asylum]

Nope.  The 65816 blew. 

lol

[touko]

Nope. The 65816 blew. lol

LOL

[TurboXray]

Surprisingly, the 6280 can keep up with the 68k on quite a few 16bit stuffs. Sometimes coming very close to matching it, other times beating it. But like stated before, comparing snippets of code between these two processors isn't exactly representative; even simple addition comparisons.

 But here's one:

Code Select Expand

(68k)
move.w d0,abs.w ;12
add.w d0,abs.w ;16

28 cycles

(6280)
lda <$01 ;4
clc ;2
adc <$02 ;4
sta <$01 ;4
lda <$03 ;4
adc <$04 ;4
sta <$03 ;4.  24+2 = 26

 That's just a memory+memory->memory operation; 16bit+16bit->16bit. The 6280 beats it by 2 cycles. I used ZP on the 6280, but I also used the MD's fast access mode ram (top half of the 32k) for faster accessing too. Not exactly the same, but fairly close in principal (if you treat certain ZP variables as ram instead of data regs). If you have a matrix of variables that need to be added to a single value (say like moving a series of linked objects), the 6280 automatically gets free indexing and such. I had quite a few examples of 16bit operations, and even when the 6280 was slower cycle wise - it was still pretty close. And of course if the operation is 8bit+16bit->16bit instead of a full 16bit operation, the 6280 gets a nice little speed up there (a branch to skip on non overflow detection). This isn't to take away from the 68k's 16bit operationally ability (it can do quite a few fancy 16bit things), it's just to show that different between one being 8bit and the other being 16bit isn't as drastic as it seems.

 Of course if you design the game logic specifically around the 6280 strengths, it'll scream along no problem. The key is high level optimization in design along with low level optimizations. This might limit you in game design slightly, but the player/gamer will never know. The 68k is more flexible and robust overall, while the 6280 is extremely fast at more specific/narrow-focused designs.

[touko]

yeah i think so ..
I have a discussion about this with stef (the creator of gens), but he's too fanboy, nothing is better than MD and his CPU ..
Of course it's a great machine, and his VPC is very ,very, good ..

And I'm a little annoyed by this urban legend,where if a CPU is 16 bit, then it's alway better than a 8 bit .
I took as an example of a 256 bytes increment, a common use to increment a pattern on a 32*32 pixels sprite ,to show how fast the 6280 can be in 16 bit data processing using the 8 bit LSB/MSB feature ..
This kind of processing is very common in games of this era ..
i think also that 8 bit variables are the most common.

[Arkhan Asylum]

It's not that it's "better" speed wise. It's that it's more capable.   Like I said before, a truck and a car can both take some eggs home, but the car sure has problems getting a couch home...

It can do much more with itself than an 8-bit CPU.  Imagine if Amiga kept going with 6502 CPUs like what was in the C64.

The Amiga would've been a joke. 


For game consoles, the CPU almost barely matters in the end, because the other hardware decisions are what truly make or break the consoles.   

[HercTNT]

I'm just thrilled there is not a test on this later as my head exploded!! Frankly you guys could be BS'ing and i would have no idea LOL. For all i know you just described the processing power of a frosted flake when it interfaces with a bowl of milk

[spenoza]

For all i know you just described the processing power of a frosted flake when it interfaces with a bowl of milk

If someone designs a console I can eat for breakfast... I'll feel really bad for losing a console when I get hungry.

[touko]

It's not that it's "better" speed wise. It's that it's more capable.   Like I said before, a truck and a car can both take some eggs home, but the car sure has problems getting a couch home...

It can do much more with itself than an 8-bit CPU.  Imagine if Amiga kept going with 6502 CPUs like what was in the C64.

The Amiga would've been a joke.  

Yes of course, but you're taking extreme cases ..
68K is perfectly designed for a workstation, and of course is well suitable for a home computer, better than a 6280, in this case 6502 is out of competition .

For game consoles, the CPU almost barely matters in the end, because the other hardware decisions are what truly make or break the consoles.  

I agree with that, and how many people said "Snes has a crappy  CPU " ??, yes snes has also very slow main RAM, but very impressive hardware too ..
When you have good copros, you don't need (usualy) a fast CPU ..

[EvilEvoIX]

This argument has gone back and forth for years.  Look at the games and what the system is capable of.  Later MD games would be really hard to visualize on the PCE.  The PCE is really good at color and I think that is the systems strong suit.  The md has poor color but can be displayed cleverly.  Systems and chip sets have strengths and weaknesses.  In my experience the PCE does shooters really well.  The md certainly does animation better, and the snes did RPGs.  It was an amazing time as all systems were so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between 8bit and 16bit.  When push comes to shove you won't see earthworm Jim on the PCE or Ranger x, at least not without noticeable sacrifices.

[CrackTiger]

Here we go again.

[touko]

Sprites animation on earthworm jim is perfectly doable on PCE, can not on hucard due to his space limit, but not in point of view of PCE hardware ..
PCE can transfert datas to VRAM even screen is not in vblank at full speed (or close).

At this point, the MD is more limited, the huge majority of transfers occur in vblank, where his DMA transfers are optimal .

[CrackTiger]

Sprites animation on earthworm jim is perfectly doable on PCE, can not on hucard due to his space limit, but not in point of view of PCE hardware ..
PCE can transfert datas to VRAM even screen is not in vblank at full speed (or close).

At this point, the MD is more limited, the huge majority of transfers occur in vblank, where his DMA transfers are optimal .

He meant that the MD is better at hand-drawing with pencils than the PCE.

I wish I were being sarcastic.

[EvilEvoIX]

Here we go again.

Man I had all three systems in the day.  Idk why my opinion is being dismissed.  Arguing the specific chipset we all know the M6800 is a more powerful processor.  The MD was given a lot more tools to work with.  It lacks color.

[CrackTiger]

This is an argument I've been rehashing for months.  Look at the roms I have and ignore what the system is capable of.  MD games are impossible for me to visualize on the PCE.  The PCE is really cute and I think that is the systems strong suit.  The md has poor color but I can be fooled by simple tricks.  Systems and chip sets have strengths and weaknesses which I cherry pick to acknowledge.  In my experience, I have only seen the PCE do shooters.  The md certainly hand-draws cartoons better, and the snes has more RPGs in english.  It was an amazing time that I missed out on, or so I am told, as all systems were said to be so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between NES and SMS.  When push comes to shove you could see Sapphire on the MD or Lords of Thunder, without any noticeable sacrifices.

Fixed.

Here we go again.

Man I had all three systems in the day.  Idk why my opinion is being dismissed.  Arguing the specific chipset we all know the M6800 is a more powerful processor.  The MD was given a lot more tools to work with.  It lacks color.

Only the parts of your opinions which dismiss and ignore all presented facts. See this latest comment for example. Did you even read any of the tech talk before ignoring it and just re-posting the same stuff again?

[Tatsujin]

Yeah sapphire is just a shewty, therefore pce can obviously handle it well.
If it were another genre than a shewty, it would be plain shoddy because pce only can handle shewties well..

[touko]

He meant that the MD is better at hand-drawing with pencils than the PCE.

I wish I were being sarcastic.

LOL ..

I do not mean to be a pce fanboy, but there are some points where Md is better than PCE, and IMO not for CPU ..

It should not be a general CPU usage, because the main use is the game, and assembly was the main language, the c was trivial in professional studios.

[Arkhan Asylum]

Yes of course, but you're taking extreme cases ..
68K is perfectly designed for a workstation, and of course is well suitable for a home computer, better than a 6280, in this case 6502 is out of competition .

Not quite extreme.   The more 16-bit operations you do, the more the 68k will begin to win out.   Unless you make frequent, proper use of the zero page.

So it really just depends what kind of game you're making.  What's really funny though, is you would most often be using 16 bit numbers for RPGs (for stats, EXP, gear, combat stuff), so you won't even notice that there's a speed difference.  

I agree with that, and how many people said "Snes has a crappy  CPU " ??, yes snes has also very slow main RAM, but very impressive hardware too ..
When you have good copros, you don't need (usualy) a fast CPU ..

Yeah the 65816 is a giant piece of crap, but the rest of the SNES pulls it together for some excellent games.  Contra 3 is no laughing matter!



There are some things the MD does well/easily that the PCE doesn't do as well.   One of those things is multiple background layers.    Earthworm Jim is possible on PCE, sure.  However, the game would likely lose something in the mix.   You'd have to blow a lot of sprites to fake the layers in a game like that.


PC Engine's strong suits are color depth, and moving a lot of large sprites around, easily.  Sprite animation has nothing to do with the hardware in this case.  It's just whoever drew it.  All the animation you see on MD games can happen on the PCE, provided someone draws it.

  

[CrackTiger]

He meant that the MD is better at hand-drawing with pencils than the PCE.

I wish I were being sarcastic.

LOL ..

I do not mean to be a pce fanboy, but there are some points where Md is better than PCE, and IMO not for CPU ..

It should not be a general CPU usage, because the main use is the game, and assembly was the main language, the c was trivial in professional studios.

The MD has lots of strengths over the PCE and vice versa, just as the SNES has strengths and weaknesses that balance out overall with the MD & PCE. But ever since evilevolx first declared that he "has all the roms", yet was unfamiliar with most games, he has been preaching that the PCE and its games are not in the same class as the MD and SNES and that it is instead in the higher end of the 8-bit generation.

It's pretty bad when you end up with everyone in a Genesis forum arguing against your Genesis>PCE opinions. It's even crazier to think that you'd find any more support for them here.

[touko]

Not quite extreme.   The more 16-bit operations you do, the more the 68k will begin to win out.   Unless you make frequent, proper use of the zero page.

So it really just depends what kind of game you're making.  What's really funny though, is you would most often be using 16 bit numbers for RPGs (for stats, EXP, gear, combat stuff), so you won't even notice that there's a speed difference.  

Yes in RPG 68k is the best thing, for a programmer point of view, more easy and less brainwashing to manipulate 16bit datas ..
In this case, C was also the good choise to decrease time development,and 68k is perfectly suitable .

Yeah the 65816 is a giant piece of crap, but the rest of the SNES pulls it together for some excellent games.  Contra 3 is no laughing matter!

Some other exemples, are super aleste, ans rendering ranger R2

There are some things the MD does well/easily that the PCE doesn't do as well.   One of those things is multiple background layers.    Earthworm Jim is possible on PCE, sure.  However, the game would likely lose something in the mix.   You'd have to blow a lot of sprites to fake the layers in a game like that.

Of course I have not mentioned the second layer ,but this not a determining factor in sprites animation,but but you will probably lose it .

PC Engine's strong suits are color depth, and moving a lot of large sprites around, easily.  Sprite animation has nothing to do with the hardware in this case.  It's just whoever drew it.  All the animation you see on MD games can happen on the PCE, provided someone draws it.

Yes i think so, this is the strong department of this machine, colors and sprites moving, but his sprites limit is very low for a certain kind of games, like beats them all.
I think also that SGX can manage a very good version of earthworm jim, better than MD,except for underwater level and his vertical scroll/2 tiles .

[HercTNT]

What we need is an interactive growth chart with a penis representing each of the different consoles. everytime someone speaks in favor of one of the consoles, the penis's start throbbing and popping up and down.  Up when the comments have some sort of factual information behind them, and down when its just utter fanboy bullshit. This way, people would be careful what they say so that they don't wind up with a tiny penis..........ummmm.........console 

[soop]

Did you even read any of the tech talk before ignoring it and just re-posting the same stuff again?

This.

Otherwise, it's a very interesting topic.  I used some assembly language on the Amiga, so I get the general gist of the conversation, but it's fascinating.

[PCEngineHell]

This argument has gone back and forth for years.  Look at the games and what the system is capable of.  Later MD games would be really hard to visualize on the PCE.  The PCE is really good at color and I think that is the systems strong suit.  The md has poor color but can be displayed cleverly.  Systems and chip sets have strengths and weaknesses.  In my experience the PCE does shooters really well.  The md certainly does animation better, and the snes did RPGs.  It was an amazing time as all systems were so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between 8bit and 16bit.  When push comes to shove you won't see earthworm Jim on the PCE or Ranger x, at least not without noticeable sacrifices.

And yet the MD/Genesis couldn't give you a decent copy of BomberMan, Fatal Fury 2, Fatal Fury Special, or Art of Fighting to save its own life. Dracula X is far better then Bloodlines hoped to be, visually or otherwise. Snatcher, better looking on PCE. Raiden, better on PCE. This happens to be the case with most games, including all the arcade ports, that were on both systems, and there are plenty of games on PCE that are visually more appealing then Ranger X. Ranger X is mostly standard fare for the Genesis in its later life, with a few neat tricks in spots but honestly a lot of smaller to average sprites, dull looking colors and boring enemies and sub par audio. It's also another one of those titles that could have been done on on PCE, esp if on Super Cd. Yeah you'd lose the background scrolling, but fuck it, who cares. The sprites and over all detail and color in the game could have been improved, and over all that is more important.

The Genesis was a great system for being able to move a lot of stuff around the screen fast background wise. Regardless of that, a lot of the crap did not look that great as a whole. Low colors and a rough look are common among even the top tier Genesis titles, and Earthworm Jim is def not that impressive. Tiny to average sprites and a lot of filler spaces in the background art where there is no actual details. Other then the scrolling going on in the background, the game could have been done on PCE, with cleaner, better looking sprites for that matter. The sprite animation could have been handled fine. If you are going to name a game that really holds its own still on the Genesis, pick something like Lightning Force, Shinobi III or Sonic 2, but def not Ranger X or Earthworm Jim.

I'm not really going to go into the sound, people have their own preferences on that, and both systems are able to generate great music and voices when the right programmers are handling it. In the end though don't just assume that because it wasn't done on PCE that it simply can't be done. You may have to ditch some background scrolling, sure, but that is not what makes the game fun or over all visually appealing (and push come to shove, the PCE does have its own nifty tricks up its sleeve, see Vasteel or Metamor Jupiter for a couple of examples). Most everything else the PCE does better, hands down.  And back onto Earthworm for a sec, the only reason Earthworm Jim didn't even get a TG16 release was because Interplay/Shiney did not support Nec systems.

[Arkhan Asylum]

Genesis did get some vibrant games, but they were few/far between.   Most games look all dingy.  It's like the 16 bit Commodore 64.   Dithery and muddy.


Contra Hard Corps, Rocket Knight and Ristar are 3 I can think of offhand that looked excellent. 

but look at stuff even like Phantasy Star 3.  It's super dithered.  PCE RPGs dwarf that stuff.



Hard Corps is arguably better than Alien Wars, but it really depends on preference/mood.

[PCEngineHell]

Yeah well I think Hard Corps looks like crap other then the special fx. You can barely even call it a full screen game because of the dumb ass large black status bar. I will take Contra 3 over it any day of the week. Ristar was good, as was Dynamite Heddy. Rocket Knight was also a good one.

[Tatsujin]

while harcorps is a very good and fun bringing game with tons of action and neaty tricks, still some of its BGs looking like escaped from an average NES game.

[Arkhan Asylum]

Yeah, the HUD sucks in Hard Corps.  I didn't think the graphics looked too bad, when you consider that its a genesis game.

I thought about it a little more, and these are ones I remember looking pretty nice:

Ecco the Dolphin 1 and 2 (duh)
Blaster Master 2, though looking at it again, it's kind of bland in alot of places.
all the Sonic games (I mean that's kind of a given, I guess)
Comix Zone
Flashback
Pirates of Dark Water

But, if I think of SNES and PCE games, the list kinda just keeps going.  Easily, too.

Some of the most widely loved Genesis games look like shit.

[TurboXray]

This argument has gone back and forth for years.  Look at the games and what the system is capable of.  Later MD games would be really hard to visualize on the PCE.  The PCE is really good at color and I think that is the systems strong suit.  The md has poor color but can be displayed cleverly.  Systems and chip sets have strengths and weaknesses.  In my experience the PCE does shooters really well.  The md certainly does animation better, and the snes did RPGs.  It was an amazing time as all systems were so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between 8bit and 16bit.  When push comes to shove you won't see earthworm Jim on the PCE or Ranger x, at least not without noticeable sacrifices.

Says the man who's lacks any real understanding or even experience coding for these systems. I *know* that you are here just to troll. Go back to Sega16, please.

 The PCE hucard setup lacks system ram. 8k is enough to handle all variables, but it's no where near enough to decompress and keep graphics in a buffer for fast access (like the Genesis and SNES). Thus piss poor compression schemes used and minimal animation. I've seen quite a few hucards store graphics in 8 color tile format (sprites and bg tiles) to save on space. The PCE was originally setup for 32k (you can see the evidence as the first 8k bank is mirror on the next three banks. The supergrafx actually fills those slots), and it that would have helped tremendously in using schemes like LZ compression BITD (like Genesis and SNES did).

 The PCE doesn't lack speed (game logic speed is faster than the snes and about even with the Genesis). The PCE doesn't lack vram bandwidth; it can write to vram during all of active display (if vblank isn't enough). It does have block transfer instructions which are essentially dma 'instructions'  (while not as fast the snes DMA or Genesis DMA, it's a hell of a lot faster than any manual copy method and the previous 8bit game platforms lacked this). The PCE doesn't lack VRAM; it has the same as the Genesis and SNES. Matter of fact, the PCE vram layout is like the Genesis in that it's pretty flexible as where to put stuff (tiles/sprites/SAT); unlike the snes that's more rigid in it's layout. The PCE's sprite scanline limit is also inline with the other two systems. The sprites can be any of the different sizes on screen like the Genenis and unlike the snes that's limited to only 2 sprite sizes per screen.

 The PCE being the first system out, of the next generation, does lack a few things compared to system that came out *afterwards*. And the second BG layer is pretty much the only thing to stand out. If you want to criticize the PCE, do it for that. Not all this other bullshit.



 Anyway, I thought this was supposed to be processor vs processor, and not game console vs game console. Let's get back on track.

Not quite extreme.   The more 16-bit operations you do, the more the 68k will begin to win out.   Unless you make frequent, proper use of the zero page.

So it really just depends what kind of game you're making.  What's really funny though, is you would most often be using 16 bit numbers for RPGs (for stats, EXP, gear, combat stuff), so you won't even notice that there's a speed difference.  Smile

Even if you gave the 68k the full benefit of doubt and said all 16bit operations are faster, how many 16bit operations do you have to execute per 1/60 frame in relation to everything else? I would think an RPG would be the lowest; it'd not like you're going to be hitting those on  1/60th frame basis (at least not for turn base RPGs).

 

Some other exemples, are super aleste, ans rendering ranger R2

The '816, even with its hindering 8bit data bus, would smoke both the 6280 and the 68k at the same clock speed. Even with the 8bit data bus, the '816 is faster at both 16bit and 32bit math cycle wise. But if the '816 had a model with a full 16bit data bus, it would just be stupidly crazy fast.

Yes i think so, this is the strong department of this machine, colors and sprites moving, but his sprites limit is very low for a certain kind of games, like beats them all.

I understand the 16 wide sprite cell setup on the pce, but it wouldn't have been that hard for have a 'half flag' in the SAT that would treat all sprites as 16x8 instead of 16x16. That goes a long way IMO. But that said, MD has a much better sprite size setup (smaller is better in this case) for beatem ups. But if you designed a beatem up from the ground up, you can get something better than Crest of the Wolf/Riot Zone. Check this out:

pcedev.net/pics/SOR_exm_1.png

 All the sprites have been resized to 32 width segments (the top half are offset from the legs). Right there, that's seven 32 wide sprites per scanline. It's not busting the scanline limit. Of course, you wouldn't be fighting all 7 at once; take a note from the SOR2 and SOR3 games - move sprites to the top and bottom and have them wait (sometimes the game even moves them off screen). Also have them fall back really far (almost all the way off screen), etc. SOR2 and more so with SOR3, plays really dirty with the AI to keep the sprite scanline limit down.

[Arkhan Asylum]

Even if you gave the 68k the full benefit of doubt and said all 16bit operations are faster, how many 16bit operations do you have to execute per 1/60 frame in relation to everything else? I would think an RPG would be the lowest; it'd not like you're going to be hitting those on  1/60th frame basis (at least not for turn base RPGs).

That's why I said you wouldn't even notice the speed difference.

You'd notice it in action games, depending what exactly it is you're doing.   If you have an action RPG, depending how you have planned out your character system, it might do something for you.

[touko]

Yes MD sprites size is the most flexible of the 3, and made for saving VRAM, and maximise sprites on screen .
His sprites limit is also very good in h40 mode, by 20 (16 pixels) sprites/scanline  .
With this, a conversion of final fight is more easy ..

I tried to think how doing a good browler on PCE, and I came to the conclusion that the best compromise would be a base of 32*48 pixels sprites, for pushing max sprites on screen,and compensate for the small size by more variety in the movements .

But no doubt that the 6280 can handle a FF sprite size, with 5/6 sprites on screen at same time, and all the game logic,he is powerfull enough .

We discussed with stef about bloc transfers, and it seems that 68k is very more efficient than 6280 in this department .
A peek of 2.2 cycles /bytes, and an average of 4.3 cycles for the 68k.

[EvilEvoIX]

This is an argument I've been rehashing for months.  Look at the roms I have and ignore what the system is capable of.  MD games are impossible for me to visualize on the PCE.  The PCE is really cute and I think that is the systems strong suit.  The md has poor color but I can be fooled by simple tricks.  Systems and chip sets have strengths and weaknesses which I cherry pick to acknowledge.  In my experience, I have only seen the PCE do shooters.  The md certainly hand-draws cartoons better, and the snes has more RPGs in english.  It was an amazing time that I missed out on, or so I am told, as all systems were said to be so different and had so much personality.  I don't think that the PCE suffered so much from it's "bit-ness" however it really does straddle the line between NES and SMS.  When push comes to shove you could see Sapphire on the MD or Lords of Thunder, without any noticeable sacrifices.

Fixed.

Here we go again.

Man I had all three systems in the day.  Idk why my opinion is being dismissed.  Arguing the specific chipset we all know the M6800 is a more powerful processor.  The MD was given a lot more tools to work with.  It lacks color.

Only the parts of your opinions which dismiss and ignore all presented facts. See this latest comment for example. Did you even read any of the tech talk before ignoring it and just re-posting the same stuff again?

Butt-hurt?  Sorry you feel that way :/


I have the express, the tg16 and now the duo r.  I forgot how much Bloody Wolf looks like Gunstar;).  The 6800 is more powerful SND can do more.  As stated in previous threads the PCE can run 8bit data really well but in comparison to the md with 16/32bit stuff it falls behind.  You are not gona run Resq on the PCE.  Keep ignoring those facts?