Quantcast

Page 1 of 3 123 LastLast
Results 1 to 15 of 45

Thread: Genesis ROM speed

  1. #1
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default Genesis ROM speed

    Exactly how fast was the ROM used in Genesis games?

    I know the PCE consistently used ROM fast enough for zero wait states from the CPU (better than 140 ns), but that was exceptionally fast ROM for the time and well beyond the speed for commodity mass-market ROM. (which was in the 400-500 ns range towards the end of the 80s and very early 90s)
    I also got the impression that lat least some early MD games used very slow ROMs (~520 ns, barely fast enough for the CPU to access without wait states), but now I realize that might not make sense given the speed memory is accessed with vblank DMA for block transfer to VRAM.

    The VDP does block transfer at about 2.6 or 3.3 MB/s, but that means it's reading and writing that much, so actually accessing memory 2x as fast (presumably at the clock rate of the VDP -5.37 or 6.71 MHz, but not doing block transfer continuously for the entire length of a scanline in vblank, so actual transfer rate is slightly lower). So that would mean the VDP is accessing memory at 186 or 149 ns, but since it would only ever access ROM every other cycle, it should be possible to configure things such that ROM would only need to be capable of 298 or 372 ns. (but that's still significantly faster than the 520 ns claimed to be used for early MD games)

    However, that's the access speeds needed if the VDP's block transfer logic can only make 8-bit accesses, but if it could make 16 bit reads (followed by 2 consecutive 8-bit writes to VRAM) or if there were an external 16-bit bus latch employed for a similar purpose, it should have been possible to get by with RAM that was half that speed again. (so 520 ns would be acceptable for either either VDP speed)


    Otherwise, Sega would definitely have had to be using faster ROM to allow use of DMA at those speeds.
    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?

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

    Default

    The default rom space /DTACK always results in four 68000 clock cycles unless held off by something like DMA or the 32X. In that period, you can access either a byte or a word.

  3. #3
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    200ns is absolute minimal speed you can use in MD without getting graphical corruption from failing DMA transfers.
    EDIT: according to Eke-Eke's calculations it would be 300ns
    Last edited by TmEE; 05-18-2011 at 05:27 AM.
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  4. #4
    Wildside Expert
    Join Date
    Nov 2008
    Posts
    101
    Rep Power
    13

    Default

    Most (all ?) ROMS are 16-bit so the cartridge does not make any difference betwen byte/word reads and always return a word on data bus. The CPU picks upper or lower byte in case of 8-bit read and the VDP most likely read one 16-bit word at once during DMA for performance reasons.

    VDP DMA transfer time is tied to the maximal number of access to its internal bus which is a slot every 2 pixels and indeed makes ~300ns between each slots (at the fastest 6.71 Mhz pixel clock).

    For VRAM, one byte is written per slot which means one word is being read from ROM every 2 slots = 600ns but for VSRAM/CRAM, access it's one word per slot so I too wonder how it could work with ROM slower than 300ns... most likely, all released games are using ROM with suitable speed or this would be immediately visible
    Last edited by Eke-Eke; 05-18-2011 at 05:19 AM.

  5. #5
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by Eke-Eke View Post
    For VRAM, one byte is written per slot which means one word is being read from ROM every 2 slots = 600ns but for VSRAM/CRAM, access it's one word per slot so I too wonder how it could work with ROM slower than 300ns... most likely, all released games are using ROM with suitable speed or this would be immediately visible
    Perhaps games planned to use slow ROM would have the programmers take that into account. (can VSRAM/VRAM be updated manually by the CPU or use DMA to 68k work RAM rather than ROM -have the 68k load the necessary data into work RAM ahead of time)

    There's definitely no buffering that would allow CRAM updates using slower accesses to ROM? (it seems rather wasteful to use fast ROM just for that purpose . . . not like the PCE where fast ROM is necessary for peak CPU speed, or SNES for that matter)


    I was mainly wondering if NEC was the main exception to using much faster than commodity ROM speeds (I know the SNES uses slightly faster than average ROM, but it's not a huge leap from the cheap ~420 ns ROM the likes of the lynx was using -actually the Lynx and Jaguar were the main cases where ROM speed was brought into question -both avoiding ROM access as much as possible and relying on RAM to maintain good performance; the Jaguar in particular only using 375 ns -I think that might be hardcoded too, but I'm not sure -if not, that could mean some massive boosts in flexibility with ROM on homebrew releases, or even some of the low-profile late 90s releases)
    Last edited by kool kitty89; 05-18-2011 at 08:55 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?

  6. #6
    Outrunner
    Join Date
    Jul 2009
    Location
    Azeitão - PT
    Age
    30
    Posts
    721
    Rep Power
    12

    Default

    Even 300ns is too much. The VDP reads the rom in one pixel and writes to cram (or vsram) on the next pixel, but the data has to be valid for a great part of the write cycle, not just for a split picosecond at the end (because of setup and hold times and propagation delays, etc). So at the end of the pixel where data has been read, there should be already valid data. Doesnt need to be, if its not then the write signal pulse has to be an "half-pixel" pulse.

    I say 150ns should be the safe minimum, 180 or 200 may work.

  7. #7
    Co-Creator of the MegaAmp Raging in the Streets villahed94's Avatar
    Join Date
    Apr 2010
    Location
    Oaxaca, Mexico
    Age
    23
    Posts
    4,531
    Rep Power
    42

    Default

    The access time is much higher than the typical RAM chip used(100 ns). However the failing write-read may be related to the CPU speed. At a quite higher speed(12 mhz) the Cpu is reading and writing data much faster than what both the ROM and the VDP can, causing Graphic garbage. This is a rule for most games. In the other side there are games on which too fast writeback routines cause them to crash. There are some games on which the ROM is fast enough to have a constant data transfer and don´t have any problem with this, but they do have problems with PCM.


    Mega Amp: An all-new audio circuit for your Sega Genesis/MegaDrive and clones.

  8. #8
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    27
    Posts
    10,003
    Rep Power
    105

    Default

    You have no idea what you just said....
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  9. #9
    Shining Hero Joe Redifer's Avatar
    Join Date
    Dec 2005
    Location
    Denver, CO - USA
    Posts
    12,978
    Rep Power
    116

    Default

    He does that.

  10. #10
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by Jorge Nuno View Post
    Even 300ns is too much. The VDP reads the rom in one pixel and writes to cram (or vsram) on the next pixel, but the data has to be valid for a great part of the write cycle, not just for a split picosecond at the end (because of setup and hold times and propagation delays, etc). So at the end of the pixel where data has been read, there should be already valid data. Doesnt need to be, if its not then the write signal pulse has to be an "half-pixel" pulse.

    I say 150ns should be the safe minimum, 180 or 200 may work.
    Again, could you get around that by not using DMA to update CRAM? (ie if a programmer knew a game would be using slow ROM, could they set things up such that CRAM was only updated by the CPU manually copying data over -or copying into work RAM and then loading via DMA from that RAM)
    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?

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

    Default

    Quote Originally Posted by kool kitty89 View Post
    Again, could you get around that by not using DMA to update CRAM? (ie if a programmer knew a game would be using slow ROM, could they set things up such that CRAM was only updated by the CPU manually copying data over -or copying into work RAM and then loading via DMA from that RAM)
    Yeah, they could do that. There are basically three completely different timings used for the rom access: the CPU uses four 68000 cycle accesses as mentioned; the VDP uses its own timing for DMA; finally, the Z80 uses yet another completely different timing for it's own accesses. The CPU is easy to understand - the other two aren't very well documented.

  12. #12
    Master of Shinobi Sik's Avatar
    Join Date
    Jan 2011
    Posts
    2,145
    Rep Power
    44

    Default

    Quote Originally Posted by TmEE View Post
    You have no idea what you just said....
    I don't think I have any idea what did he say either... x_X

  13. #13
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    28
    Posts
    9,713
    Rep Power
    60

    Default

    Quote Originally Posted by Chilly Willy View Post
    Yeah, they could do that. There are basically three completely different timings used for the rom access: the CPU uses four 68000 cycle accesses as mentioned; the VDP uses its own timing for DMA; finally, the Z80 uses yet another completely different timing for it's own accesses. The CPU is easy to understand - the other two aren't very well documented.
    In the 68000's case, doesn't it need to have the data ready on the bus by the end of the 3rd cycle or a memory access? (which would imply you'd need ~390 ns memory to avoid wait states in the MD, unless there's some buffering that could get around that . . . but I'd gotten the impression that it was with buffering that you could get away with 3 cycles -ie using a 16-bit latch like in the ST and Amiga- otherwise the 68k needs to access the bus on all 4 cycles of an access iirc)
    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?

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

    Default

    Quote Originally Posted by kool kitty89 View Post
    In the 68000's case, doesn't it need to have the data ready on the bus by the end of the 3rd cycle or a memory access? (which would imply you'd need ~390 ns memory to avoid wait states in the MD, unless there's some buffering that could get around that . . . but I'd gotten the impression that it was with buffering that you could get away with 3 cycles -ie using a 16-bit latch like in the ST and Amiga- otherwise the 68k needs to access the bus on all 4 cycles of an access iirc)
    The standard 68000 read cycle without wait states has you assert the /DTACK by S4; the data bus must be stable by that point. So it's the end of cycle two, not three. With a latch, you could cut the bus short a cycle by isolating the 68000 from the bus and keeping the latch supplying the data to the 68000 for the fourth cycle. The 68000 always goes four cycles (plus any waits).

    The Amiga was a little more sophisticated. Since the first two cycles aren't used by the 68000 (except as address setup), the custom chips used the first two cycles for itself, then the last two cycles for the 68000. That made much of the DMA transparent to the 68000, but required much faster ram.

  15. #15
    Co-Creator of the MegaAmp Raging in the Streets villahed94's Avatar
    Join Date
    Apr 2010
    Location
    Oaxaca, Mexico
    Age
    23
    Posts
    4,531
    Rep Power
    42

    Default

    Quote Originally Posted by TmEE View Post
    You have no idea what you just said....
    Of course I do. Frying Md´s by super overclocking and some analysis of the games has lead me to 2 conclusions about how games can behave differently each other, and how some games tolerate much better speeds than others.

    1.- Games that have a slow chip(They don´t tolerate as fast writeback routines as the cpu , if the latter runs at much higher speeds)
    2.- Bad programming of the game itself(Even if the chip is fast enough to be running well, how the game was programmed can lead to disastrous results).

    Typical Rom speed should be around 250-300 ns, while the oc tolerants might be around 200 ns or less. Fantasia is a good example of bad rom, being near 500 ns or more.


    Mega Amp: An all-new audio circuit for your Sega Genesis/MegaDrive and clones.

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
  •