You’re not wrong to say it was called the Mega Drive in Japan, but it was actually called the Mega Drive everywhere outside of Canada and the U.S. (eg. Europe, Australia, etc.).
The 68000 is a transitional processor, that is clearly designed to be competitive with other typical 16-bit processors, but it also has 32-bit registers as what seems like a future proofing attempt, so when future systems would need to transition to 32-bit, they can remain software compatible, to some extent both ways. Really most instructions only operate on 16 bits to conserve the number of memory transfers and computation, and considerable effort went into cutting down the amount of extra hardware required for 32-bit to almost nothing. Compare and contrast say 8088, a 16-bit processor designed to be integrated into 8-bit systems; or 386SX, a 32-bit processor designed as a drop in replacement for 16-bit systems. Obviously neither of these are particularly efficient at the operation at the maximum operand width. It was also common to see 64-bit processors used in systems where actual 64-bit operation wasn't really the desired goal, like PS2 and N64. On Megadrive/Genesis, the DMA peripheral stops the 68000 CPU whenever DMA is running. However it's still a net advantage, since it can copy data much faster than 68000 could hope to manage! It's also pretty much necessary since the video memory isn't double buffered, so for the elements that are currently being displayed, you can't just overwrite them as you're preparing the data for next frame, you have to prepare the data in a separate buffers in main RAM while the previous frame is being scanned out by the VDP, and then QUICKLY transfer these buffers from main RAM during the blanking period. The processor has to be stopped, since the system doesn't have multi ported main RAM or cartridge, the main RAM and cartridge ROM are just slow enough for the processor, and the processor doesn't have any cache or scratch RAM, so while it's disconnected from RAM, there's nothing that it could possibly sensibly do! The advantage of DMA peripheral is that it only needs to deal with the data, it doesn't have to fetch a 16-bit instruction every time a 16-bit chunk of data needs to be transferred. Additionally, since the processor sits on the main bus, it would necessarily consume at least 3 main bus IO cycles synchronised with main RAM and cartridge bus per transfer, so instruction read, operand read, and then operand write; and that fully unrolled, not counting control flow. DMA peripheral however sits inside the VPU, so it doesn't need an operand write cycle, since the write is internal, it only needs a read on the external bus. So DMA is at least trice as fast. Actually most systems of the era made use of cycle stealing, where whatever device held memory, would just stop the CPU clock whenever it needed to do the memory transfers, and as the name implies, as opposed to DMA here, it was just for several cycles at a time. There wasn't really much design room for a more fine grained protocol that would allow for a higher hardware utilisation! It's difficult to say why the Z80 was included. It seems that Master System backwards compatibility was a design consideration from the start, Z80 was cheap enough, and would be needed for that anyway; and while it's already there, it might as well take over audio tasks, it's usually used to program the synthesizer soundchip registers, and also manually handfeed samples to the optional DAC channel of the Yamaha soundchip. Obviously had they chosen to forgo Z80, they'd just need some sort of FIFO buffer or an extended asynchronous DMA peripheral to do digital PCM audio. I think some modern productions use 68000 to do most audio stuff, instead dedicating z80 to mix and pump several PCM channels or achieve higher PCM sample rate. In my mind, TI PSG chip was never physically present as a discrete component, integrated into the VPU or the jungle chip instead, as Yamaha's reimplemented version with a different noise pattern. Also very, very few developers on the system actually wrote any Z80 code, choosing to use SEGA's provided tooling GEMS instead which included the audio driver code and was a complete MIDI based authoring solution.
68000 has 32 bit registers to address more then 128kiB or 64kiB if you want byte granularity. Anything not 2^2 is odd. You want segments? Also to keep the register file in proportion to all the microcode, 32 16bit register would be okay. Then just pair them up like on 8088. I don't think you've got to get philosophical on this one. Cycle stealing sounds so mean. What about the fact that the 68k and the z80 have a phase where they think for themselves and don't need any cycle? Funny how many computers were able to fit their other memory needs (DRAM refresh for z80, video refresh for AtariST) into these slots.
@@ArneChristianRosenfeldt but there's only 23 pin (effectively 24 bit) address! Apparently going 32 bit was cheap enough though in terms of complexity, and gave it that extra elegance and flexibility. Fundamentally nothing prevented them from doing 24bit registers though. As to whether I want segment addressing is not the question, that's the design 16 bit processors simply tended to go with. 8-bit processors also have special handling for addresses to accommodate 16-bit address space, and it was 'fine' for what it was. Z80 has built in DRAM refresh logic. It's partially used on the Spectrum for extended RAM (the optional 32k) while the 16K are refreshed passively by video scanout. I don't know how DRAM refresh works on ST, I'll learn about it. Fundamentally though you have to roll with the memory timings you're given, and the high capacity ROM available for cartridges wasn't very fast. So while you can expect to have 100ns RAM easily, most megabyte capacity ROM of the late 80s when Megadrive came out could be expected to be like 450ns. Megadrive mandates something like 200ns ROM for the cartridge. But it's all the same bus and ROM accesses are necessarily very abundant on Megadrive.
Soooo 🤔 if another 32kb of ram was throw in there.. would that have fixed a lot of the issues the genesis had that Devs saw as short coming s .?????????
@@ArneChristianRosenfeldt My laptop has 20 GB of RAM, and many systems have odd integers of 64KB. Many graphics cards in the 90s had 6MB or 12MB of VRAM.
The Z80 was also for maintaining backwards compatibility with Master System games. The Mega Drive was internally referred to as the Mark IV as the continuation from the Mark III/Master System. Coupled with the SN76489, there's still a Master System at it's foundation. And as it came out in 1988 in Japan, it was competing with the Famicom and PC Engine then in 1989 in North America against the NES. That was the whole crux of the "Genesis Does What Nintendon't" campaign, it was their new 16-bit machine against the aging 8-bit NES but SEGA still struggled to make headway because of Nintendo's grip on the market and third-party licensees. There was no "Console War" until 1991 after the FTC forced Nintendo to cut out their shit and make it a more fair for competitors, that's when SEGA cut the price of the Genesis to $150 and packed in Sonic the Hedgehog to counter the launch of the SNES then took half the market for a window of time.
Regarding "Blast Processing" - I think I remember reading an interview with one of SEGA USA's devs who said he had mentioned "blasting data directly to the VDP" and one of the marketing guys overheard him and had a eureka moment - Blast Processing was born.
Great work! It would be interesting to make a video about the NeoGeo, specially as it shares many similar hardware components as the Genesis/MD. It was so ahead from others consoles of its time by relying most only on sprites and huge cartridges but would be nice to see how that was achieved.
Blast processing was basically a catchier name for DMA, more marketable. During transfer the 68k CPU is frozen making it only viable during VBlank, while the Z80 is unnafected unless it needs to access the bus. This was a faster method of moving data from ROM or RAM to VRAM/CRAM/VSRAM and didnt require special code to send it via the data port. This made it quicker than the equivalent 68k instructions that achieved the same result.
Anyone that asks is it really that impressive a feature? From experience, yes. You can dma new tiles graphics, scrolling, animation, fading.. and its fast and easy.
Of all the console wars, the 16-Bit War was the best. Not only do we get the best consoles of the time but the best games unique to those platforms too.
The best I could find based on internal statements from the time: Blast Processing meant using the DMA to burst transfer data from game ROM to the DAC (Digital Analogue Converter), saving the CPU some clock cycles to do other things. Is that really a big advantage? At the end of life, it was. The Genesis was still able to free up about 1 MIPS from the 68000 CPU to handle some audio and video effects in software allowing it to play DOOM and Wolfenstein like stages and add a bit of flare to Aladdin, Toy Story, and some arcade ports right before SEGA of Japan murdered the system (with its dominating 55% market share in North America). Megadrives were better than their contemporaries because you could eventually get all five chips running and doing useful work at the same time, and because the VDP left in all sorts of sprite and color hacks that made these late games possible.
@@ZygalStudios The term "Blast Processing" came about after an engineer tried to explain DMA techniques to marketing. So while it is a marketing term, it is referring to something which the Genesis excelled at... very fast DMA transfers, to various RAM. Not just from ROM to DAC.
There was a lot of parallax scrolling and some impressive art and animation as early as 1992 under the Kalinski team. Hell, Sonic 1&2 hacked the hardware a lot.
@@ZygalStudios And if SEGA had released a 12MHz 68EC030 + 😮SVP "Genesis32" like I've suggested, then it would've cost less than the 32X, been easy to bring games over (using the 3D or sound), and kept the Genesis alive for another year or two. As important, with the onchip caches, that would take some demand off the system bus and allow much faster DMA transfers for 3D graphics.
6:02 Lol the Genesis/MD' 32/16-bit CPU was clocked literally OVER TWICE AS FAST as the 16/8-bit CPU in the SNES! (≈7.6MHz vs ≈3.5MHz) "A little bit faster"? Get real... The Genesis/Mega Drive absolutely CRUSHED the SNES in raw CPU performance! And the game library reflected this! (Action & sports games). It's the custom graphics & sound processors that made the SNES special, and the games reflected that too. (RPG's, platformers).
Yes, thank you for pointing this out. When I said "A little bit of a clock speed advantage", thinking on a smaller scale than what I'm typically used to, didn't seem like all that much. But yes, it is a major difference and benchmarks prove that! The genesis is far more efficient at processing for raw computation. However, I want to address something that can be a bit misleading in this context. Clock speed isn't always indicative of CPU Performance. There are far more factors involved in the design of a processor than just the speed of the clock that effect overall processor performance. Your comment seems to have two sides to it. In this case, the clock speed difference is so overwhelming that it does make a significant difference, but this isn't always the case as gaps of clock speeds start to shrink. Amdahl's Law is a great reference to how to look at some of these things comparatively from a high level.
The Genesis CPU was rated at 1.2 MIPS. The 6502 in the NES ran at 0.5 MIPS, slightly slower even than the anemic Z80 in the Master System. The SNES used a 16-bit version of the 6502 which officially boasted 1.5 MIPS or a theoretical 1.8 MIPS, though never matched the 68000 because of a lack of registers and memory access bottleneck. They were relatively close in performance.
@@MaxAbramson3 "The 6502 in the NES ran at 0.5 MIPS, slightly slower even than the anemic Z80 in the Master System." Don't think so. NES 6502 clocked at 1.789mhz is ~0.720 MIPS. Master system z80 @ 3.58mhz is ~0.520 MIPS. But it's not even that. 6502's direct memory access and free indexing as well, makes it much more performant than the z80. The 65x design isn't hurt by the lack of general purpose registers because it has fast direct memory access. And for indirection (address "registers" or vectors), it literally has up to 128 "address vectors". The bottlenecks on the z80 are because of its limited register set (needed for the lack of direct addressing modes), and it's a bottleneck compared to the 65x design. As well as the 65x isn't constantly needing to push/pop from the stack like the z80 constantly is. What the 65x carries over in relation to competing with the 68k, is the 68k has ZERO benefit from 8bit operations. And it has a fairly high overhead for instruction cycles FOR some instructions that offer little performance bang for the buck (support instructions; test, jsr, rts, etc). This is how the 65x can pull up to the 68k, and a 5mhz '816 would literally destroy a 7.6mhz 68k. I've coded and cut my teeth on these processors in assembly. The whole MIPs thing is fun to look at, and tells you something about the arch/ISA design, but it's mostly useless for direction comparisons. The only thing it really tells you - is the difference in architecture between the 65x (and 6809) and the 68k. I found that some of the worse people to talk about performance across different processors.. are people that mostly/only coded for the 68k. They can't wrap their mind around anything that isn't a 68k design. 65x is an "accumulator" processor design - fast simple instructions with fast direct memory access. To them, that's a bottleneck. They don't understand the optimization part that goes along with that. The z80 is a hack of a "accumulator design" but with MOST of the advantages taken away and more bottlenecks thrown in. The 68k design was literally designed with the purpose to keep it OFF the bus. That's why it has a grip load of registers for its time. Because on "real" systems, you're going to be sharing the bus - the 65x/6809 are just bus hogs (and require 4x the speed of ram than the 68k) and not just not scalable. The 68k totally excels in what it was designed for. But in a game system, the 68k loses a lot of that edge and design. The 65x design picks it up because supporting hardware takes away most of the need for the more powerful 68k instructions. I can also tell you the Genesis CPU is NOT running 1.2 MIPs. That would mean the average instruction is ~6.3 cycles. THAT is a laugh. About 12 years ago, we ran genesis games with a MIPs calculator in the emulator.. and it was around ~0.710 MIPs. No Lie. It doesn't tell you the performance, but it tells you the instruction cycle length is pretty slow.
9:10 should read YM2612 and outputs 53Khz. It has a 9bit onboard dac. It has six channels each with 4 sine wave ‘operators’ with 8 possible ‘algorithms’. A pcm mode for channel six and an independent lfo signal, assignable to any attribute/s across the channels. The design is a paired down DX7 FM design but the DX7 has 12bit output, 6 operators and 32 algorithms. The TI sound chip is 3, square wave, 3 octave tones (I think) and a noise channel which can combine with another channel to generate noisy tones. All four together can output a sample. The YM2612 generates very clean audio with a wide bandwidth (bass to treble) but the 9bit fav caused digital noise which is fairly noticeable if you know what to listen for. Around 200 games used the GEMS driver. Most sound bad. The reason is that the default patches (instruments) were somewhat hastily designed and the author of the driver assumed that composers would apply tweaks to the instruments to polish them up a bit but this happened quite rarely. Composer Spencer Nilsson did a bang up job with Ecco the Dolphin and Nathan Grigg for Demolition Man but the majority fell flat. The problem was in the nature of the MIDI standard. 128 patches was standard. So any midi device recognises what any instrument should be in the 128 instrument bank and the instrument will do its best to replicate, say, a marimba for patch 12. So any composition should theoretically sound correct played from any midi compatible device. But this is extremely limiting when you consider the possibilities of fm synthesis with an additional lfo. You are drawn into a corner of writing in individual notes and ignore that an fm system can generate an envelope of sound, altering a range of characteristics across the duration of the note or even not have a specific begging or end. I’m going off on one but GEMS, many of you may know is infamous for giving the chip a bad name. It was the equivalent of playing back a midi tube one windows 3.1. There is a somewhat jangly staccato sound to notes starting and stopping so abruptly and with such basic shapes. I think it’s more accurate to say that US developers struggled with the Z80 and FM technique who never programmed a Spectrum or Amstrad CPC. You will find that games using GEMS would come from that region, whearas the UK has the Krisalis sound driver available or otherwise created exceptional music such as Tim Follin and Matt Furniss. To hear the chip being put through its paces, the Technosoft developed Thunderforce 4 soundtrack is recommended. But the lost is endless. Skeleton Krew and Bram Stoker’s Fracula are also examples of how a midi implementation falls quite short of the full utilisation of this chip by more technically minded chip tune musicians. Disclaimer: this information is probably about 90% correct.
It makes me wonder if it was really so much of a stretch to just have 256B of cram, could have easily doubled the colours. But video games were still seen as a niche industry at the time so maybe it wasn't worth the risk.
I have heard the Sega Genesis was a very easy platform to develop for. The consoles power was easy to get to and given how it was built most arcade developers should have felt right at home.
It's easy so long as you're not trying to push the machine to its limits. Developers with 3-4 years of experience were able to get that machine to crank out impressive 2.5D and even flat shaded polygon graphics to rival powerful arcade hardware of 1990-91 era. Some of us are even working on DOOM for the machine and are up to 4-5fps.
@MaxAbramson3 Holy...Doom?! That's freaking awesome man. I have a question no one has ever given me an answer to. You just might be the guy to know the answer. If not, or if you don't feel like it or whatever, that's cool to man. Here goes... Would the Sega CD be able to run a port of Doom with its ASCII chip and second 68K processor? Seeing some of the games running on it... like Soulstar, make me think it could have done it. Now, I'm not, of course, talking about a 1-to-1 port of the PC here or even the 32X retail release version. I'm thinking better than the Snes with ceiling and floor textures, windowed, and at a 15-20 FPS. I would also expect simplified geometry and maybe maps that are cut with loading screens, perhaps.
@Sinn0100 Using the ASIC DSP for floors and ceilings, 256x128, maybe 15-20fps. More likely a 8-15MB cartridge with the CD-ROM holding cut scenes and/or music. It's possible that we could simply load all of the textures and enemies for a stage into the 256KB of work RAM, then use the scaling feature of that ASIC DSP to scale and warp walls. That would get us to 15-20fps, though not consistently.
0:06 it's not also known as the Sega Mega Drive. It's also known as the Sega Genesis. All of the world except North America had the Mega Drive and it would have been called the Mega Drive in NA as well if there wasn't licensing issues. Well there was Korea too where it was localized, so the full and factual way to say it is: The Mega Drive, also known as the Genesis in North America and Super Game Boy/Super Aladdin Boy in Korea. It was created as the Mega Drive and only renamed because of a livencing issue so it doesn't change what the console is called universally. If there were big companies in NA named Dreamcast and PlayStation, the consoles would still be called Dreamcast and PlayStation even if they were localized Sega Leviticus and Sony Exodus in North America.
I would love to see a video that describes the creation of the Mega Drive, drawing board to shop shelf. In particular, what was envisioned and what actually came to be. Great video, thank you.
Well for one thing the VDP was intended to use a second 64k block of VRAM The pins still exist on the package, but were not connected to anything. There is an undocumented interleave mode in the VDP that would have allowed for video writes to be twice as fast by writing to both at the same time. In this mode sprites and tiles are spread across both banks of VRAM. The VDP also has pins for external color RAM that are also not connected to anything that would have allowed for more color pallets. The C2 arcade board which uses the Megadrive VDP as well as a 12Mhz 68000 and no Z-80 actually uses those features of the VDP and had something like 16 color pallets instead of 4.
@@atomicskull6405 Yes and apparently Team Titan found some unused commands which allowed for some form of hardware scailing with Mega Drive’s ($C0001C) debug register. Also, the mega drive can have 2 MB installed on the board and the system will recognise it and can use it if software was made to take advantage of it, apparently the mega drive always sees the 64KB as 2MB any way, or something like that. I did know that original design specs were to have 128KB of system ram, that would of been amazing if it was to come to the shelves like that. Back to the 2MB, there is one ROM that would see it if you were to install the memory, MEGA OS, that tech demo OS, that can actually see the system RAM, so it would be nice to try that.
@@notsuoh16Bit 128KB of video RAM, but Sega of Japan pared that back to 64KB of VRAM at the last minute to save money. So SEGA could've released an upgraded Genesis with a 12MHz 68EC000 CPU (or 68EC030 with caches to take some of the pressure off the system bus), 12MHz Z80 sound chip (3.5x faster), up t 2MB of RAM, 128KB of VRAM, and another color mode on the VDP similar to the Saturn, making it easier to develop 2D games for both systems. Worse, this could've been released for Christmas of 1993, would've been more powerful (in some ways) than the Jaguar, made the 32X unnecessary, and existing games would've played much better on the 12MHz Genesis. They might've even been able to add Virtua Racing's 23MHz SVP to avoid the Lock On cart patent issue that kept the $49.99 unit from coming out. For existing Genesis owners, a swap-the-box would've cost around $100-120, much less than the 32X. Update: This would've made life EASIER for game developers, since their 1994-95 games that wouldn't quite run on a 7MHz Genesis would now run fluidly without a rewrite. Existing Genesis owners would only be out $100, and new buyers could get a complete system for about $130--perhaps with Daytona USA as the pack in.
It was based on a description of the direct color trick the SoA tech director figured out, but the marketing people undoubtedly didn't understand that anyway.
@dogen While that is the story we get nowadays. Like Joe stated, at the time it was advertised as a way of saying that the genesis had faster more Xtreme games than the SNES. No game showed or even made at that time used the burst feature that was later described. I think once they got called out on it they just searched for some explanation.
It was a marketing term to describe the DMA transfer from the ROM cartridge directly to the Digital to Analog Converter (DAC). The CPU did not need to be externally interrupted in order to perform these data transfers around the system.
I wish the genesis had better expansion support by connecting the pins to its hardware to the expansion and cartridge for future enhancement purposes which would've axed the need for the 32x add-on alongside using its dma years earlier like the japanese developers.
@@KungKras System 16 was just a C2 arcade board with a slower processor and less VRAM and CRAM. The attachments are there inside the original Mega Drive, but SoJ decided to cut memory in half at the last minute to save money. Had they even included a cartridge expansion there, they could've sold the VRAM expansion for $50 and also kept this machine alive on the market for at least two more years.
Goddamn. You have the most underrated retro youtube channel around as far as I'm concerned! Can I ask what your background is? Just wondering how you can get so in-depth with your retro development videos.
Thank you!! That means a ton! I'm an embedded systems engineer, B.S. in Electrical Engineering and working on an M.S. in Computer Engineering focusing in Microarchitecture and Scheduler design
Nah, he barely understands most of the words he says, this is how he does it, so he can pump out a lot of words with only a moderate effort. Like i find his suggestion that DMA peripheral in Megadrive would run in parallel to the main processor, letting it do something in the background absolutely hilarious - this is indeed how DMA works on more modern systems, but this is fundamentally at odds with cacheless processors of the time. And very little effort spent on unambiguous wording too. I mean, the problem with saying "8-bit PCM audio" had been pointed out before me... there's the PSG soundchip, that's got 4 channels, each 1-bit waveform and 4-bit volume, so that's 6-bit output or equivalent; then the Yamaha soundchip, i don't know its intermediate accumulator precision, it might be around 13 or 16 bit, with 9-bit output for each channel, in a time-interleave; and the 7-bit PCM samples as spoonfed by Z80, which go through and steal one of Yamaha channels. And it's evident enough that at least some of this complexity was more or less obvious to him, just not worded well enough.
@@ZygalStudios Damn. I've done embedded software development professionally and still do it for fun. And I can't get so much as a call back from all of these companies-- while they claim that they can't find people. I can find qualified, experienced engineers who are looking for work everywhere I go. Most of my friends have some kind of technical background.
Blast Processing is essentially marketing taking something that sounded cool when talking to an engineer that was trying to explain an actual technical thing that wasn't actually usable at the time. ^_^
Which realized in 1994 to 1995 when the snes dominate NA market shares due to donkey kong country and Nintendo marketing. Had they took the engineer advice seriously. The genesis would've never had its 94 to 95 market slump and stay competitive with snes and upcoming early 32-bit systems (jaguar and 3do).
@@maroon9273 I don't think that had anything to do with with people's thoughts on Blast Processing. That was kind of an odd connection you made there ^_^
@@dtester No, I'm talking western and 3rd party developers having the ability and resources of accessing its dma years earlier. Especially during the early 32-bit era. Also, when snes created quality games in 1994 and after to point it overthrew sega market shares in NA.
For "blast processing", Sega wouldn't have touted it, but the SNES Ricoh CPU would vary its clock-rate based on what it was doing, which was quite ahead of its time. But that would be something Nintendo would boast about if they wanted, and they didn't.
nice video dude..i have some question about a new arm chip, apple m1. i know a lot of youtubers has been made this video but i have a lot question how does apple became so efficient but also fast. how difficult to program on there?? because there's not a lot of documentation. and how about the amx and also why theres a lot of rumors spreading about the new one m1x/m2 while the developer not fully develop the apple m1?? and whats your opinion about apple m1??
For all things Apple M1, you'll have to ask Hector Martin. As to how it's fast and efficient? P.A. Semi is an engineering group that Apple purchased and their work has always been impressive, and it's a result of 20 years of cumulative work. It seems to inherit the the highly complex, out-of-order, heavily superscalar architecture similar to typical desktop chips, as opposed to being grown from simpler in-order designs gradually gaining out-of-order features, but it also has low-power simpler cores to be used when the full performance isn't needed, similar to basically all modern mobile chips. These are big chips. They're also being manufactured on a secret node that might be 5nm TSMC, which is just not really available to other companies, might have yield issues and is probably not economical. How difficult to program? Well from the application perspective, it's the same as basically any other ARMv8 chip, plus the usual Apple ecosystem; but as to system level intricacies, Hector would know.
I started writing a book on the ARM64 for those needing to drop into Assembly. ARM supported the idea initially, then nixed support without explanation.
Silly question, I know nothing about computers and stuff .. but could we take a Genesis - it's components - and add a hard drive and basically turn it into a computer (I know it's already a computer) but I mean would it be powerful enough to run windows 1.0 or DOS ? Weird question I know and I can't formulate it properly 😅
I mean in theory yes but you would need to write custom drivers for every new component you added. Then you would need a custom OS which would need to be coded. The Atari ST and Amiga were both based around the 68k and the Sharp 68k was too iirc
Golden Axe, Alien storm and Streets of rage 2 have 6 characters on screen at once with no slowdown, there is nothing at all like that on snes. PC engine often does beat sega in objects on screen though.
Except Atari didn’t do that. The Jaguar did get a 16 bit 68000 at some point in development but both of the custom chips it was designed around were true 32 bit processors. Because the system buss was 64 bits wide they claimed it was a 64 bit system, not because it had two 32 bit chips.
The Jaguar also had 64-bit RAM, blitter, and object processors, and that's where most of the work is done. Of course, using that metric, the Master System had a 16-bit Video Display Processor running at 11MHz.
amazing video plz continue , ,,,,i need your advice , in order to learn about the genesis hardware , what should i study..or read ??... ,,,,and can u plz remove the background music ,,next time ,it is quite confusing ...,,and can u make another video about the genesis hardware , explaining what each part do ,,,thanks in advance
My best advice to you for this is to get in touch with the Genesis/Mega Drive homebrew community through a site or forum. They will be able to provide the best insights at how to get a working environment set up so you can start developing. Now from a knowledge standpoint, get used to the instruction sets that the 68k and Z80 offer. That way, you can think about how to use them to design game code and how best to maximize instruction throughput for the best game experience. I appreciate the feedback :) I'd like to keep the music in, but I will lower the volume next time. Thanks for the encouragement as well! Stay tuned for more!
@@ZygalStudios Unfortunately, the two main forums still are not being administrated, and some of us have accounts that have been sitting in limbo for a year or more.
Yep. People often fail to realize the Mega Drive originally came out in 1988 in direct competition to the Famicom and PC Engine then 1989 in North America against the NES. That was the whole crux of the "Genesis Does What Nintendon't" campaign.
@@ZygalStudios cool thanks. I had seen that and forgot. Question now that the jaguar has fried your brain, what would it take to make a clone console? Can take this offline if needed, curious if it could be done.
@@ZygalStudios yes i know on the surface it at the moment is impossible however would like to know if clone hardware could be made like a retron box for genesis. Reason being is the systems are getting old, supply is limited and games are still being made. Hell it may sell more than the original hardware. Have some financial backing if you want to discuss further. What geek heros we would be if it was done trademarked and released.
@@Tolbat so I would say it's definitely not impossible, just a good amount of work lol. This system could probably be modeled with some SoCs. The trouble is getting to operate is exactly the same. Most/All timing characteristics would have to be the same as the original system. It's possible, just would require lots of time, talent, and persistence:)
I didn't like the wide button layout of its controller. Three buttons vertically across? What is this, arcade? It's dumb for a controller you hold in your hands. The buttons should have been in a triangle style, let's face it. It also was too annoying to have to hit the start button, especially with games like MK. Yes other controllers came out later, but that just was hard to enjoy. Same issue far later with the original x-box controller, with those far down black and white buttons.
odd for as smart as you are you did not find an answer to what blast-processing is. you just about described it when explaining the hardware spects. specific hardware data operations of the VDP, DMA and bandwidth combination unique about the Genesis console is what SEGA quoined as blast-processing. similar to the S.N.E.S. unique hardware/software process of scaling + rotation being labeled at number 7 among its modes of operation has nationally quoined "mode-7" to be the term for its scaling + rotation method of operation. whereas now many dunce hats think scaling + rotation is mode-7 any time they see that on screen by whatever computer or console applies that. mode-7 is only a S.N.E.S. thing. scaling+ rotation is scaling+ rotation and blast-processing is only a SEGA Genesis thing.
You’re not wrong to say it was called the Mega Drive in Japan, but it was actually called the Mega Drive everywhere outside of Canada and the U.S. (eg. Europe, Australia, etc.).
He is wrong as it was developed and conceived in Japan as the Mega Drive and only known in America as Genesis
The 68000 is a transitional processor, that is clearly designed to be competitive with other typical 16-bit processors, but it also has 32-bit registers as what seems like a future proofing attempt, so when future systems would need to transition to 32-bit, they can remain software compatible, to some extent both ways. Really most instructions only operate on 16 bits to conserve the number of memory transfers and computation, and considerable effort went into cutting down the amount of extra hardware required for 32-bit to almost nothing.
Compare and contrast say 8088, a 16-bit processor designed to be integrated into 8-bit systems; or 386SX, a 32-bit processor designed as a drop in replacement for 16-bit systems. Obviously neither of these are particularly efficient at the operation at the maximum operand width. It was also common to see 64-bit processors used in systems where actual 64-bit operation wasn't really the desired goal, like PS2 and N64.
On Megadrive/Genesis, the DMA peripheral stops the 68000 CPU whenever DMA is running. However it's still a net advantage, since it can copy data much faster than 68000 could hope to manage! It's also pretty much necessary since the video memory isn't double buffered, so for the elements that are currently being displayed, you can't just overwrite them as you're preparing the data for next frame, you have to prepare the data in a separate buffers in main RAM while the previous frame is being scanned out by the VDP, and then QUICKLY transfer these buffers from main RAM during the blanking period.
The processor has to be stopped, since the system doesn't have multi ported main RAM or cartridge, the main RAM and cartridge ROM are just slow enough for the processor, and the processor doesn't have any cache or scratch RAM, so while it's disconnected from RAM, there's nothing that it could possibly sensibly do! The advantage of DMA peripheral is that it only needs to deal with the data, it doesn't have to fetch a 16-bit instruction every time a 16-bit chunk of data needs to be transferred. Additionally, since the processor sits on the main bus, it would necessarily consume at least 3 main bus IO cycles synchronised with main RAM and cartridge bus per transfer, so instruction read, operand read, and then operand write; and that fully unrolled, not counting control flow. DMA peripheral however sits inside the VPU, so it doesn't need an operand write cycle, since the write is internal, it only needs a read on the external bus. So DMA is at least trice as fast.
Actually most systems of the era made use of cycle stealing, where whatever device held memory, would just stop the CPU clock whenever it needed to do the memory transfers, and as the name implies, as opposed to DMA here, it was just for several cycles at a time. There wasn't really much design room for a more fine grained protocol that would allow for a higher hardware utilisation!
It's difficult to say why the Z80 was included. It seems that Master System backwards compatibility was a design consideration from the start, Z80 was cheap enough, and would be needed for that anyway; and while it's already there, it might as well take over audio tasks, it's usually used to program the synthesizer soundchip registers, and also manually handfeed samples to the optional DAC channel of the Yamaha soundchip. Obviously had they chosen to forgo Z80, they'd just need some sort of FIFO buffer or an extended asynchronous DMA peripheral to do digital PCM audio. I think some modern productions use 68000 to do most audio stuff, instead dedicating z80 to mix and pump several PCM channels or achieve higher PCM sample rate.
In my mind, TI PSG chip was never physically present as a discrete component, integrated into the VPU or the jungle chip instead, as Yamaha's reimplemented version with a different noise pattern.
Also very, very few developers on the system actually wrote any Z80 code, choosing to use SEGA's provided tooling GEMS instead which included the audio driver code and was a complete MIDI based authoring solution.
68000 has 32 bit registers to address more then 128kiB or 64kiB if you want byte granularity. Anything not 2^2 is odd. You want segments? Also to keep the register file in proportion to all the microcode, 32 16bit register would be okay. Then just pair them up like on 8088. I don't think you've got to get philosophical on this one.
Cycle stealing sounds so mean. What about the fact that the 68k and the z80 have a phase where they think for themselves and don't need any cycle? Funny how many computers were able to fit their other memory needs (DRAM refresh for z80, video refresh for AtariST) into these slots.
@@ArneChristianRosenfeldt but there's only 23 pin (effectively 24 bit) address! Apparently going 32 bit was cheap enough though in terms of complexity, and gave it that extra elegance and flexibility. Fundamentally nothing prevented them from doing 24bit registers though. As to whether I want segment addressing is not the question, that's the design 16 bit processors simply tended to go with. 8-bit processors also have special handling for addresses to accommodate 16-bit address space, and it was 'fine' for what it was.
Z80 has built in DRAM refresh logic. It's partially used on the Spectrum for extended RAM (the optional 32k) while the 16K are refreshed passively by video scanout. I don't know how DRAM refresh works on ST, I'll learn about it.
Fundamentally though you have to roll with the memory timings you're given, and the high capacity ROM available for cartridges wasn't very fast. So while you can expect to have 100ns RAM easily, most megabyte capacity ROM of the late 80s when Megadrive came out could be expected to be like 450ns. Megadrive mandates something like 200ns ROM for the cartridge. But it's all the same bus and ROM accesses are necessarily very abundant on Megadrive.
Soooo 🤔 if another 32kb of ram was throw in there.. would that have fixed a lot of the issues the genesis had that Devs saw as short coming s .?????????
@@48hourrecordsteam45 I don't see how it would, and what shortcomings?
@@ArneChristianRosenfeldt My laptop has 20 GB of RAM, and many systems have odd integers of 64KB. Many graphics cards in the 90s had 6MB or 12MB of VRAM.
Unbelievable, one of the only approachable videos going over the sega genesis architecture! Awesome job, gladly subbed!
The Z80 was also for maintaining backwards compatibility with Master System games. The Mega Drive was internally referred to as the Mark IV as the continuation from the Mark III/Master System. Coupled with the SN76489, there's still a Master System at it's foundation. And as it came out in 1988 in Japan, it was competing with the Famicom and PC Engine then in 1989 in North America against the NES. That was the whole crux of the "Genesis Does What Nintendon't" campaign, it was their new 16-bit machine against the aging 8-bit NES but SEGA still struggled to make headway because of Nintendo's grip on the market and third-party licensees. There was no "Console War" until 1991 after the FTC forced Nintendo to cut out their shit and make it a more fair for competitors, that's when SEGA cut the price of the Genesis to $150 and packed in Sonic the Hedgehog to counter the launch of the SNES then took half the market for a window of time.
Regarding "Blast Processing" - I think I remember reading an interview with one of SEGA USA's devs who said he had mentioned "blasting data directly to the VDP" and one of the marketing guys overheard him and had a eureka moment - Blast Processing was born.
Scott Bayless was talking about using the DMA to "blast" data from the ROM to the VDP without having to use the 68000.
Sure, but they should have called it "blast transferring".. because a DMA isn't "processing" anything. It's transferring data.
@@TurboXray Real and true. But it aint got the same ring to it hahaha
Great work! It would be interesting to make a video about the NeoGeo, specially as it shares many similar hardware components as the Genesis/MD. It was so ahead from others consoles of its time by relying most only on sprites and huge cartridges but would be nice to see how that was achieved.
Blast processing was basically a catchier name for DMA, more marketable. During transfer the 68k CPU is frozen making it only viable during VBlank, while the Z80 is unnafected unless it needs to access the bus. This was a faster method of moving data from ROM or RAM to VRAM/CRAM/VSRAM and didnt require special code to send it via the data port. This made it quicker than the equivalent 68k instructions that achieved the same result.
Anyone that asks is it really that impressive a feature? From experience, yes. You can dma new tiles graphics, scrolling, animation, fading.. and its fast and easy.
And I have just noticed this video is 3 years old and I have added precisely nothing that wasn't already in the comments... its one of those days!
Huh… I thought the Z80 was included for backwards compatibility first and foremost. It was certainly used in that capacity. Interesting.
Of all the console wars, the 16-Bit War was the best. Not only do we get the best consoles of the time but the best games unique to those platforms too.
The best I could find based on internal statements from the time:
Blast Processing meant using the DMA to burst transfer data from game ROM to the DAC (Digital Analogue Converter), saving the CPU some clock cycles to do other things.
Is that really a big advantage? At the end of life, it was. The Genesis was still able to free up about 1 MIPS from the 68000 CPU to handle some audio and video effects in software allowing it to play DOOM and Wolfenstein like stages and add a bit of flare to Aladdin, Toy Story, and some arcade ports right before SEGA of Japan murdered the system (with its dominating 55% market share in North America). Megadrives were better than their contemporaries because you could eventually get all five chips running and doing useful work at the same time, and because the VDP left in all sorts of sprite and color hacks that made these late games possible.
Huh.. so blast processing was marketing speak for a DMA loading technique 🤣
That's interesting!
Definitely has its advantages in this case.
@@ZygalStudios The term "Blast Processing" came about after an engineer tried to explain DMA techniques to marketing. So while it is a marketing term, it is referring to something which the Genesis excelled at... very fast DMA transfers, to various RAM. Not just from ROM to DAC.
@@AlexvrbX this is probably the best explanation I've seen so far. Thank you!!
There was a lot of parallax scrolling and some impressive art and animation as early as 1992 under the Kalinski team. Hell, Sonic 1&2 hacked the hardware a lot.
@@ZygalStudios And if SEGA had released a 12MHz 68EC030 + 😮SVP "Genesis32" like I've suggested, then it would've cost less than the 32X, been easy to bring games over (using the 3D or sound), and kept the Genesis alive for another year or two. As important, with the onchip caches, that would take some demand off the system bus and allow much faster DMA transfers for 3D graphics.
6:02 Lol the Genesis/MD' 32/16-bit CPU was clocked literally OVER TWICE AS FAST as the 16/8-bit CPU in the SNES! (≈7.6MHz vs ≈3.5MHz) "A little bit faster"? Get real... The Genesis/Mega Drive absolutely CRUSHED the SNES in raw CPU performance! And the game library reflected this! (Action & sports games). It's the custom graphics & sound processors that made the SNES special, and the games reflected that too. (RPG's, platformers).
On top of that the SNES CPU had to slow down even more to access RAM, and some cart ROMs were "slow" ROMS slowing things down again!
Yes, thank you for pointing this out. When I said "A little bit of a clock speed advantage", thinking on a smaller scale than what I'm typically used to, didn't seem like all that much. But yes, it is a major difference and benchmarks prove that! The genesis is far more efficient at processing for raw computation.
However, I want to address something that can be a bit misleading in this context.
Clock speed isn't always indicative of CPU Performance. There are far more factors involved in the design of a processor than just the speed of the clock that effect overall processor performance. Your comment seems to have two sides to it. In this case, the clock speed difference is so overwhelming that it does make a significant difference, but this isn't always the case as gaps of clock speeds start to shrink. Amdahl's Law is a great reference to how to look at some of these things comparatively from a high level.
@@BenHeckHacks That whole "variable speed bus" approach on the Ricoh 5A22 is wild to me. That may be a future video topic on how that works!
The Genesis CPU was rated at 1.2 MIPS. The 6502 in the NES ran at 0.5 MIPS, slightly slower even than the anemic Z80 in the Master System. The SNES used a 16-bit version of the 6502 which officially boasted 1.5 MIPS or a theoretical 1.8 MIPS, though never matched the 68000 because of a lack of registers and memory access bottleneck. They were relatively close in performance.
@@MaxAbramson3 "The 6502 in the NES ran at 0.5 MIPS, slightly slower even than the anemic Z80 in the Master System." Don't think so. NES 6502 clocked at 1.789mhz is ~0.720 MIPS. Master system z80 @ 3.58mhz is ~0.520 MIPS. But it's not even that. 6502's direct memory access and free indexing as well, makes it much more performant than the z80. The 65x design isn't hurt by the lack of general purpose registers because it has fast direct memory access. And for indirection (address "registers" or vectors), it literally has up to 128 "address vectors". The bottlenecks on the z80 are because of its limited register set (needed for the lack of direct addressing modes), and it's a bottleneck compared to the 65x design. As well as the 65x isn't constantly needing to push/pop from the stack like the z80 constantly is. What the 65x carries over in relation to competing with the 68k, is the 68k has ZERO benefit from 8bit operations. And it has a fairly high overhead for instruction cycles FOR some instructions that offer little performance bang for the buck (support instructions; test, jsr, rts, etc). This is how the 65x can pull up to the 68k, and a 5mhz '816 would literally destroy a 7.6mhz 68k.
I've coded and cut my teeth on these processors in assembly. The whole MIPs thing is fun to look at, and tells you something about the arch/ISA design, but it's mostly useless for direction comparisons. The only thing it really tells you - is the difference in architecture between the 65x (and 6809) and the 68k. I found that some of the worse people to talk about performance across different processors.. are people that mostly/only coded for the 68k. They can't wrap their mind around anything that isn't a 68k design. 65x is an "accumulator" processor design - fast simple instructions with fast direct memory access. To them, that's a bottleneck. They don't understand the optimization part that goes along with that. The z80 is a hack of a "accumulator design" but with MOST of the advantages taken away and more bottlenecks thrown in. The 68k design was literally designed with the purpose to keep it OFF the bus. That's why it has a grip load of registers for its time. Because on "real" systems, you're going to be sharing the bus - the 65x/6809 are just bus hogs (and require 4x the speed of ram than the 68k) and not just not scalable. The 68k totally excels in what it was designed for. But in a game system, the 68k loses a lot of that edge and design. The 65x design picks it up because supporting hardware takes away most of the need for the more powerful 68k instructions.
I can also tell you the Genesis CPU is NOT running 1.2 MIPs. That would mean the average instruction is ~6.3 cycles. THAT is a laugh. About 12 years ago, we ran genesis games with a MIPs calculator in the emulator.. and it was around ~0.710 MIPs. No Lie. It doesn't tell you the performance, but it tells you the instruction cycle length is pretty slow.
9:10 should read YM2612 and outputs 53Khz. It has a 9bit onboard dac.
It has six channels each with 4 sine wave ‘operators’ with 8 possible ‘algorithms’. A pcm mode for channel six and an independent lfo signal, assignable to any attribute/s across the channels.
The design is a paired down DX7 FM design but the DX7 has 12bit output, 6 operators and 32 algorithms.
The TI sound chip is 3, square wave, 3 octave tones (I think) and a noise channel which can combine with another channel to generate noisy tones. All four together can output a sample.
The YM2612 generates very clean audio with a wide bandwidth (bass to treble) but the 9bit fav caused digital noise which is fairly noticeable if you know what to listen for.
Around 200 games used the GEMS driver. Most sound bad. The reason is that the default patches (instruments) were somewhat hastily designed and the author of the driver assumed that composers would apply tweaks to the instruments to polish them up a bit but this happened quite rarely.
Composer Spencer Nilsson did a bang up job with Ecco the Dolphin and Nathan Grigg for Demolition Man but the majority fell flat.
The problem was in the nature of the MIDI standard. 128 patches was standard. So any midi device recognises what any instrument should be in the 128 instrument bank and the instrument will do its best to replicate, say, a marimba for patch 12. So any composition should theoretically sound correct played from any midi compatible device.
But this is extremely limiting when you consider the possibilities of fm synthesis with an additional lfo. You are drawn into a corner of writing in individual notes and ignore that an fm system can generate an envelope of sound, altering a range of characteristics across the duration of the note or even not have a specific begging or end.
I’m going off on one but GEMS, many of you may know is infamous for giving the chip a bad name. It was the equivalent of playing back a midi tube one windows 3.1. There is a somewhat jangly staccato sound to notes starting and stopping so abruptly and with such basic shapes.
I think it’s more accurate to say that US developers struggled with the Z80 and FM technique who never programmed a Spectrum or Amstrad CPC.
You will find that games using GEMS would come from that region, whearas the UK has the Krisalis sound driver available or otherwise created exceptional music such as Tim Follin and Matt Furniss.
To hear the chip being put through its paces, the Technosoft developed Thunderforce 4 soundtrack is recommended.
But the lost is endless. Skeleton Krew and Bram Stoker’s Fracula are also examples of how a midi implementation falls quite short of the full utilisation of this chip by more technically minded chip tune musicians.
Disclaimer: this information is probably about 90% correct.
It makes me wonder if it was really so much of a stretch to just have 256B of cram, could have easily doubled the colours. But video games were still seen as a niche industry at the time so maybe it wasn't worth the risk.
Wasn't the Blast Processing thing a marketing term about the faster CPU? They were all about how the Genesis was 16 bit and was just like the arcade
DMAing data straight from the ROM cart to the DAC without having to.use the CPU.
I have heard the Sega Genesis was a very easy platform to develop for. The consoles power was easy to get to and given how it was built most arcade developers should have felt right at home.
It's easy so long as you're not trying to push the machine to its limits. Developers with 3-4 years of experience were able to get that machine to crank out impressive 2.5D and even flat shaded polygon graphics to rival powerful arcade hardware of 1990-91 era. Some of us are even working on DOOM for the machine and are up to 4-5fps.
@MaxAbramson3
Holy...Doom?! That's freaking awesome man. I have a question no one has ever given me an answer to. You just might be the guy to know the answer. If not, or if you don't feel like it or whatever, that's cool to man. Here goes...
Would the Sega CD be able to run a port of Doom with its ASCII chip and second 68K processor? Seeing some of the games running on it... like Soulstar, make me think it could have done it. Now, I'm not, of course, talking about a 1-to-1 port of the PC here or even the 32X retail release version. I'm thinking better than the Snes with ceiling and floor textures, windowed, and at a 15-20 FPS. I would also expect simplified geometry and maybe maps that are cut with loading screens, perhaps.
@Sinn0100 Using the ASIC DSP for floors and ceilings, 256x128, maybe 15-20fps. More likely a 8-15MB cartridge with the CD-ROM holding cut scenes and/or music. It's possible that we could simply load all of the textures and enemies for a stage into the 256KB of work RAM, then use the scaling feature of that ASIC DSP to scale and warp walls. That would get us to 15-20fps, though not consistently.
@MaxAbramson3
That is awesome! Thank you for answering that question!
0:06 it's not also known as the Sega Mega Drive. It's also known as the Sega Genesis.
All of the world except North America had the Mega Drive and it would have been called the Mega Drive in NA as well if there wasn't licensing issues.
Well there was Korea too where it was localized, so the full and factual way to say it is:
The Mega Drive, also known as the Genesis in North America and Super Game Boy/Super Aladdin Boy in Korea.
It was created as the Mega Drive and only renamed because of a livencing issue so it doesn't change what the console is called universally.
If there were big companies in NA named Dreamcast and PlayStation, the consoles would still be called Dreamcast and PlayStation even if they were localized Sega Leviticus and Sony Exodus in North America.
I would love to see a video that describes the creation of the Mega Drive, drawing board to shop shelf. In particular, what was envisioned and what actually came to be.
Great video, thank you.
Well for one thing the VDP was intended to use a second 64k block of VRAM The pins still exist on the package, but were not connected to anything. There is an undocumented interleave mode in the VDP that would have allowed for video writes to be twice as fast by writing to both at the same time. In this mode sprites and tiles are spread across both banks of VRAM. The VDP also has pins for external color RAM that are also not connected to anything that would have allowed for more color pallets. The C2 arcade board which uses the Megadrive VDP as well as a 12Mhz 68000 and no Z-80 actually uses those features of the VDP and had something like 16 color pallets instead of 4.
@@atomicskull6405 Yes and apparently Team Titan found some unused commands which allowed for some form of hardware scailing with Mega Drive’s ($C0001C) debug register. Also, the mega drive can have 2 MB installed on the board and the system will recognise it and can use it if software was made to take advantage of it, apparently the mega drive always sees the 64KB as 2MB any way, or something like that. I did know that original design specs were to have 128KB of system ram, that would of been amazing if it was to come to the shelves like that. Back to the 2MB, there is one ROM that would see it if you were to install the memory, MEGA OS, that tech demo OS, that can actually see the system RAM, so it would be nice to try that.
@@notsuoh16Bit 128KB of video RAM, but Sega of Japan pared that back to 64KB of VRAM at the last minute to save money. So SEGA could've released an upgraded Genesis with a 12MHz 68EC000 CPU (or 68EC030 with caches to take some of the pressure off the system bus), 12MHz Z80 sound chip (3.5x faster), up t 2MB of RAM, 128KB of VRAM, and another color mode on the VDP similar to the Saturn, making it easier to develop 2D games for both systems. Worse, this could've been released for Christmas of 1993, would've been more powerful (in some ways) than the Jaguar, made the 32X unnecessary, and existing games would've played much better on the 12MHz Genesis. They might've even been able to add Virtua Racing's 23MHz SVP to avoid the Lock On cart patent issue that kept the $49.99 unit from coming out.
For existing Genesis owners, a swap-the-box would've cost around $100-120, much less than the 32X.
Update: This would've made life EASIER for game developers, since their 1994-95 games that wouldn't quite run on a 7MHz Genesis would now run fluidly without a rewrite. Existing Genesis owners would only be out $100, and new buyers could get a complete system for about $130--perhaps with Daytona USA as the pack in.
@@MaxAbramson3 This is very interesting and I agree.
They came up with good specs, then went "full retard"
Mega Drive in Europe, too. Blast processing: more MHz on processor, faster scrolling.
Blast processing was a marketing term based solely on the literal processor speed to explain why Sonic was so fast. Lived through this.
It was based on a description of the direct color trick the SoA tech director figured out, but the marketing people undoubtedly didn't understand that anyway.
@dogen While that is the story we get nowadays. Like Joe stated, at the time it was advertised as a way of saying that the genesis had faster more Xtreme games than the SNES. No game showed or even made at that time used the burst feature that was later described. I think once they got called out on it they just searched for some explanation.
It was a marketing term to describe the DMA transfer from the ROM cartridge directly to the Digital to Analog Converter (DAC). The CPU did not need to be externally interrupted in order to perform these data transfers around the system.
I wish the genesis had better expansion support by connecting the pins to its hardware to the expansion and cartridge for future enhancement purposes which would've axed the need for the 32x add-on alongside using its dma years earlier like the japanese developers.
...... what?
@@KungKras128KB of VRAM and additional color RAM like the C2. The Genesis could've displayed 4,096 out of 98,000 colors and had twice the bandwidth.
@@MaxAbramson3How?
With a new VDP in the expansion slot?
@@KungKras System 16 was just a C2 arcade board with a slower processor and less VRAM and CRAM. The attachments are there inside the original Mega Drive, but SoJ decided to cut memory in half at the last minute to save money. Had they even included a cartridge expansion there, they could've sold the VRAM expansion for $50 and also kept this machine alive on the market for at least two more years.
@@MaxAbramson3But aren't the colour limitations literally etched into the VDP's silicon?
Goddamn. You have the most underrated retro youtube channel around as far as I'm concerned! Can I ask what your background is? Just wondering how you can get so in-depth with your retro development videos.
Thank you!! That means a ton!
I'm an embedded systems engineer, B.S. in Electrical Engineering and working on an M.S. in Computer Engineering focusing in Microarchitecture and Scheduler design
Nah, he barely understands most of the words he says, this is how he does it, so he can pump out a lot of words with only a moderate effort. Like i find his suggestion that DMA peripheral in Megadrive would run in parallel to the main processor, letting it do something in the background absolutely hilarious - this is indeed how DMA works on more modern systems, but this is fundamentally at odds with cacheless processors of the time.
And very little effort spent on unambiguous wording too. I mean, the problem with saying "8-bit PCM audio" had been pointed out before me... there's the PSG soundchip, that's got 4 channels, each 1-bit waveform and 4-bit volume, so that's 6-bit output or equivalent; then the Yamaha soundchip, i don't know its intermediate accumulator precision, it might be around 13 or 16 bit, with 9-bit output for each channel, in a time-interleave; and the 7-bit PCM samples as spoonfed by Z80, which go through and steal one of Yamaha channels. And it's evident enough that at least some of this complexity was more or less obvious to him, just not worded well enough.
@@SianaGearz I'm not sure if you're kidding or just being rude
@@ZygalStudios Damn. I've done embedded software development professionally and still do it for fun. And I can't get so much as a call back from all of these companies-- while they claim that they can't find people. I can find qualified, experienced engineers who are looking for work everywhere I go. Most of my friends have some kind of technical background.
The 68000 was also used in the Atari ST and the Amiga
Blast Processing is essentially marketing taking something that sounded cool when talking to an engineer that was trying to explain an actual technical thing that wasn't actually usable at the time. ^_^
Which realized in 1994 to 1995 when the snes dominate NA market shares due to donkey kong country and Nintendo marketing. Had they took the engineer advice seriously. The genesis would've never had its 94 to 95 market slump and stay competitive with snes and upcoming early 32-bit systems (jaguar and 3do).
@@maroon9273 I don't think that had anything to do with with people's thoughts on Blast Processing. That was kind of an odd connection you made there ^_^
@@dtester No, I'm talking western and 3rd party developers having the ability and resources of accessing its dma years earlier. Especially during the early 32-bit era. Also, when snes created quality games in 1994 and after to point it overthrew sega market shares in NA.
@@maroon9273 still seem weird but ok ^_^
Thanks for this!!
Df retro explains blast processing.
How much was 'hard to work with' regarding the Saturn a matter of the switch from 2D to 3D games?
For "blast processing", Sega wouldn't have touted it, but the SNES Ricoh CPU would vary its clock-rate based on what it was doing, which was quite ahead of its time. But that would be something Nintendo would boast about if they wanted, and they didn't.
Your videos are amazing
Subbed - keep up the interesting content.
nice video dude..i have some question about a new arm chip, apple m1. i know a lot of youtubers has been made this video but i have a lot question how does apple became so efficient but also fast. how difficult to program on there?? because there's not a lot of documentation. and how about the amx and also why theres a lot of rumors spreading about the new one m1x/m2 while the developer not fully develop the apple m1??
and whats your opinion about apple m1??
For all things Apple M1, you'll have to ask Hector Martin. As to how it's fast and efficient? P.A. Semi is an engineering group that Apple purchased and their work has always been impressive, and it's a result of 20 years of cumulative work. It seems to inherit the the highly complex, out-of-order, heavily superscalar architecture similar to typical desktop chips, as opposed to being grown from simpler in-order designs gradually gaining out-of-order features, but it also has low-power simpler cores to be used when the full performance isn't needed, similar to basically all modern mobile chips. These are big chips. They're also being manufactured on a secret node that might be 5nm TSMC, which is just not really available to other companies, might have yield issues and is probably not economical. How difficult to program? Well from the application perspective, it's the same as basically any other ARMv8 chip, plus the usual Apple ecosystem; but as to system level intricacies, Hector would know.
@@SianaGearz thank you
I started writing a book on the ARM64 for those needing to drop into Assembly. ARM supported the idea initially, then nixed support without explanation.
Silly question, I know nothing about computers and stuff .. but could we take a Genesis - it's components - and add a hard drive and basically turn it into a computer (I know it's already a computer) but I mean would it be powerful enough to run windows 1.0 or DOS ? Weird question I know and I can't formulate it properly 😅
I mean in theory yes but you would need to write custom drivers for every new component you added. Then you would need a custom OS which would need to be coded. The Atari ST and Amiga were both based around the 68k and the Sharp 68k was too iirc
It is very similar to the Amiga 500 in terms of processing power but lacks the RAM needed to run disk based software.
SEGA almost did that and had a keyboard, mouse, and floppy drive ready for this, almost like an Amiga.
What would happen if you replace the Turbografx 16 cpu and put the Motorola 68000 cpu same as the one in the Sega genesis.
TurboGrafx ala pc engine used a 6502 clone like the original NES/famicom . Totally different architecture. Many arcade systems used the 68000
@@FadkinsDiet NEC should have went with the 68000 cpu instead of the 6502 clone cpu. Are just make a 16 bit cpu for the Supergrafx.
The Sega Genesis is more powerful then you think
Golden Axe, Alien storm and Streets of rage 2 have 6 characters on screen at once with no slowdown, there is nothing at all like that on snes. PC engine often does beat sega in objects on screen though.
Shouldn't the Genesis be a (16+24+32bit) system if we calculate it the Atari Jaguar way.
Except Atari didn’t do that. The Jaguar did get a 16 bit 68000 at some point in development but both of the custom chips it was designed around were true 32 bit processors. Because the system buss was 64 bits wide they claimed it was a 64 bit system, not because it had two 32 bit chips.
The Jaguar also had 64-bit RAM, blitter, and object processors, and that's where most of the work is done. Of course, using that metric, the Master System had a 16-bit Video Display Processor running at 11MHz.
amazing video plz continue , ,,,,i need your advice , in order to learn about the genesis hardware , what should i study..or read ??... ,,,,and can u plz remove the background music ,,next time ,it is quite confusing ...,,and can u make another video about the genesis hardware , explaining what each part do ,,,thanks in advance
My best advice to you for this is to get in touch with the Genesis/Mega Drive homebrew community through a site or forum. They will be able to provide the best insights at how to get a working environment set up so you can start developing. Now from a knowledge standpoint, get used to the instruction sets that the 68k and Z80 offer. That way, you can think about how to use them to design game code and how best to maximize instruction throughput for the best game experience.
I appreciate the feedback :) I'd like to keep the music in, but I will lower the volume next time. Thanks for the encouragement as well! Stay tuned for more!
@@ZygalStudios Unfortunately, the two main forums still are not being administrated, and some of us have accounts that have been sitting in limbo for a year or more.
You got one thing wrong, the genesis was a competitor to the NES, not the SNES. It wasnt till the snes came out that things changed
Yep. People often fail to realize the Mega Drive originally came out in 1988 in direct competition to the Famicom and PC Engine then 1989 in North America against the NES. That was the whole crux of the "Genesis Does What Nintendon't" campaign.
Do this for the Atari Jaguar please
Already did :) it was the first one I did!
Check it out!
@@ZygalStudios cool thanks. I had seen that and forgot. Question now that the jaguar has fried your brain, what would it take to make a clone console? Can take this offline if needed, curious if it could be done.
@@Tolbat Clone as in hardware emulation?
@@ZygalStudios yes i know on the surface it at the moment is impossible however would like to know if clone hardware could be made like a retron box for genesis. Reason being is the systems are getting old, supply is limited and games are still being made. Hell it may sell more than the original hardware. Have some financial backing if you want to discuss further. What geek heros we would be if it was done trademarked and released.
@@Tolbat so I would say it's definitely not impossible, just a good amount of work lol.
This system could probably be modeled with some SoCs.
The trouble is getting to operate is exactly the same. Most/All timing characteristics would have to be the same as the original system.
It's possible, just would require lots of time, talent, and persistence:)
Pfft a little more? More than double
Nice video, but you completely lost me... you have so much knowledge.
I didn't like the wide button layout of its controller. Three buttons vertically across? What is this, arcade? It's dumb for a controller you hold in your hands.
The buttons should have been in a triangle style, let's face it.
It also was too annoying to have to hit the start button, especially with games like MK.
Yes other controllers came out later, but that just was hard to enjoy.
Same issue far later with the original x-box controller, with those far down black and white buttons.
"were easier to be made" ? You mean the architecture allowed them to be made easier? :p
That and development support was available :)
Love the videos, though!
odd for as smart as you are you did not find an answer to what blast-processing is. you just about described it when explaining the hardware spects.
specific hardware data operations of the VDP, DMA and bandwidth combination unique about the Genesis console is what SEGA quoined as blast-processing.
similar to the S.N.E.S. unique hardware/software process of scaling + rotation being labeled at number 7 among its modes of operation has nationally quoined "mode-7" to be the term for its scaling + rotation method of operation. whereas now many dunce hats think scaling + rotation is mode-7 any time they see that on screen by whatever computer or console applies that. mode-7 is only a S.N.E.S. thing. scaling+ rotation is scaling+ rotation and blast-processing is only a SEGA Genesis thing.
Good try but super vague
turn that garbage background music off.
CPU benchmark MD vs TG vs SNES
MD lying
ua-cam.com/video/2k_jP73Ly7A/v-deo.html
Please do more nes SNES turbo neo Geo !
Plans are in the works :)