Quantcast

Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20

Thread: busting 32x performance myths

  1. #16
    Sports Talker
    Join Date
    Sep 2013
    Posts
    39
    Rep Power
    0

    Default

    May I ask for a Saturn binary that tests both VDP1 and VDP2?
    no prob
    http://www.hyakushiki.net/misc/satspd.bin
    I mean, the 68000 is not gonna be any faster so there's nothing they could do about the 68000 hogging the cartridge bus against the SH-2 when it got there first. And if it's running code from cartridge area, it's gonna be doing it all the time.
    Well, I think the 32x could have enforced an access window in between 68k accesses, kind of like how the Amiga shares memory bandwidth. Although that's not what concerns me, I'm just saying they should have made it less of a bottleneck for the SH2, when the 68k is not using it. Even PCE hucards are faster.

    edit: now that I've found this additional piece of documentation https://segaretro.org/images/2/2c/SH...are_Manual.pdf I'm wondering if fooling with the bus state controller could tweak the performance a bit (although the 32x doc said not to do this)
    Last edited by bakemono; 05-30-2019 at 02:50 AM.

  2. #17
    Raging in the Streets Sik's Avatar
    Join Date
    Jan 2011
    Posts
    3,353
    Rep Power
    63

    Default

    Quote Originally Posted by bakemono View Post
    Well, I think the 32x could have enforced an access window in between 68k accesses, kind of like how the Amiga shares memory bandwidth. Although that's not what concerns me, I'm just saying they should have made it less of a bottleneck for the SH2, when the 68k is not using it. Even PCE hucards are faster.
    That's… precisely what it's doing. If a SH-2 wants to access the cartridge while the 68000 tries to access it, then the SH-2 will be given immediate access as soon as the 68000 is done, and if the 68000 wants to access again before SH-2 is done, then the 68000 has to wait. The docs explicitly say that whoever gets in first wins.



    The 68000 is really that slow from the SH-2's viewpoint (don't forget the latter spends less cycles per instruction and also runs at over 3x the clock speed, as well as having a cache to cope with most common accesses). And the PCE used a CPU that spent less cycles on a bus access than the 68000, if you wonder why the hucards are faster. The 68000 is a well known cycle waster, as it was designed in a time where CPU speed was starting to surpass RAM speed significantly and it was better to spend cycles that way to get more complex instructions.

    For the record, the Jaguar suffers from a similar problem: the two DSPs sharing a bus with the 68000 was an awful idea because the latter loves to hog the bus.

    Quote Originally Posted by bakemono View Post
    edit: now that I've found this additional piece of documentation https://segaretro.org/images/2/2c/SH...are_Manual.pdf I'm wondering if fooling with the bus state controller could tweak the performance a bit (although the 32x doc said not to do this)
    I'm pretty sure that's used for the RAM on the 32X and you really really don't want to touch it (・ω・;)

  3. #18
    Sports Talker
    Join Date
    Sep 2013
    Posts
    39
    Rep Power
    0

    Default

    Quote Originally Posted by Sik View Post
    That's… precisely what it's doing.
    Not quite. On the Amiga, the chipset can access memory more often than the 68k does by itself. Every two cycles. It can leave every other slot open for the CPU, and then the CPU only waits when it executes instructions that don't finish in an even multiple of four cycles, while the chipset still gets its business done. On AGA the chipset does two consecutive accesses during its turn.
    The 68000 is really that slow
    That's not relevant to my point though. Even if the 68000 used 5 minutes to read a word, that's no reason for the SH2 to also behave in such a way

  4. #19
    Raging in the Streets Sik's Avatar
    Join Date
    Jan 2011
    Posts
    3,353
    Rep Power
    63

    Default

    The Amiga chipset also has predefined access patterns that have been factored into the wait states they added to the 68000. That doesn't apply to the SH-2s which spend most of their time away from the ROM space and where ROM accesses are completely arbitrary depending on the program running on them.

    The truth is that they probably expected programmers to try avoiding having both sides accessing ROM at the same time and the approach they took was just a fallback for the cases where it's really needed (or for when ROM accesses aren't common enough to become a big issue).

    Also I should mention that going by the tech bulletins, they seemed to be still making some modifications to the hardware three months ahead of release…

  5. #20
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    29
    Posts
    10,088
    Rep Power
    109

    Default

    Sega didn't opt to add an access buffer in the bus management chip on 32X side which would do fastest possible ROM cycles right away and store it for 68K to work on so that SH2 can get on the bus immediately after rather than wait entire slow 68K bus cycle to get its turn. But we got full CPU access durations on the ROM.
    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 ^

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
  •