Quantcast

Page 6 of 6 FirstFirst ... 23456
Results 76 to 84 of 84

Thread: Sega Saturn's Expansion Port... and The one Add-On that should've been made!!!!!!!!

  1. #76
    Road Rasher
    Join Date
    Oct 2010
    Location
    Winsted, Connecticut
    Posts
    299
    Rep Power
    11

    Default

    can the CD door still open with that 32x look-a-like attached?

  2. #77
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    77

    Default

    Quote Originally Posted by sheath View Post
    Chilly Willy,

    What are you offering the above alternative to? Looking at the Saturn's limited library, it appears to have provided reasonable mid-late 90s PC capabilities and Model 2 turned out fine as well.

    What you are describing still sounds like a low level assembly based system that relatively few developers would have squeezed the power out of.
    Much of the Saturn software was assembly as well. All of SEGA's libraries for the 32X and Saturn were assembly. In any case, the 68000 based compilers were far more developed and debugged than SH compilers at that time as the 68000 was popular in personal computers and workstations.

    My proposed Saturn is only barely less powerful than what SEGA gave us, being only less powerful in 2D capabilities. It would also have levered the knowledge developers already had with the SEGA CD.


    A ~$200 Saturn as you describe in 1995 may well have been something Sony would have taken a huge loss to compete against. How do you think your Saturn and the PS1 would have stacked up?
    Actually, what I described would still probably have been over $300 - don't forget that the CDX launched at about $400.

    It would have eliminated the need for the 32X, and would have capitalized on existing games and programming knowledge, meaning Saturn games would have come out quicker and more frequently. Between no 32X and a larger game library, it might have actually faired pretty well against the PSX.

  3. #78
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    29
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by Chilly Willy View Post
    It could run routines from ram - it's whether SEGA provided functions to run routines from ram that remains the question. When they dedicated the SH1 to just handling the CD, they probably removed any ability to run your own code. There really wouldn't be a need for it when you have the ability to use the 68000 and both SH2s.
    Well... when it was free of CD-ROM duties, it would be useful as a general coprocessor. It was on its own bus, so it didn't have some of the bus sharing limits of the SH2s and regardless of the model it had a 1 kB scratchpad at the very least (SH1s had 1, 4, and 8 kB versions with 0, 16, 32, or 64 kB of ROM on-chip).

    I can't seem to find any specific info on the SH7097 though... Or anything in the SH709x range for that matter.



    Quote Originally Posted by Chilly Willy View Post
    Seriously, what I might have done in SEGA's place would be to start with the CDX, beef up the graphics functions in the the CD ASIC to a full VDP1 level, bump up the speed of the MD side 68000 to match the CD side (12.5 MHz), add one SH2 to act as a coprocessor to the MD 68000 (clocked at twice the 68000 speed), make a few minor updates to the VDP in the MD ASIC (like we talked about in another thread... increase the number of palettes and increase access speed to the vram among other things), and replace the Ricoh sound chip with something a little better (maybe a newer Yamaha chip like Kitty mentioned).
    Yeah, and one interesting possibility is if the pixel combining/RAMDAC chip also added alpha blending capabilities (even simple averaging like the SNES and Saturn VDP1 -but preferably in 24-bit RGB). That would be particularly interesting for shading effects: have 1 256 color 3D layer and then a translucent overlay used for 16/256 shades for shading/lighting effects. (that might be easier to engineer and better looking than hardware dithering in 256 colors or plain flat shaded/posterized 256 color)

    If they added a DSP coprocessor, the one used in the SCU would probably be a lot better than a 25 MHz SSP-1601 as I suggested in that older discussion.

    And as for using old tech, they probably wouldn't be using the exact same chips for the new machine (not all of them anyway), with the newer VDPs missing the necessary external buses and integrating other stuff that wouldn't need to be doubled, but working with mostly pre-existing hardware should have cut R&D time and costs for sure and (initially at least) they could probably use much of the very same hardware. The dual VDPs, RAMDAC/pixel combining/alpha blending logic would probably be on a new ASIC (and only including the MD-DAC+SMS+PSG+YM2612+CRAM+I/O blocks once, with the 2nd VDP block being just the digital portion of the VDP itself, or even omitting the SMS VDP logic entirely if they felt the need for SMS compatibility was unnecessary -which it already was by the MD2 given the rarity of PBC-IIs in Europe -and virtual absence elsewhere), maybe integrating the beefed up MCD blitter or leaving that on a separate IC with other interface logic integrated as with the MCD ASIC.

    And with compatibility you'd need to keep all the MD+MCD audio hardware too, so you might as well make better use of it. (and rather than pushing for the OPL4, let alone something as elaborate as the SCSP, you could double the Ricoh chip, or add a few simple 16-bit DMA channels -the latter would probably be better to allow higher quality streaming audio in general with added stuff via software mixing: maybe even just a pair of 16 bit linear DACs with DMA -so like the 32x but with better DACs- and variable output sample rate, but a bank of DMA channels with a good range of hardware sample rates, volume, and 8/16-bit support would be nice too -maybe something like the Atari Falcon has with 8 16-bit DMA channels, and that actually went up to ~50 kHz, but it didn't cater to the common 48/44.1/32 kHz/22.05 kHz rates exactly) If they could get a good deal on the OPL4 (especially licensed and embedded), then it would certainly be a nice option on top of the old hardware. (you'd have the PSG, YM2612, Ricoh chip -probably with more RAM- and the OPL3 FM block of the OPL4 plus 24 DMA PCM channels sampled to 22 or 44.1 kHz at 8/12/16-bit resolution -with a bit of added logic to allow DRAM interfacing given it only supports SRAM/ROM natively)

    But given the low-cost emphasis and existing compatible hardware included, probably stick with a simple stereo DAC controlled by one of the other CPUs and /or DSP depending what had DMA to the audio bus. (maybe interleave accesses of both the Ricoh chip and the simple 16-bit DMA audio -simple ST/Amiga like interleaving should have been feasible, or perhaps make the DMA audio read directly from one of the 68k buses instead -then allowing either 68k, the DSP, or SH2 to mix to the DMA channels and keep the ricoh RAM purely 8-bit -a slow 128 or 512 kB 8-bit DRAM chip which should have only been a small 24-pin narrow DIP, and a bit of added logic to the Ricoh interface in the ASIC to allow DRAM to be used rather than SRAM/PSRAM)

    And I already mentioned the previous discussion on page 2 of this thread
    Quote Originally Posted by kool kitty89 View Post
    We've gone through that before though, especially here:
    http://www.sega-16.com/forum/showthr...?t=8497&page=3 (especially chilly willys posts)

    You'd have backwards compatibility, and you'd leverage existing technology to make the next level less expensive. They didn't need the power of VDP2 (the 2D chip), and one faster 68000 + one SH2 would have worked just as well (or better) than two SH2s. The only part that needed BIG improvements was the graphics processor in the CD part, along with better audio.
    Cost advantage, R&D advantage, etc to allow faster production run-up, lower price point, and more time+fund investment in software development, advertising, producing good development tools, etc.
    If they left out the warped rasterization logic of VDP1 and focused on providing external resource to aid in rasterization would have saved some time and increased flexibility and made the hardware only quads a non-issue. (via fast CPUs and/or DSPs -one SH2 and the DSP from the SCU would be nice -especially if it could be clocked up to 16.7 or 25 MHz)
    As it is, the DSP in the Saturn+SH2s probably could have addressed triangle rasterization fairly well (perhaps even with less resource than software floating point math -and obviously avoding overdraw with folded quads), but Sega probably wasn't supplying a ready-made example of using the DSP for that... but in such a case with the hypothetical console, that would have been a primary feature to support with the DSP.

    And you've got the 68ks to help out too even if the SH2+DSP were maxed out rendering and related tasks (scene management, z-sorting, physics, lighting, etc), especially while the CD was idle or streaming CD-DA and you had full use of both 68ks. (and the Z80 for what that's worth, maybe again used as an audio controller, maybe clocked faster in Saturn mode if they really wanted to make use of it -maybe even 12.5 MHz given the 50 MHz- and a better bank switching scheme)


    Since there's no VDP2 and they're working on existing hardware anyway, maybe they could have put more focus on the VDP1/blitter instead. Regardless of adding hardware rasterization, they could have added buffering for higher bandwidth and peak fill rate (and certainly keep the color look up capabilities of the Saturn VDP1), but buffering in particular would be very useful in maximizing operation in slower RAM and avoiding the need for SDRAM and still being faster than the Saturn's VDP1 for some things. (using 32-bit word RAM and texture memory, or perhaps DMA to the SH2 bus for 32-bit accesses as well as slower 16-bit access to the 68k buses, have phrase buffers to allow multiple lower depth pixels to be read and written at higher bandwidth and if possible add line buffers to allow prolonged reads and writes at full fast page bandwidth and probably double the internal clock rate to 25 MHz -really useful with shared memory to minimize page breaks and bus usage and is what the Jaguar does at 64-bits for most graphics operations -except texture mapping unfortunately) That's the best you could get without a proper cache, and that would be pushing it for the premise, but line buffers would minimize the hurt it would put on bus sharing with the 68ks and SH2. (if you used all 80 ns DRAM to minimize cost and use existing stockpiles, that would mean 50 MB/s for pulling textures from SH2 memory and for writing to word RAM and 25 MB/s for using the 16-bit 68k buses)

    If you used SDRAM or EDO DRAM (probably the latter due to cost -probably avoided it on the Saturn to speed development due to SDRAM being easy to interface) for SH2 memory, that would be 100 MB/s for reads from SH2 memory. (if the ASIC was running at 25 MHz at least... if it was 12.5 MHz but with the added buffering, 25 MHz RAM would be useless...) And that's not considering potential to add 64-bit memory and buffer for that. (but since you've got an existing multi-bus architecture, that would be impractical due to the traces/board space it would requite -making a few things 32-bit and the rest 16/8-bit would make more sense)

    Doing any warping effects (without full rasterization logic) would still take added overhead as any such case, but you'd have much faster texture mapping and more efficient bus sharing (without needing more buses/banks/RAM) and better 2D performance for scaling/rotation in general on top of the plain MD VDP sprites/tiles. (so supplanting the lack of VDP2 a bit more for some things -especially large, scaled background effects, competing better with the PSX GPU in 2D mode)



    Quote Originally Posted by sheath View Post
    Chilly Willy,

    What are you offering the above alternative to? Looking at the Saturn's limited library, it appears to have provided reasonable mid-late 90s PC capabilities and Model 2 turned out fine as well.
    What you are describing still sounds like a low level assembly based system that relatively few developers would have squeezed the power out of.
    None of that is to make it more powerful, but more cost effective and backwards compatible (while still optimizing cost). In actuality it would be a bit less powerful but far more cost effective and (depending on the actual feature set -a wide range of possibility in the hypothetical example) the differences wouldn't necessarily be that evident. (it definitely would be missing the VDP2 capabilities though)

    A ~$200 Saturn as you describe in 1995 may well have been something Sony would have taken a huge loss to compete against. How do you think your Saturn and the PS1 would have stacked up?
    Yeah, and that IS one thing Sega had over Nintendo from the launch of the SNES up to 1994 when both dropped to $100. (supposedly they were both $100 suggested retail by spring of '94, but it probably took longer for that price to be reflected at the actual retail level)

    And while a fully evolutionary console would have been a very attractive option (both for compatibility, or even avoiding compatibility and only choosing select components to build onto with a bit more flexibility -and still cutting R&D costs/time and easing production/development), but even so the Saturn itself could have been cost cut to a more minimalistic configuration.

    Aside from the Jupiter, they could have done a similar stripped-down configuration with the existing Saturn architecture (but no compatibility and added R&D costs). Cut down the CD-ROM sub system cut down RAM all around, and perhaps drop one of the SH2s. Using a derivative of the MCD CD-ROM interface with the 68k dual purpose for audio and CD-ROM would be nice, but from a late 1993 perspective they'd probably had the SH1 based interface locked-in, so other options would be faster. (maybe keep the slave SH2 but drop the SH1 and have the slave SH2 dual duty as coprocessor and CD-ROM manager, and cut down the CD-ROM buffer size in any case, maybe using a 128k DRAM chip -cheaper than SRAM/PSRAM and already in use by the MCD/Virtua Racing -and later 32x)
    Drop the DRAM on the main bus and perhaps drop main SH2 memory to 512 kB 32-bit (2 256k chips rather than 2 512k chips), keep video RAM the same.
    Hmm audio... definitely cut down the audio subsystem, no dedicated DSP, probably no synth, just DMA channels and maybe ADPCM decoding logic and drop the 68k.
    Hmm, or maybe go REALLY simple and have something only a little better than the 32x (say stereo 16-bit high quality DACs -not PWM- with variable sample rate up to 48 kHz or 44.1 kHz) and then use the slave CPU to drive DMA audio and perhaps allow the SCU DSP to access audio as well. (to save cost, maybe either allow the CD-ROM buffer to double as audio RAM -and thus probably bump it to 512 kB DRAM, or bump up main RAM to 1 MB again and share that with audio, sharing slow DRAM with the CDROM would probably be the cheaper option)

    So perhaps something around 2.5 MB total memory, so a major cut over the 4.5 MB the Saturn used, though probably 2 MB of that would still be fast/expensive SDRAM down from 3 MB SDRAM +1.5 MB DRAM of the real Saturn. In any such case, they could have addressed the limited initial memory with a bit more provision for RAM expansion including full 32-bit main SDRAM expansion and 16-bit SDRAM for the video bus as well (with expansion signals to facilitate that with minimal external logic on the add-on card). Basically allowing 16/32-bit SDRAM modules to be plugged straight in for expansion of the main bus and bus B (which both of the VDPs are connected to) while leaving bus A for the MPEG port alone. (bus A is the CDROM bus -or in this context, possibly a dual purpose audio+CD-ROM bus)

    Perhaps even a coprocessor add-on... maybe (to simplify marketing) make a single, unified RAM+coprocessor add-on. But probably more likely plain RAM expansion. (and SDRAM is easier to interface, so that would facilitate things)
    Last edited by kool kitty89; 12-10-2010 at 11:37 PM.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  4. #79
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    29
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by Chilly Willy View Post
    Actually, what I described would still probably have been over $300 - don't forget that the CDX launched at about $400.

    It would have eliminated the need for the 32X, and would have capitalized on existing games and programming knowledge, meaning Saturn games would have come out quicker and more frequently. Between no 32X and a larger game library, it might have actually faired pretty well against the PSX.
    You could cut costs a lot more to manage a lower cost though... and it would especially be nice to cut certain areas that would be easier to expand later on at reasonable cost, bu would be expensive early on. (like RAM)

    Also remember that the CDX was hardly low-cost optimized and likely not sold at cost. It was $350 in early 1994 while the Genesis 2 and CD 2 had dropped to $100 and $150 by that fall, and a cost optimized duo unit should have been more like $200 by fall of 1994 in that context. (so $300 for a new system in spring of 1995 to the Saturn's $400 might have been rather feasible, maybe down to $250 rather than $300 in the Fall -or avoid the spring launch in the US entirely)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  5. #80
    Sports Talker IblisSlayer's Avatar
    Join Date
    Apr 2014
    Posts
    26
    Rep Power
    0

    Default

    I know that this is a super old post, but I was wondering if making the add on for Saturn would be possible still. I have the other consoles that I would take apart to mod into an ddon to plug into the expansion port and the VCD port.

  6. #81
    ToeJam is a wiener Hero of Algol Guntz's Avatar
    Join Date
    Nov 2009
    Location
    Canada
    Age
    26
    Posts
    8,522
    Rep Power
    82

    Default

    You do realize this was a joke thread, right?

  7. #82
    Sports Talker IblisSlayer's Avatar
    Join Date
    Apr 2014
    Posts
    26
    Rep Power
    0

    Default

    Perhaps, but can still be doable. For example, the Genesis had half the required component to run master system games, so the Power Base Converter was added to add in those missing channels. The Saturn as well takes some hardware from the genesis, so an adapter (and possibly and boot disc if needed) can be used to run the Genesis. Sega CD is a possibility that is almost certain, though I believe 32X may be out of the picture due to the hardware.

  8. #83
    ToeJam is a wiener Hero of Algol Guntz's Avatar
    Join Date
    Nov 2009
    Location
    Canada
    Age
    26
    Posts
    8,522
    Rep Power
    82

    Default

    Wrong, the Genesis has everything needed to run SMS games. All the PBC does is re-route the 64 pin cartridge slot to the smaller SMS cart slot.

    The Saturn is a little too complicated to simply let the 68000 run Genesis code, you'd also have to basically emulate the VDP, YM2612 and PSG since none of those are represented on Saturn.

  9. #84
    Master of Shinobi Segadream's Avatar
    Join Date
    May 2013
    Location
    Florida
    Posts
    1,211
    Rep Power
    21

    Default

    You know what's worse than finding a expansion port on the bottom of your favorite childhood console?
    finding out that said expansion came out and was awesome and you didn't hear about it or play any of those rad games cause you live in _______ (insert country here) and not japan, then You wish you were living in japan and then : Fukushima Daiichi, still wanted to live there anyhow.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •