Excellent video with great VDP tests! So interesting.
@TheAlphaOmegaX3
Жыл бұрын
The previous video testing and this one are both interesting. Obviously, like you stated, optimization on actual game per specific console most likely would make a huge difference. Still really interesting how it's playing out. I'm shocked by the SNES result on this one. Even more to learn! Thanks for sharing man.
@hagopds
Жыл бұрын
Thank you so much. It's definitely fun and I really admire retro game developers for what they were able to accomplish.
@frun
Жыл бұрын
There's basically nothing to optimize, if it was done properly. Because it is just tiles.
@ChazzWilson
9 ай бұрын
Interesting, I like how you break it down. I know Sega should have added more colors and sprites and at least gave it the ability to scale and rotate sprites.
@shenglongisback4688
4 ай бұрын
@@ChazzWilsonYeah, unfortunately cos the loss they took from Master System they didn't want too go all out and cheap out too save money.
@DutchRetroGuy
Жыл бұрын
This is very interesting stuff, I didn't expect that result for the Genesis/Mega Drive. I suspected that the issue here isn't so much the code (though minor changes might make it faster), but rather that the interface between the CPU and VDP isn't optimal. (Appologies, a wall of text is incoming :P) With that in mind, I took your code from github and changed it to access RAM directly rather than accessing VPD registers and assembled/ran it on the only 68000 platform I've got an emulator for right now - the Amiga 500. Obviously I set the emulator to run cycle accurate and not be faster or slower than the machine itself (the Amiga emulator I use, WinUAE, is extremely close to the real deal in terms of speed for the A500). Even though the Amiga has a slightly slower CPU (at 7.09MHz to the Sega's 7.6MHz), the code ran *much* faster than what you measured. It completed in about 14,5 seconds (measured by hand using a stopwatch, so not as accurate as what you did ;)). To me this confirms that the main issue here is the access speed to the VPD. Might be interesting to see what happens if you change the code for all three to access spots in RAM instead and rerun the tests to see what the speed is at that point. *Edit* : I forgot a very simple optimisation (loading VDPBuffer into a register). I've now updated the results for that change. Makes a pretty big difference. Just for fun, I also tried what would happen if I rewrote the code to be a bit more 68000 specific. I combined the loops so that only two remain: an outer loop running 35*127 times and an inner loop running 27*31 times. I also changed the VDPController/VDPBuffer access to use registers instead of an immediate value and immediate addresses. This changed the speed to about 10 seconds. I could have optimised it further (by unrolling the VDP writes), but that felt like cheating to me so I stopped here. From this and the clock speed difference between the machines, I would tentatively conclude that the Sega Genesis CPU *should* be able to run the code you provided in around 13,5 seconds and my optimised version in around 9,3 seconds. Of course, this does assume that the Sega Genesis (like the Amiga 500) has zero-wait-state access to RAM. The remaining 10 or so seconds is then slowdown due to VDP access. Interesting stuff for sure! Also a neat showcase to see that MHz ratings are not everything.
@DutchRetroGuy
Жыл бұрын
Bonus points for seeing where my new algorithm has a bug 😂 Doesn’t make much difference speed wise if you fix it, though 😉
@CarecaRetrogamer
Жыл бұрын
Again, I'm impressed by ur skills to improve the test even more... u guys are beasts, both you and the guy in the video! Cheers!
@hagopds
Жыл бұрын
Nice to hear from you and thank you very much for great ideas. I'm a big fan of the Amiga 500 and it's amazing you are coding on one🙂. It would be really interesting to see how the Amiga compares to the Genesis. Yes, that certainly makes sense to access RAM and use a register for the VDPBuffer. It will be fun to try and see the performance differences. Using larger for loops is certainly helpful. I wanted to keep the algorithms as close as possible on all three consoles, and limited the range from 0 to 127. This way I was able to use moveq for the 68000 as you suggested in the previous video. I appreciate your help and thank you so much for the interesting discussion.
@DutchRetroGuy
Жыл бұрын
@@hagopds thanks! I've been coding on the Amiga for a few years now, always have been fascinated by retro tech and it's a very interesting platform that I used heavily in the past, so it made sense for me to start there :) By the way, my inner loop optimisation can't be done - it changes the output of the example code (which I hadn't seen because my test code didn't write to an actual VDP ;)). But changing it to three loops rather than four should still be possible and keep most of the speed increase I found. Also, I only wrote to RAM to see the overal speed of the instructions, because I thought that the VPD might be slowing things down. It seems this is the case. I don't think that doing the code on the Mega Drive itself via an intermediate cache action in RAM will be faster :( As for Amiga vs Mega Drive, I'd simply say that the Amiga 500 is a better computer and the Mega Drive is a better games machine. IMHO, of course :)
@iwanttocomplain
Жыл бұрын
There’s an emulator for Genesis called Kega Fusion, it has version for Windows and Mac.
@retromtg1834
Жыл бұрын
N64 vs PS1 vs Saturn would be pretty great. Nice video, these are amazing
@glenndoiron9317
Жыл бұрын
Interesting, but nobody would actually do this on the Turbografx. The Turbografx had opcodes (ST0/ST1/ST2) and a block VRAM copy state machine (TAI/TDD/TII/TIA etc opcodes) which are several times faster than this and were intended to be used for this exact scenario (copying data from RAM/ROM to VRAM, or from VRAM to RAM). The copier takes 6 cycles per byte written, so approximately 1.5 million bytes per second, and would chew through the 4.1 million tiles in around 3 seconds.
@glenndoiron9317
Жыл бұрын
@@inceptional Feel free to make more leaps of logic and put more words into my mouth. Your mental gymnastics are impressive.
@Stabby666
Жыл бұрын
@@inceptional His point, obviously, was that the optimum method wasn't used for the test. This doesn't mean the optimal method was used for the other systems either, but he was pointing out one case he was familiar with. Did you really find it that difficult to understand?
@Stabby666
Жыл бұрын
@@inceptional You typed a lot of words to double down on your previous comment. The person you replied to did not imply the other systems were given any advantage. Only that the tests were not particularly well optimised for the systems. He likely used the PC engine as an example as he's familiar with the hardware. If he was more familiar with the Nintendo he may have mentioned that. You're assuming bias where none was evident. These types of tests only really make sense if the hardware is being used in an optimal way. You wouldn't benchmark an Nvidia 4090 by slowly pushing pixels from RAM into its video buffer using only the CPU - it makes no sense. In fact, benchmarking consoles is generally ridiculous since the games are what define them, followed in priority by the ease of development and maybe how the hardware works as a whole to deliver content after that. Raw figures mean little. I feel the same when people "benchmark" mobile phones. Who cares?!
@turbinegraphics16
Жыл бұрын
That seems incredibly fast, maybe even too fast. They would mean Turbo graphics could display full frame rate and resolution fmv from the cd or simulate multiple layers using tile animations no problem. The arcade card certainly shows it is capable of something special. The 320 mode of the turbo looks real nice too but only a few games use it and the system does tend to have a bit of sprite flicker. Almost sounds like z80 code with those block copies.
@glenndoiron9317
Жыл бұрын
@@turbinegraphics16 Well, the downside is that the CPU is locked out of running code while the transfers are taking place. So it would be a bit unrealistic to expect this kind of transfer rate all the time (unless everything fits on the cartridge or in RAM and you're just copying data.) Also it won't really help all that much with simulating a dual background. A second playfield does not exist on the TurboGrafx, so simulating that would involve manipulating the tile pixel data just like on the C-64 or any other single playfield system. The ram copy function is fast but cannot alter the data like this in transit, it only copies. You would need to precompute the scrolled tiles and copy them on the fly. This is unfortunately very expensive as far as ram utilization is concerned.
@BurritoKingdom
Жыл бұрын
Yeah. The Mega Drive co processors were always it's weakness. The main CPU was a beast but the VDP and sound chips never utilize the CPU to it's potential. The Super Famicom had the opposite problem, great co-processors hamstrung by a weak CPU. This was fixed with the SA-1 enchantment chip, which was basically the SNES CPU clocked 3 times faster and more RAM. I'm still kind of confused why Nintendo didn't use this as the CPU in the first place but it could have been a cost thing. The PC Engine was the most balanced of the "16-bit" consoles. It was easily the most efficiently built console. If you ever see the console, you'd be surprised how small it is. Too bad NEC did a terrible job marketing it in the US.
@MrMilli
Жыл бұрын
"...but it could have been a cost thing" Nintendo originally planned for backwards compatibility with the NES and that's why they went with that CPU to start with. The SA-1 was released couple years after the SNES launch. I can only assume that silicon process refinements allowed that higher clock.
@ArneChristianRosenfeldt
7 ай бұрын
@@MrMilliin the Jaguar docs they mention how they make the custom chips compatible with both 16 bit 68k and x86. In the end 32bit MIPS also worked. How could big Nintendo not hold open the door for 68k?
@jmbenetti
Жыл бұрын
This is great content and I love how you explained everything. I suscribed to your channel and I'll be waiting for more like this. Maybe different tests for 4th generation consoles , or something for 5th?
@BubblegumCrash332
24 күн бұрын
Comments prove the 90s console wars never ended
@ianball3972
5 ай бұрын
Late to the channel, but liking the content !! Thank you :)
@javiiermendes
Жыл бұрын
The only limitation of PCE are the single backgrownd instead of 2 or 4. Any way PCE are close to the SNES on this benchmark. With an independant 2 backgrownd layers even with optimised 64 sprites the diference will be minimal . So no mather if are 8, 16 or even 32 bits procesors the VDP are the heart of all these consoles.
@Sinn0100
Жыл бұрын
This comparison, while interesting does not paint an entirely accurate picture of which machine was faster in the graphics department. I believe, if you factor in each systems RAM along with their graphics processor the end results would look radically different. These machines are far more than the sum of their parts.
@harrisontashjian752
Жыл бұрын
Very interesting, my favorite part is the comments about the optimization of code in an attempt to push each system to it's limit. I wonder how other competing systems stack up against one another.
@TurboXray
Жыл бұрын
You also got quite a bit of your specs wrong. The "typical" res for Genesis/MD is not 320x240. It's 320x224 (it's only different in PAL regions). PCE/TG is typically 232 lines not 224 lines (and even up to 240 lines). You're "video" clock speeds are also all wrong. The huc6260 is not a "video processor".. it's just a color encoder. So it's only the huc6270 for the PCE/TG. Emulators does mean anything. Run the tests on a real console (like console devs from their respective communities do), if you're really trying to benchmark stuff. For example; SNES9x runs the snes at the full 3.58mhz in high speed mode, but the actual performance is closer to 3.1mhz because work ram runs at a slower rate than fastrom - and this is a 65x design.
@athos5359
Жыл бұрын
what is the speed of snes video ram is that not more important for the video hardware testing,plus the snes has more on die cache ram vs the genny maybe that is why the snes video hardware is a lot faster
@TurboXray
Жыл бұрын
@@athos5359 What? Explain to me what exactly you think is "on die cache" on the snes..
@athos5359
Жыл бұрын
@@TurboXray from sega retro forum,internal gpu cache genensis=236byte, bandwitch=28,846588mb /s. snes=1056bytes ppu1=544byte OAM ,512 CGRAM.
@TurboXray
Жыл бұрын
@@athos5359 Sega Retro is a shitty and seriously inaccurate site. Please for the love of gaming, don't read that garbage. It literally has made up figures, complete misunderstanding, and is the running joke of retro gaming for years. There 's NO cache on these video chips. There's a line buffer for sprite fetching, and SNES is old school with on chip ram for OAM table and color ram (just like the PCE, and like the NES before them). On chip memory is not cache. Buffers are not cache. And to go back to my point; the "speed" of the video processor is not inherently testable via writing to vram in a loop.
@athos5359
Жыл бұрын
@@TurboXray wel the sega genensis had a sprite cache so theres that it reduce acces tovideo ram so i think this banchmark is more puching the video ram to the limit than the video chip.
@frioglobal
6 ай бұрын
I was intrigued by the title of this video, but I am sorry to say that unfortunately this is not a VDP benchmark whatsoever. It is somewhat interesting to benchmark RAM to VRAM data transfer speed as a minor point of comparison of bus speed, but there are too many flaws even with the method used to make this simple comparison. The code presented does in fact not push any of the systems to their limits, as no special instructions are used, no particular care is given to the choice of institutions used to perform the transfer and crucially no DMA was used at all. Let’s say that at the very least the title is misleading…
@RetroGamebloke
6 ай бұрын
A good example of commands per cycle and cycle speed. Although, the Megadrive definitely had the edge on the SNES when it came to sprite handling as far as I could see. So many shooters on the SNES were awesome, bar the fact they slowed to a crawl. The PC Engine however, was an awesome bit of kit for it's time, annoying it never got released in the UK. Still have a Turbo Graphix portable about, which despite the battery issues, was very impressive graphically and was better than any rival product at the time. All had their advantages to be fair. If used well, any of these systems could kick ass. All they were missing (at least for me) was a keyboard and a way to program them.
@michaelraasch5496
Жыл бұрын
Good video. But I would say this kind of test actually is misleading. You are not comparing the VDPs but just how long it takes to put some values into them. I'm not 100% sure but I would say writing data into those video registers will not halt the CPUs until the VDP is done. Based on this II would optimise the 68K code and change that move.l from move.l #$40000003, VDP_CONTROLLER to a move.l d5,(a0) . And of course put the respective values into the registers d5 and a0. You go from 28 cycles down to 12. And also use an address register for VDPBuffer. There you will get 100% speed increase alone. I have not checked that optimisation so please give it a try.
@Mavendow
Жыл бұрын
This makes a lot of sense. Especially considering that optimizations were a subject of much discussion on these systems. Every cycle counts when you're working with MHz. Nowadays I've occasionally gotten 1,000x+ speed boosts from refactoring code that was already being used in a product. It really shows the difference in how we code.
@michaelraasch5496
Жыл бұрын
@Jôn I'm most familiar with the 68K. Feel free to optimise the others. Fanboi
@michaelraasch5496
Жыл бұрын
@Jôn and just for you: for the Super Nintendo replace the stx RAM_x0002 with txa and ldx RAM_x0002 with tax. You do the math.
@hagopds
Жыл бұрын
Thank you Michael, really great suggestions. I tried a quick test by initializing d5 and a0 and changing move.l #($40000003),VDPController to move.l d5,(a0). It took the same time (under 28 seconds) to complete the test. Thanks again, very interesting ideas.
@DutchRetroGuy
Жыл бұрын
@@hagopds this pretty much confirms my feeling that the reason for slower execution is that the VDP can't respond to new data as fast as the CPU can deliver it. Thanks for the extra test, very interesting stuff :)
@Sinistar24
Жыл бұрын
Looks like you forgot to turn on “blast processing mode” on the genesis 😉
@nuclearkitten6421
Жыл бұрын
The Genesis VDP had a ton of effects in order to bump up the amount of colors the genesis could display iirc It did prove to be an issue on the original VA0 units where they found an issue with the vdp and clock speed mid production and had to wire on another board in order to fix it
@TurboXray
Жыл бұрын
Your assembly code doesn't even match your pseudo C code. The snes and pce aren't doing any sort of "tile[n]". PCE is literally doing display(counter-), and SNES is doing display(counter-). The PCE code is writing the counter to ram, and then reading it back.. for no reason!.. why??!!! Just write Y reg to data port like you're doing with the snes code. Also.. you can't write to VRAM during active display on the SNES. It doesn't work - only during vblank (stop using crappy snes9x.. it's old and inaccurate). You CAN write to vram during active display on the PCE and MD though. But on the MD, you will stall the CPU because you'll fill the FIFO buffer too fast- which is what is happening, which is why it's slower. Your SNES version is going to be much slower, because you can only write during vblank time. The PCE one, I corrected it to be like the SNES one and it's ~70%. I mean, not like any of this matters because this "benchmark" doesn't show anything. Literally doesn't tell you anything - it's not representative of anything. And it's also highly dependent on the CPU.
@smokeydops
7 ай бұрын
You need to use real hardware for these tests. Emulators may show a trend but they are not trustworthy for performance.
@frioglobal
6 ай бұрын
Oh there are fallacies with this way beyond the fact that real hardware wasn’t used 😉
@dimddr_man
6 ай бұрын
Maybe genesis 8 MHz and sega CD 14Mhz?
@MrDarchangelomni
Жыл бұрын
On the SNES you can display 32k simultaneous colors using scanline interrupts.
@MrDarchangelomni
Жыл бұрын
@@inceptional Im not aware of any production games, but there were a few homebrews and a couple demos that I remember from what I remember it was interupting the screen on a particular scanline and using some kind of transparency effect and/or artifacting.
@MrDarchangelomni
Жыл бұрын
@@inceptional I will fire up my socket 7 and see if the bbs list is still on the drive
@imaxjunior6531
Жыл бұрын
It would be interesting to combine the code of these two resent benchmarks into one code then run.
@iwanttocomplain
Жыл бұрын
What do you mean by “drawing... background tiles”? Do you mean loading into vram from cart rom or wram? If so which? Do tiles need to pass through wram to get into vram? I don’t think they do. Is loading tiles into vram something which is a common bottleneck in practical performance? Why do games slow down? Is it due to loading in tiles from the cart or is it from a large number of sprites animating (updating their co-ordinates and loading in new frames of animation)? I’m thinking bottlenecks/slowdowns occur, not due to the loading of background tiles but the animating of sprites, along with background tile scrolling and animating. I suppose animating a background tile (not pallet swapping) is just loading in new tiles. Although pallet swapping is also using some bus bandwidth. So the loading in of background tiles might be 1/4 of the load on a fast moving action packed game on the cpu and bus. So your test is not indicative of more than 25% of the factors which affect game performance. I appreciate the test you made. But if you are replacing the same tile repeatedly, with, I guess, alternating two different tiles (or just the same tile), would there be a different result of you were replacing, say, 20 different tiles concurrently? Edit: sorry, you’re drawing a whole screen and replacing tiles with the same tile. But background layers are generally wider than the screen to allow loading in of tiles before they appear in the viewable area, you probably already knew. That doesn’t affect this test though. I don’t know. But a more useful test might be to see how many unique tiles can be loaded for each new frame. Then to scroll the plane whilst animating the tiles and see if that affects tile loading in speed. Then to add animating and moving (co-ordinate) sprites, maybe one at a time. You would need to write benchmark software like, set up a timer, based on cpu clock speed (as these machines don’t have crystals), although MHz is a measurement related to a second, it’s easy to say 2.5mill cpu cycles = 1 second, then count any fractions to get a millisecond like 2.5mill / 100 = 1ms then count them too) to count (to a fraction of a second), the time it takes to scroll a plane, say, 32 tiles horizontally (255px) with an ever increasing load of sprites. Say, 0-40 on screen 8x8px glowing orbs, like a shmup game. 4 frames of animation each. Have them bounce in a parabola with randomised heights so we can see them. Also have them slow towards the top to simulate physics. Tests like that, anyway. I’m not even sure what I’m looking at here. Are you actually just loading in colour information or pixel data?
@iwanttocomplain
Жыл бұрын
@@inceptional well H40/320px wide res, for some reason, allows more data to transfer into vram during each h-black state than H32 mode. I don’t understand this. Drawing is done by some now obsolete technique called ‘blitting’, which is a component of the vdp or ppu, which has a limit to how much it can do per frame. I don’t know what a blitter is or what it does, but the Amiga has a chip which only does blitting.
@iwanttocomplain
Жыл бұрын
@@inceptional I don’t think the system is being throttled, as I think you’re suggesting, for H32 mode compared to H40 mode. It’s more a case of circumstance. It’s confusing, because a scanline is moving at a set speed, so you assume that if there’s less pixels being drawn then there’s an advantage to the bus in transferring data. But actually these old consoles are not clever, they work like clockwork. The data bus is moving more data in H40 mode because in H32 mode, when the scanline reaches h-blank, the bus has to wait until the next scanline begins before it can push more data. That’s my assumption. As the system is designed for H40 mode, the bus must be set at a nominal speed, which doesn’t change based on the resolution. So when H32 mode is on, which is really a compatibility mode, designed to simplify conversions from games using that resolution, the bus is simply waiting when a line of 32 columns is drawn. I found the table, it’s under Bandwidth for the Sega Retro Sega Mega Drive/DMA page. H40 shows about a 10% additional amount of data per scanline. What’s even more confusing is that the difference between 60Hz and 50Hz is over 110% increase in bytes transferred per scanline for 50Hz. When the scanline speed is only 20% slower. Interestingly, on the Sega Mega Drive/Technical Specifications page, I just noticed there are actually two cart speeds available 10MB/s and 15MB/s.
@jhoughjr1
Жыл бұрын
@@iwanttocomplain Your assumption is correct. Thats why 2600 programmers had to race the beam.
@iwanttocomplain
Жыл бұрын
@@jhoughjr1 oh yeah, I’ve heard that term before. I guess it means cramming as much data into active display, h-blank and v-blank as possible.
@iwanttocomplain
Жыл бұрын
I looked up what ‘blitting’ is. It’s short for block image transfer. What it means is, that if a colour already exists in a pixel from one frame to the next, the pixel is not redrawn, ie, the colour attribute for that portion of memory is not reloaded and this system is actually not obsolete but still in use, as is the packed pixel format, as opposed to the planar pixel format.
@orlandoturbo6431
Жыл бұрын
What are the limitations of the TurboGrafx-16 just the one background layer.Can the TurboGrafx-16 play Nintendo games if there was an adapter.
@hagopds
Жыл бұрын
The TurboGrafx-16's single background layer only allows one background to appear on screen. The Genesis and SNES could display 2 or more overlapping backgrounds, which helps make game levels appear to have more depth. Programmers could simulate multiple background layers on the TG16, but this required more development time and effort. The TG16 and NES have a very similar CPU, although it's not possible to directly play games with an adapter. I think a few games like Mega Man were unofficially ported from the NES to the TG16.
@orlandoturbo6431
Жыл бұрын
@@hagopds I seen those Nintendo games on Turbochip.They even have VIC 20 games like Jelly Monsters and Gridrunner running on the TurboGrafx 16 too.Just wondering what is the chip in the Supergrafx that give it a second background layer.And why didn't they use it in the TurboGrafx-16 or TurboDuo.
@glenndoiron9317
Жыл бұрын
@@orlandoturbo6431 I seem to recall that they slapped in a 2nd VDC, plus another IC to mix the two VDC outputs. The clock speed remained the same, so you still had the same ROM -> VDC bandwidth, but it was now split between the two VDCs as you still had only one CPU and CPU bus to perform the transfers. This probably doubled the number of available sprites, too.
@orlandoturbo6431
Жыл бұрын
@@glenndoiron9317 Is it possible to add a chip in the TurboGrafx-16 to stop the flicker in some games.
@maroon9273
Жыл бұрын
@@orlandoturbo6431 yes, the pce is expansion friendly.
@Roxor128
Жыл бұрын
I think it could have done with a contemporary PC comparison point. Maybe a 386 with a VGA card? I think those were common around the time these consoles were on the market. If you just want to use emulators, the DOSBox wiki says running it at 7800 cycles will give speeds comparable to a 33MHz 386.
@Nordlicht05
Жыл бұрын
We had a 386dx40. What VGA card I have now idea. But we could play battledrome in a for that time ok framerate
@Sinn0100
Жыл бұрын
Forgot the 386, the 486 came out in 1989! Although I do not think it is fair to compare these 3 consoles to a 386 or 486 variant. Right off the bat the gulf in pricing is so large you could have purchased all three 4th generation machines at once and still had money left over to purchase a bunch of games. They just aren't in the same league as the 386/486.
@laumpolumpio
6 ай бұрын
Can you run this same benchmark but swapping the vanilla PCE for the Supergrafx?
@turbinegraphics16
Жыл бұрын
So this is testing copying the tiles into vram and then the name table and then the colour pallete. Certainly a lot faster than the nes and sms which can take a few frames to do the same. So it seems the genesis is slowest to load the tiles but once in memory can move them around faster than snes. There has to be some reason that on all snes beat em ups you only have a max of 3 enemies on screen while on genesis you got a number of beats em ups showing 5 enemies on once on screen. Maybe faster vdp access allows fx chip to be better or for streaming animations from the cartridge faster.
@athos5359
Жыл бұрын
les ai calculations needed with only 3 enemies on screen,snes cpu was slower and ai needs cpu power.
@jsr734
Жыл бұрын
@@athos5359 TMNT Turtles in Time puts 4 enemies on screen plus 2 player characters; another beatemp up named Legend also puts similar amounts of characters on screen and there are other examples i don´t remember right now. Let´s just say that Capcom was not the best snes developer, performance wise.
@athos5359
Жыл бұрын
@@jsr734 is TMNT turtles 60fps??but ok street of rage2 puts 6 enemies on screen 60fps most of the time only4 to 5 on screen, what also depends is how complex the ai is.
@2kBofFun
Жыл бұрын
That probaly explains why DK Country without background and foreground (snow, rain) has basically nothing happening on screen and is plain boring. They managed to make it appear a lot nicer that the game actually was.
@jsr734
Жыл бұрын
@@2kBofFun Donkey Kong Country is a nice looking and fun game (specially 2 and 3) and some stages have lots of bees and vultures coming to you, what do you refer to there is nothing happening on screen?
@dwightdixon8508
Жыл бұрын
Interesting vid. Apparently developers weren’t discouraged by CPU “Benchmark’s” as the software that was released on the Genesis/MD was far more superior than anything released on the TurboGrafx-16/PC Engine and in few instances the SNES too.
@2kBofFun
Жыл бұрын
Take Bomberman 94, vs Mega Bomberman vs Super Bomberman 3.... More superior? Are you on kool aid? MD and SNES don't have a chance. I know this example is made by Hudson, slightly biassed towards the PCE, but I do feel they ran into hardware limitations with their BM94 conversion attempts.
@nathleflutiste
9 ай бұрын
@@2kBofFun "don't have a chance" on what basis ? Each console has its own merits. And everyone doesn't necessarily expect the same things from a game. You just sound like a PC-Engine nerd salty because the Megadrive and the Snes got more success…
@plawson8577
7 ай бұрын
@@nathleflutistePC Engine wasn’t actually 16-bit.
@nathleflutiste
7 ай бұрын
@@plawson8577 Yes I know, it's more like two 8-bits processors working together if I recall correctly, but even though it was the case, the system has very promising capabilities.
@ostiariusalpha
5 ай бұрын
@@nathleflutisteYou do not recall correctly.
@shootermcgavin1208
Жыл бұрын
The TG16 had a superior color palette and sound chip than the Genesis. Just missing the parallax scrolling.
@maroon9273
Жыл бұрын
Superior on screen colors, genesis and th16 has the same 9-bit color pallete.
@jonpirovsky
Жыл бұрын
Sound chip??? No way, the TG16 sound chip is crap compared to the Genesis.
@saturndual32
Жыл бұрын
More colors on screen? Yes Better sound? No
@ImWithTeamTrinity
Жыл бұрын
@@jonpirovsky The Genesis sounded like Darth Vader having sex with a high tension wire. I had both systems when i was a kid, compare MUSHA to Blazing Lazers.
@shenglongisback4688
Жыл бұрын
@@ImWithTeamTrinity lol brah... you heard darth having sex in that sound lol
@erockbrox8484
Жыл бұрын
When you add in the SA-1 chip to the SNES, the console becomes a whole other animal.
@joshuawick5382
Жыл бұрын
Yeah but that chip was on the game, not the system.
@nathleflutiste
9 ай бұрын
@@joshuawick5382 And if we go there we could also speak about the Sega Virtua Processor…
@SoulforSale
4 ай бұрын
Though Sega used a Motorola 64000....
@drd2093
Жыл бұрын
So both the Genesis and SNES have dedicated circuitry for doing this called DMA, and it would be more appropriate to benchmark that. This test shows what I was talking about in my last comment about the memory inefficiency of the 68000.
@robfarmer9272
Жыл бұрын
The SNES could have been a real beast of a console lasting beyond it's years if as you said it had a beefed up CPU and some of the silly flaws fixed. Like only being able to load 64kb of sample data at power up to the sound ram. If they did the simple fix of loading new sound sample data on the fly the snes would have had amazing music for the era. hey ho.
@robfarmer9272
Жыл бұрын
@@inceptional from memory only 3 games or around that found a way to re map the sound cache ram. But took a heap of cpu timing which had to blank the screen. Which made it very impractical for in game usage
@maroon9273
Жыл бұрын
@@robfarmer9272 also, a dma inside the ppu processor.
@SaadAzim
Жыл бұрын
I second this. And while the TurboGrafx-16 didn't have a dedicated DMA, the CPU had the ability to copy data in blocks. If I remember correctly, something along the lines of "TIA source, destination, amount". :)
@jhoughjr1
Жыл бұрын
yes and no. This does combine all parts of the system to get an overall idea of performance. Game GPU tasks would still be CPU bound IRL.
@marisawifkinson3383
Күн бұрын
Moore Angela Gonzalez Scott Hall Anthony
@frun
Жыл бұрын
Sega vdp is suspiciously slow.
@robfarmer9272
Жыл бұрын
Wasn't it just a beefed up Sega Mastersystem VDP. I'm sure remember reading that way back when. It's why it was compatible with the Mastersystem roms. It had a Z80 built in for helping the sound chip but was used for master system roms also, and the VDP was compatible with the Master system as it was basically the same chip beefed up. The powerbase add on didn't have any extra hardware. Just an expansion port convertor and LED. If SEGA actually built the MegaDrive from the ground up to be a system 16 or 18 hardware then it would have been much better imho.
@frun
Жыл бұрын
@@robfarmer9272 Probably, since ms can also display decent amount of colors. No doubt, MD could be significantly more powerful, had it been designed from the ground up.
@robfarmer9272
Жыл бұрын
@@frun yeah. I think where Sega got it wrong. They could have made a better console with off the shelf parts but just spending a tiny bit more. I mean the Yamaha YM2151 sound chip is just better than the MD YM2612 but costs only slightly more. Equally they could have beefed up the CRAM and VRam. The colour palette was a letdown on the MD.
@maroon9273
Жыл бұрын
@@robfarmer9272 facts, big mistake sega made. This is why sega released two add-ons which led to to fall of sega. The genesis would've had a longer lifespand and more competitive with the snes, had they built it based on the systems 18 or 16 board instead of the master system.
@jc_dogen
Жыл бұрын
@@robfarmer9272 but the ym2151 needs an external dac and doesn't include any pcm hardware. say what you want about the ym2612 pcm being crappy ( it is lmao ) but at least it's something. There's also the rumor that yamaha wasn't always willing to sell their higher end chips to everyone. I would argue they'd be better off just making the small tweaks that would make pcm much easier and faster, and a bit more ram for palettes.
@Styler3x
Жыл бұрын
Its totally pointless without using DMA!
@mxggo9046
6 ай бұрын
Yeah, but do they blast process???????
@tizianasaav450
6 ай бұрын
TurboGrafx-16 has a bus of 8 bit??
@diegolastra
6 ай бұрын
It had an 8 bit CPU. It was a sort of hybrid 8/16 bit design.
@tizianasaav450
6 ай бұрын
@@diegolastra thanks
@ostiariusalpha
5 ай бұрын
PC-E/TG-16 had a 16-bit main data bus, plus an _extra_ 8-bit data bus. It was a strange machine.
@tizianasaav450
5 ай бұрын
@@ostiariusalpha Copetti talks about a final 21-bit color bus, that machine is interesting
@mr.hatman9345
Жыл бұрын
But how fun are the games to play? That's all that's important because hardware doesn't mean squat. Personally I had the most fun overall with SNES with Genesis a close second. NEC's games were a little bland but certainly had a few gems, more notably with the CD ROM games.
@nathleflutiste
9 ай бұрын
Well in terms of coding and game development it has its own interests.
@lindadouglas9734
Жыл бұрын
ᎮᏒᎧᎷᎧᏕᎷ 👇
@erockbrox8484
Жыл бұрын
In the USA we never even heard about the Turbo Gfx 16........ ever.
@markstrickland438
Жыл бұрын
Strange, I bought two a few days after launch in 1989, in a very small, rural town in the U.S.A. - at a regional department store at that.
@jhoughjr1
Жыл бұрын
I did back in the early 90s. Saw a few comercials on our satellite tv. Saw them at Babbages for 47.99 in maybe 91-94 sometime. Really wanted one but ended up with a super nintendo. I later bought one at a pawn shop I think with over a dozen games. Sold it in the late 90s.
@zenbyo
Жыл бұрын
@@markstrickland438 Same. I was lured in by the big ass sprites in Legendary Axe and China Warrior.
@lakojake4215
7 ай бұрын
You didn't miss out on much. It's like a slightly upgraded Nintendo(NES).
@darrendavenport3094
5 ай бұрын
@@lakojake4215 you have no idea what you're talking about lol
Пікірлер: 151