When the megadrive 1 was released in japan the expansion connector where you put the megacd on was already built in. So, was it from the beginning planned to expand the hardware someday or did sega made an expansion port just in case of ?
Printable View
When the megadrive 1 was released in japan the expansion connector where you put the megacd on was already built in. So, was it from the beginning planned to expand the hardware someday or did sega made an expansion port just in case of ?
Good question....
...
...
Nope, extention such like segacd wasn't planned.
What was planned was things like external FDD / CDROM drive. But never a "side system".
The whole design is very bottlenecked because the extension port is very small (256KB x 2) and only one direction (md>extention).
With only a few more signals going through extention port they could have made a setup a LOT more effective... But they didn't, means no planning for such things.
Same issues occurs for 32x, was never planned.
yeah its sort of like how sega put an extra 44 blocks of memory in the dreamcast vmu's that were never used, it (like the sega genesis expantion port) was just for a little "headway" down the road.
Fonzie, that's something that always baffles me. Why make the expansion port if you're not gonna optimize it for going the extra mile, in case you choose to make an add-on system for said expansion port.
Obviously making the cartridge port optimized for use with an add-on system would have been ridiculous, so that's beside the point. We all know the 32X should never have existed.
you could argue the mega cd should have never been since the games look pretty much the same and the 32x should have gone on the side making it a better looking system + 1 less wire and maybe it would have been more succesful that way. ok im just talking silly but you could argue it either way and the mega cd wasnt all that golden most of the time lots of lazy ports of games you can already get on the megadrive.
How limited is the expansion port?
If the Sega CD increased the color palette. Would you need an external cable like the 32x does? Or would the expansion port have been able to do it without an external video cable?
Yes, you'd still need the cable as the video doesn't go to the expansion port. They really should have... along with ALL the CPU signals. They really screwed the pooch when they designed the side expansion slot. Must have been an ex-Microsoft employee that did that part. You know how they are about computers NEVER exceeding certain bounds in the future. ;) :DQuote:
Originally Posted by Eric83
The Expansion port seems like a barely usable floppy/CD connection... (FDWR and DISK signals come to mind)
They should really used the pixel output from the VDP... Man that way the MD could have 15/16/24 bits of color selection along with 8 palettes and possibly more with palette banking (awesome $hit right there) . Damn... But no they sucked big time using the crippled VDP CRAM/DAC, and worse: a 9 bit f_cking serial shift register to select the bank to the Z80 (wtf were they drinking!?)...
Sega failed a lot in the hardware department of the MD.
Yeah, the MD is nice, but it's really just a Master System with a 68000 tacked on and a minor enhancement to the VDP. There's a BUNCH of things they could have done that would have made it far better - like not using a serial port for the Z80 bank. That was REALLY stupid and is a major limit on how useful the Z80 is. Giving two banks instead of one would have also been far better. The 68000 and ram is okay, but they should have made it where the 68000 could access VRAM at any time. That would have made that far better.Quote:
Originally Posted by Jorge Nuno
The reason the Exp. Port feels like a floppy drive connector? It was meant to be one, as some early sketches show, along with a keyboard and an tape deck or something else weird and VERY late 80s.Quote:
Originally Posted by Jorge Nuno
I never saw those sketches, I made my assumption from the signals' names presented on the port.
That's sad... I always laugh at any attempts to make a game console into a computer. One example that comes to mind is the ColecoVision and ADAM computer...Quote:
Originally Posted by Enigmus
The 32x was a lot better off though, the cartridge connector is far more capable than the expansion connector. (address space, signals avaialble, etc)Quote:
Originally Posted by Fonzie
Yeah, with no YS, you couldn't support video overlay if you wanted to. Too bad the expansion connector wasnt just an auxiliary cartridge connector. (isn't that what the SMS did for it's EXP port? -I think a drawback on the SMS was that the exp port couldn't support a plug-in YM2413 like the Mk.III, that would heve been great -particularly since nothing even used that expansion)Quote:
Originally Posted by Chilly Willy
Even so they probably could have just omitted the expansion connector alltogether and used the cartridge connector for the CD instead (with a layout more like the Jaguar's top loading CD with passthrough cartridge slot), maybe even cheaper with that configuration (top loading drive), but FCC approval might have been more of an issue.
Or they could have omitted the exp port entirely and added the pixel bus to the cartridge port as well, then using only the cart slot for peripherals. (and maybe even allow some cartridges to take advantage of that with onboard hardware)Quote:
Originally Posted by Jorge Nuno
Having the RGB signals as well would have meant no need for external video mixing as well.
They could have set it up with outboard pins on the cart slot, like SNES, to avoid rasing costs of standard cartridges. (and trade some cost with the expansion connector removed, or maybe just putting the necessary signals and increased addressing on the expansion connector would be preferred -though that removes the enhanced cartridge possibility)
With YS and the pixel bus I think you could do the dual VDP idea Chilly Willy proposed. (2 genesis VDPs, supporting overlay, both in a Supergrafx manner and capable of combining pixels to have 8-bit palettes -256 colors with an external RAMDAC supporting a larger palette as well) And with RGB on the connector as well, no mixing cable either!
I think a 72-pin connector would probably have been enough for all that.
Nothing wrong with that IMO, Adam was horribly executed though, could have been more like MSX. (simple console with external expansion capabilities plus CV compatibility) Or more precicely, like Sega SC-3000, except with the CV being more popular than the SG-1000 at the respective times.Quote:
Originally Posted by Guntz
Same for the other way around, C64GS, Commodore MAX, A5200, XEGS, CD32, etc are all tied to poor execution or other external factors (like a crumbling company with the CD32, combined with barred US release), something like the XEGS might have worked OK in place of the 5200 (still no lockout though due to A8 compatibility), and a C64 based gaming system might have been OK if it facilitated simple ports (ie full 64 kB and minimal keypad with most commonly needed keys), just a cheaper, cart-cased system with very limited expandability, the MAX was way too limited (RAM) and the 64GS was both way too late (needed to be there by '85 or '86) and had compatibility problems due to missing keys. (the latter could have been fixed in software and facilitated by controllers with a couple more buttons)
However, this isn't even the general case with the Genesis Disk drive. It may have been inteded for some additional non-gaming applications, but I think it was primarily intended to be what the Famicom Disk system was, support for an alternate media. (namely much cheaper and more flexible than ROM cartridges -and writable) The obvious problem is ease of piracy (especially due to ease of production), which the FDC experienced in spite of semi-propritary format. (and of course came as a major problem with optical discs as well)
http://sega-16.com/forum/showthread....d=1#post209573
Hey, I got to thinking in th eabove theread and realized that Sega could have gone the route NEC went and Nintendo was planning to with a more or less bare bones CD drive with separate system card/cart/module plugging into the cart slot. But going further this would have also allowed for the module w/out the CD unit if a cart slot was added, so sort of like an earlier 32x, and with the greater flexibility of the cartridge slot, possibly more like the 32x. (ie added VDP) And allow the 2 units to be sold separately, thus allowing expansion module users to upgrade to CD as well.
Of course, that would still exclude any neat stuff possible with the pixel bus and still require an external mixing cable for video expansion.
Also, a revision to my previous post: I don't think RGB would even be necessary if using the pixel bus for enhanced video with dual VDPs and such, just a separate A/V port on the expansion unit. (so long as normal genesis games still displayed fine via that AV connection, I'm not entirely sure if that would work)
Yeah you can look at this from a technical standpoint BUT I say look at it like this. The Mega Drive came out in 1988 in Japan and at that time NEC was releasing the CD-ROM drive for the PC Engine so it's safe to assume Sega had at least thought of the idea at that point. They might not have known exactly what the expansion would be used for but I'm sure they though a CD-ROM was a possibility.
Well, NEC thought ahead (actually, it was Hudson since they designed the system) and made a huge expansion bus/port - all cpu pins, video pins, etc. And never took advantage of it :) So I'd say NEC (they designed the CD addon unit) was a bigger fool than Sega.Quote:
Originally Posted by Chilly Willy
It's just a peripheral expansion port. There's nothing to say they did or didn't intend it to be for CD. It could have been for anything in the future (at the time). Though I'm sure a modem addon was probably a big interest at the time. An expansion port allows you to include a peripheral without the need to constantly switched between carts out or using a pass through device on the cart port.Quote:
Yeah you can look at this from a technical standpoint BUT I say look at it like this. The Mega Drive came out in 1988 in Japan and at that time NEC was releasing the CD-ROM drive for the PC Engine so it's safe to assume Sega had at least thought of the idea at that point. They might not have known exactly what the expansion would be used for but I'm sure they though a CD-ROM was a possibility.
Wow! That really is extensive, and to think all they used it for was the simple CD unit and an A/V expansion unit. I wonder if that could have been used for a supergrafx type upgrade. (especially if that had been integrated with the CD unit) A lot like what Chilly Willy suggested for the genesis, but without the pixel accumulation ability. (no 4+4=8-bit pixels)Quote:
Originally Posted by tomaitheous
The Mega Modem used the DE-9 EXP. port on the back of the console rather than the side expansion connector. (and Xband and Sega Channel used the cart slot of course)Quote:
It's just a peripheral expansion port. There's nothing to say they did or didn't intend it to be for CD. It could have been for anything in the future (at the time). Though I'm sure a modem addon was probably a big interest at the time. An expansion port allows you to include a peripheral without the need to constantly switched between carts out or using a pass through device on the cart port.
Tomaitheous, does the PC-Engine's expansion connector support VRAM expansion?
Why does SEGA made Mega Drive so color-poor? I mean, only 64 colors? If I unterstand correctly, with small changes and no price rice at all it could do a on-screen 256 capable machine.
64 colours was pretty large at the time, I guess they didn't see the purpose in going higher.
Technology just advances so fast.
drop out one of the sprite size bits and use it to double palette counts.... MD had 16 sprite sizes at any given time, PCE had 4, SNES has 2.... with 1 bit kicked out, it had 8 and it would still have been the king on that regard :P
The Genesis VDP already supports anouch CRAM entries for 8 subpalettes too right? (I don't think it physically has the necessary -unused- CRAM onboard already though -that would be pretty wastefull)Quote:
Originally Posted by TmEE
With that extra bit for palette selection, would it allow the 8 subpalettes to be applied to any layer as with the current 4? (I recall someone mentioning that you could have 8 subpalettes, but have the upper 4 set to BG only and lower 4 to spr only -or viceversa)
Needless to say, the master palette was a significant limiting factor as well, a 12-bit RGB palette should have been practical to use at least. (probably more worthwhile than including the HL/Shadow feature)
Then there's a bunch more things that got brought up itn the 10 things could could change about the genesis thread. (Z80 clock speed, Z80 bank selection, 68k clock speed, using DRAM for main instead of PSRAM -save a lot on cost even if you used a good bit more RAM, pixel accumulation support for a 256 color mode at 1/2 resolution, haivn g2 bankd of VRAM -or toggling between 64 kB and 2x 32 kB banks, etc)
MD supports 4+4 palettes over the digital color bus, you will drop all internal stuff besides sync signals if you want that. This would not work for any existing game nor MD2s
OK, I found th epost I was thinking of:Quote:
Originally Posted by TmEE
And using the color bus and an external output for more colors would completely bypass the onboard DAC, right? (that's what you man by dropping all internal stuff -9-bit DAC, CRAM etc) And had Sega actually used it (or facilitated external use on the cart slot or expansion port) they probably wouldn't have removed that bus on the MD2 ASIC anyway, so that wouldn't have been an issue. ;)Quote:
Originally Posted by Jorge Nuno
Looking at this again, if the genesis has 16 sprite sizes, what are the variable heights and widths alotted? I know 32x32 is the largest, and I'd thought 8x8 was the smallest, but all combinations of 8, 16, and 32 pixels HxW only gives 9 values, so does the Genesis support 4x4 sprite tiles as well or what? (or do 7 of those 16 vales get wasted so that all 9 sizes can be used simultaneously -in which case dropping to 8 would barely be a sacrifice at all)Quote:
Originally Posted by TmEE
Oh, and here's that 10 changes to genesis hardware thread I mentioned for anyone interested: http://sega-16.com/forum/showthread.php?t=4328&page=13 (pg 16 being the start of an interesting discussion with chilly willy ;))
And that quoted post above is from the Super VDP thread of course.
Things go in increments of 8pixels in sprite sizes. 8, 16, 24 and 32pixels both horizontally and vertically, total of 16 sizes. I would drop one vertical bit or horizontal and double the pixel count of the remaining bit (16 or 32 pixels).
One arcade board (or several) which use the same VDP as MD use external CRAM and RAMDAC and have 4+4 palette support by doing that...
In my opinion a bigger limitation than the 64 on-screen colours was the MD's tiny 512 colour palette. Most Amiga games looked more colourful than their MD counterparts, despite having half the on-screen colours, thanks to the Amiga's larger palette.
That comparison is indirect though, even in normal 32-color mode, that's 32 unique colors for a blitter manipulated bitmapped display (only 16 of those colors being used for the -relatively weak- hardware sprites). The MD uses 4 16-color subpalettes (effectively 15 color as 1 is needed for transparent) with only 1 subpalette being used per tile (just on other tilemap systems, like NES, TG-16, SMS, SNES, etc), but there are aslo going to be redundant colors in those subpalettes, so the total number of unique colors will be fewer still, sometimes probably no more than 32 unique colors even.
On top of that, a lot of Amiga games use halfbrite mode, which offers 64 colors (32 indexed from the 12-bit RGB palette, then having another 32 with half the brightness/intensity), this could even approximate the color fairly well for 256 color VGA games on PC.
And again, it's a bitmapped display, so any of the colors can be used anywhere on screen, the MD is limited to 16 color tiles. (so even with 12-bit RGB like the Amiga it would be at a diadvantage) Both can use tricks like changing palettes for different sanlines, but I think the MD might have to do that in software while the Amiga's Copper supported it in hardware, then there's HL/shadow on the MD, but that's more limited as well.
Still, that's not to say that the MD wouldn't have benefitted a lot from the larger palette (and again, if it came down to it, probably a more useful feature than HL/Shadow), but having addional subpalettes (like 8 instead of 4) would be a big help as well. Even with 8 you'd have only 1/2 the subpalettes the SNES does in mode 2 (which is the closest approximation of the MD) and 1/4 of what the TG-16 has. (albeit with an advantage of a 12-bit palette over the TG's 9-bit RGB -which is what the MD actually has -and the Atari ST)
Just a thought, has anyone considered that perhaps the genny's video chip was so gimped in terms of colors in comparison to all the other 16-bit era consoles because they wanted to retain MS (Master System) compatibility?
The MD's VDP exists because they built it upon the SMS' VDP (which they built upon the SG-1000's VDP, a Texas Instruments TMS9918).
Too bad that didn't continue to build on past hardware when they built Saturn and Dreamcast.
Quote:
Originally Posted by Dant
Yes, there may have been some limitations tied to building on the SMS VDP in the first place, but as the tech guys have already mentioned (moreso in other threads), the main issues (subpalettes and master palette) could fiarly easily have been improved. (time possibly being the deciding factor -a delayed release could have allowed for substancial improvement in some areas -not just color -some of which should even have saved on cost -like switching to DRAM instead of PSRAM for 68k -maybe Z80 too)Quote:
Originally Posted by Christuserloeser
But the SMS's VDP is really a massive overhaul of the TMS9918, it's so much more capable and there are substancial differences overall; the color palettes are completely different even, TMS9918 uses 15 YCbCr values opposed to RGB. (the SMS VDP must have a built-in transcoder to output RGB for SG-1000 -or just approximates the colors eith 6-bit RGB values)
Donig so for the Saturn probably wouldn't have been too tough, but retaining comaptibility on the DC might have been more challenging to maintain similar cost and capabilities. Probably doable though, all the video/audio hardware, Z80, and 2x 68000s could probably have been crammed into one ASIC -assuming a Genesis+CD derived Saturn prior to DC, the SH2s would be another issue, I'm not sure if you could omit one and have the SH4 fill the gap or not; otherwise I'm sure you could put a pair of SH2s to good use -probably replacing soem other parts of the DC hardware, the Sound system for instance. (-but you've got 2x 68000s and a Z80 to make use of as well -and a bunch or RAM that needs to be mapped properly for compatibility -even if you drop MD specific compatibility) I mean Sony managed to do it for the PS2, but that wasn't entirely cost effective, though it worked OK. (had the Saturn/alternate used a single CPU, or the DC used dual CPUs things may have been a bit easier -I think 2x SH3s could allow for backwards compatibility of a dual SH2 system -requiring switchable clock speeds of course -2x SH4s would be too expensive)Quote:
Originally Posted by gamegenie
But way off topic. ;)
That's six :) 16x16,16x32,16x64,32x16,32x32,32x64.Quote:
Originally Posted by TmEE
But you know, the sprite cell size and cell build structure option (sprite size) is one of my favorite features on the Genesis VDP :D Reducing to 8 (which would probably be something like 4 sizes and 1bit for 8x8 cell or 16x16 cell option) just isn't as nice IMO. But they wouldn't need to reduce any bits to get the additional 4 more subpalette support though. I mean, the upper 64 registers/memory cells aren't there (they're mirrored) - right? The whole thing is that they tied the sprite subpalette association to the first 64 registers because the second/addition set is not on the chip anymore.
If you think about it in reasons of cost, and the excluded all SMS video modes, removed the z80 and z80 ram, hooked the YM's interrupt lines 68k (so you get proper PCM playback) - then I sure they would have enough money/resource for a DAC expansion to 4bit and 8 subpalettes. So sure, that's a possibility. But specifically the VDP? Hmm. It's possible just the additional logic needed for backwards compatibility would cost as much as 64 more 16bit memory cells (could be 9bit wide, I never checked if the LSbit holds a value or not. But regardless, that many registers isn't cheap cost or space wise, relatively speaking). Considering all the attributes of the VDP (it really is an amazing chip for its time), removing the additional memory cells and mirroring the existing palette addressing back to the sprite table at the time to save money, was probably considered a reasonable downgrade VS cost.Quote:
Just a thought, has anyone considered that perhaps the genny's video chip was so gimped in terms of colors in comparison to all the other 16-bit era consoles because they wanted to retain MS (Master System) compatibility?
Still a curious one though. PCE came out in Oct '87, as a huge success and extremely popular on its release (building up a premise here). It out sold the Famicom the first year (and continually). While the Megadrive came out about 1 year later, development was probably at the most 6 months out for the VDP at the latest - but more likely about 1 year I'm guessing (in other words the VDP was done sooner and they still needed time to ramp up supplies of the chips). If it was up to 6 months, then it's was a poor choice on their part. But if the choice was made around the time of the PCE's release or a little afterwards, then it's understandable. The comparison being, PCE has 32 subpalettes and released in '87 - while the Megadrive has 4 subpalettes and released in '88 (but had the capability of 8 subpalettes very-very easily).
And Sega did add the 12-bit RGB palette so the SMS VDP for the Game Gear too, albeit a couple years later.
Given that the Genesis VDP is built on the SMS's design, wouldn't backwards compatibility have been kind of integral? (or are the similarities more superficial -the MD VDP uses chunky instead of planar pixels, so that's a significant change at least)
Having a 12-bit color DAC wouldn't require additional external pins either. (which is a significant component of the cost of the chip in addition to silicon -granted it wouldn't matter if the package had extra unconnected pins already)
Usign DRAM for 68k memory should have made for significant cost savings too (even with more RAM -like 128-256 kB). As for PCM playback, you could the YM's interupt lines to the Z80 for the same reason (as Chilly willy suggested in the 10 changes to the Genesis thread), that and the Z80 could have been clocked faster. (TmEE mentioned the current Z80 is good for 6 MHz already -and 1/9 of 53.7 MHz give a nice 5.97 MHz)
Who said the 68k isn't using DRAM already? Well Its PSRAM, but internally it's a DRAM (memory cell is composed by a transistor and a capacitor, where it's charge is transfered to one of the longlines and then to the sense amplifier). Well it needs refresh, so it's a DRAM for certain.
Anyway kool kitty, the VDP has no unconnected pins. All of them seem to have an internal connection. Just becuase they don't appear on the genesis schematics it doesn't mean they're NC (I can guarantee you they're not). And a 12bit color DAC needs resistors and they take up a a not-so-little area inside the chip (more if you design dummy ones, which for analog is advisable).
Also tomaitheous, it seems the LSB of the colors is set sometimes, when a color is readback, but I can't understand it.
Oh don't forget the shitty serial reg on for the Z80 page...
I cant really understand if the VDP was specially done for the MD, or if it was a graphics chip designed to be used in various console(arcade) architectures. Its external capabilities make me beleive the second.
Yes, PSRAM, but pretty exotic at the time and much more expensive than comperable DRAM. (still cheaper than SRAM though) Perhaps they did it to expedite development time.Quote:
Originally Posted by Jorge Nuno
OK, I wasn't sure. There are at least a fair amount of unused pins though (unused busses, like the pixel/color bus and possibly one intended for a 2nd 64 kB VRAM bank). I beleive both features ended up getting used in the arcade and later implementations did remove the color bus. Ideally, both added busses should have been used, allowing VRAM to be configured as 2x 32kB banks perhaps, and possibly adding the colro bus to the expansion port and/or cartridge port. (which would have major connotations for expansion -albeit other changes to the expansion port would be necessary to really help the CD -or have it connected to the cartridge port instead)Quote:
Anyway kool kitty, the VDP has no unconnected pins. All of them seem to have an internal connection. Just becuase they don't appear on the genesis schematics it doesn't mean they're NC (I can guarantee you they're not). And a 12bit color DAC needs resistors and they take up a a not-so-little area inside the chip (more if you design dummy ones, which for analog is advisable).
Other than switching to a parallel banking mechanism, Chilly Willy also mentioned slpitting the 32 kB space into 4x 8kB banks instead. (if serial bank selection was still used)Quote:
Oh don't forget the shitty serial reg on for the Z80 page...
The SMS VDP did such as well, I beleive there was an arcade board usign an SMS VDP with dual VRAM banks and I seem to recall one using dual SMS VDPs as well. (maybe both)Quote:
I cant really understand if the VDP was specially done for the MD, or if it was a graphics chip designed to be used in various console(arcade) architectures. Its external capabilities make me beleive the second.
Yeah, some years later. Not to mention the SMS VDP is much simpler in design and number of gates (and how fast they need to operate internally). Simply adding a 12bit DAC mode to the existing SMS VDP design doesn't seem like a big deal at the time of the GG. Not compared to the juggernaut that is the Genesis VDP.Quote:
Originally Posted by kool kitty89
Other than both are tile/sprite based systems, the SMS and MD - they're really nothing alike. The sprite table, how it fetches vram/pixels, the pixel mode being completely different, has a line buffer system for sprites, etc. It couldn't be more different from the SMS in low level design. That definitely leads me to believe there is additional space on the IC wafer just for handling SMS specific modes (specific SMS mode logic operation/behavior, and such that can't be handled with the existing MD mode's logic layout).Quote:
Given that the Genesis VDP is built on the SMS's design, wouldn't backwards compatibility have been kind of integral? (or are the similarities more superficial -the MD VDP uses chunky instead of planar pixels, so that's a significant change at least)
Having a 12-bit color DAC wouldn't require additional external pins either. (which is a significant component of the cost of the chip in addition to silicon -granted it wouldn't matter if the package had extra unconnected pins already)
As far as a 3x4bit DAC vs a 3x3bit DAC, it's more complicated than that. Sure, the cost of wider range DAC is more expensive (though relatively speaking, probably not much more. But still, don't forget these are high speed DACs, not very low speed ones like 40-60khz audio DACs). But there's the additional cost of now having 3 more bits per palette storage register and assuming still *only* four subpalettes - that's 3x64 more lines to lay down as well and interface to. The additional logic and such.
The z80 is basically a waste of money though. The 68k could easily handle PCM playback on that single channel with an interrupt+programmable timer input which is exactly what the 2612 already has. Why involve the z80 at all? I guess the only bad thing would be breaking up VDMA into smaller calls as not to delay any interrupts, but this is what I would do anyway if the z80 is reading from 68k mapped rom space to the DAC. So the point is still moot. There are cheaper solutions to getting single channel streaming PCM than using a z80+ram and interfacing logic, traces on the PCB, etc. IMO - the z80 wasn't included on the MD mainly for audio handling. It was included for the sole purpose of SMS backwards compatibility. There's nothing intensive about updating a few 2612 or whatever audio chip regs every so many frames. Nothing at all. Because Sega never hooked up the timer flag lines to the 68k interrupt input, is the only reason why the z80 is seen as a valid choice for PCM playback. Because it's the only option. And a rather more expensive and poorer option at that. A work around by programmers.Quote:
Usign DRAM for 68k memory should have made for significant cost savings too (even with more RAM -like 128-256 kB). As for PCM playback, you could the YM's interupt lines to the Z80 for the same reason (as Chilly willy suggested in the 10 changes to the Genesis thread), that and the Z80 could have been clocked faster. (TmEE mentioned the current Z80 is good for 6 MHz already -and 1/9 of 53.7 MHz give a nice 5.97 MHz)
Probably just open bus (and other logic using redundant lines). I've seen this on other systems ( and PCE does the exact same thing in regards to palette memory, but the 16bit write - it's the upper 7bits that are open bus internally on the chip. Sometimes you get patterned values and sometimes it's random. But never storable space internally). On the cpu side the read/write appears to be a full 4/8/16bit/whatever, but in fact internally there's no reason to waste such bits and is translated to whatever memory structure they laid out in the design. Sounds like this is the case with the MD VDP and palette registers to me.Quote:
Also tomaitheous, it seems the LSB of the colors is set sometimes, when a color is readback, but I can't understand it.
As for the MD VDP being designed for arcades primarily, I'd have to say probably not. Just because of the SMS backwards compatibility, but I would agree that they most likely had arcade usage in mind at some point for this chip - when looking at the digital pixel bus and that some Sega arcade systems not based on MD hardware also use this type of because for layer priority mixing. Again, the PCE is the same way. Its VDC was also used in a few arcade systems - even though it first appeared as a home console video device. It's designed to run a number of types of resolutions nonstand to NTSC (up to 512 scanlines (1-512 programmable, regs for vblank scanlines, etc) and as little as 8pixels to 1024pixels output on a scanline. It can run by itself *or* run with other ICs driving the H and/or Vsync output lines as input lines. You can still define a frame layout within an external defined/controlled frame. I did this to get horizont rolling image, but digitally by setting the VDC to run just the Hsync output instead of input :D ). I always wanted to hook up the VDP of the MD to the VCE (this chip holds the palette ram, has the pixel bus input lines, and provides a programmable dot clock for the supplying device, as well as all h/v frame timings and outputs) of the PCE, via the digital bus. Haven't figured out how to sync the two yet >_>
Huh, I wonder why they pushed for it then, the SG-1000 and SMS hadn't been very popular in Japan or North america, and SoJ didn;t seem especially eager to cater specifically to Europe (though they did continue to release SMS games there alone -most released on GG, of course).Quote:
Originally Posted by tomaitheous
Was the SMS's VDP very similar to teh TMS9918 derivative of the SG-1000, or was that tacked on as well? (I know the palettes are entirely different so either they'd need to remap the colros to 6-bit RGB, or include the YCbCr palette as well)
Yeah, I kind of mentioned that here: http://sega-16.com/forum/showthread.php?p=214823 rambling a bit though. Especially I was thinkig in terms of the added CRAM necessary for larger palettes (increased subpalettes and/or master palettes -let alone a 256 indexed half res mode) Again, the PCE and SNES used FAR more entries than the MD. (PCE must use more CRAM than SNES to have those 512 9-bit entries -compared to the SNES's 512 bytes)Quote:
As far as a 3x4bit DAC vs a 3x3bit DAC, it's more complicated than that. Sure, the cost of wider range DAC is more expensive (though relatively speaking, probably not much more. But still, don't forget these are high speed DACs, not very low speed ones like 40-60khz audio DACs). But there's the additional cost of now having 3 more bits per palette storage register and assuming still *only* four subpalettes - that's 3x64 more lines to lay down as well and interface to. The additional logic and such.
What if you wanted multiple PCM streams goign simultaneously (mixed onto the YM's DAC)? (chilly willy was suggesting 4 PCM streams, not to mention any decompression)Quote:
The z80 is basically a waste of money though. The 68k could easily handle PCM playback on that single channel with an interrupt+programmable timer input which is exactly what the 2612 already has. Why involve the z80 at all? I guess the only bad thing would be breaking up VDMA into smaller calls as not to delay any interrupts, but this is what I would do anyway if the z80 is reading from 68k mapped rom space to the DAC. So the point is still moot. There are cheaper solutions to getting single channel streaming PCM than using a z80+ram and interfacing logic, traces on the PCB, etc. IMO - the z80 wasn't included on the MD mainly for audio handling. It was included for the sole purpose of SMS backwards compatibility. There's nothing intensive about updating a few 2612 or whatever audio chip regs every so many frames. Nothing at all. Because Sega never hooked up the timer flag lines to the 68k interrupt input, is the only reason why the z80 is seen as a valid choice for PCM playback. Because it's the only option. And a rather more expensive and poorer option at that. A work around by programmers.
Though in that case, going for a faster 68k could be the solution as well, like a 10 Mhz one. (especially with the cost savings of the Z80+RAM and coresponding board space -and again DRAM would have helped a lot)
No, but it was an existing user base. At the time, they needed everything they could get. Remember, Sega wasn't that popular at the time (in comparison to Famicom, MSX, PCE, and the many PC systems). I'm sure they figured they needed all the help they could get (BC is one way if your user base is small and you need to compete. I think BC doesn't make that much of a difference for the more successful systems/companies).Quote:
Huh, I wonder why they pushed for it then, the SG-1000 and SMS hadn't been very popular in Japan or North america, and SoJ didn;t seem especially eager to cater specifically to Europe (though they did continue to release SMS games there alone -most released on GG, of course).
You could. But all that work and just for an 8bit DAC - no volume? Remember, the more channels you have - the lower the bitrate is for those channels. And be it digital hardware or software volume, anything that's not max volume is also lower bitrate. 4 channels on an 8bit DAC at max volume is 6bits per channel. If you were to use non linear shift volume (closer to decibels steps/range than anything linear would be), one shift per volume step on that channel is 1bit taken away from that channels resolution. The aliasing noise is somewhat detracted by the lower amplitude, but it's still there. If they were going to go through all that work/design - might as well do a separate DAC with higher bitrate (10bit DAC) and put into a custom IC with a small FIFO per channel (and maybe a realtime hardware shift volume mechanism per channel). Tie the custom IC to the scanline frequency (15.7khz) or double it or and option for both speeds. And totally ignore the 8bit direct write channel of the 2612 (keep it in FM mode).Quote:
What if you wanted multiple PCM streams goign simultaneously (mixed onto the YM's DAC)? (chilly willy was suggesting 4 PCM streams, not to mention any decompression)
Though in that case, going for a faster 68k could be the solution as well, like a 10 Mhz one. (especially with the cost savings of the Z80+RAM and coresponding board space -and again DRAM would have helped a lot)
And as for the 10mhz mode, I'm not sure what the price difference was back then between them - but that speed increase also means faster ram and more importantly rom speeds. Unless you had some sort of wait state system for the rom, but then you start adding up the complexity and cost again. 7.67mhz is fine and has proven to be just fine over the course of the Genesis' life span.
Remember that even as late as 1994-95, adding multiple channels of 8 bit audio together for output at 8 bits was still the dominant form of audio. So a MD with four channels added together via the Z80 to output on the YM2612 DAC would have been adequate until the MD's replacement came. Unless you knew your game output four VERY loud sounds at all times, a programmer would almost certainly add the channels together (with saturation) at either 7 bits per channel, or perhaps the full 8 bits per channel if they knew the game normally had quiet sounds, or few infrequent louder sounds. For volume, a simple right shift on the final sample would do for a non-linear 3 or 7 settings volume control. Most people tend to set the volume on their games to maximum and use the TV volume control in any case, so it's usually a moot point. You could easily not do any volume and tell the player to control the volume via the TV/audio deck volume control.Quote:
Originally Posted by tomaitheous
Yes, a separate audio DAC for each channel would be better, but I think people were thinking of the simplest, cheapest changes that could be made that would improve things without the added expense and complexity of something like a four channel DAC. Boosting the Z80 speed to 6 MHz would have been super-easy and cheap, while improving things. Making four banks to the 68000 space instead of one would have also been super-easy and cheap. Both of those changes would have allowed for reasonable multi-channel PCM for almost the exact same expense and complexity as what the MD has right now.