No, because the USB driver starts a cog, so the input high-level cog needs to stop itself to make room for the emulation cores.
You could in theory combine the other drivers (i.e. use SNES for player 1 and pins for player 2), but that's not supported because why-would-you-do-that?
Making some more 96 MB boards and testing it out.
Seems like it only works with basepin of 0 and 16. Doesn't seem to work on 32.
Can that be? Or, maybe I have some kind of pin conflict...
Also, speaking of, you sure you're actually testing with something that uses all 6 banks? (this would be anything marked as 96 MB size in the compat list)
@Rayman said:
Even if the game needs 96 MB, seems you'd have to play the whole game to know if it works right?
Are maybe later levels stored in the upper banks?
In theory, yes. In practice the graphics are stored in semi-haphazard order, so between the attract sequence, the menus and the first level, a significant portion of memory is accessed. (And of course the program/audio/BIOS data ends up in the higher banks, anyways). Also the only way NeoYume will ever use the final bank is by loading a game that's actually large enough to need it. The last file loaded is always the BIOS, which of course fails catastrophically if it isn't working.
So I guess the ideal test would be a bunch of different sized games such that all banks have program/bios in them at one point, which makes failure really obvious. Or just write an actual memory test.
Ok, guess I'll use mslug5 and maybe some other to test the 96 mb boards...
Can't figure out the ruby romfix.rb...
By "neoyume directory" , do you mean on the PC or on the uSD disk?
Can't get either to work...
I made a mslug5 folder under NeoYume on uSD drive and copied presumably encryted files there.
copied romfix.rb to NeoYume folder on uSD drive.
opened dos prompt and navigated to NeoYume folder on uSD drive.
This is what I get:
G:\NEOYUME>ruby ./romfix.rb --cleanup
NeoYume ROMset fixer!
basedir is .
G:\NEOYUME>
It only recognizes mslug5h (the un-suffixed mslug5 is an earlier version that has leftover debug stuff when running on AES). The only difference are the program ROMs (called 268-p1c/p2c for the -h version and 268-p1cr/p2cr for the non-suffix version)
@Rayman said:
Ok, that looks a lot better. Got these two errors... Problem?
Yes, it's a problem... Won't run without...
Deleting ./mslug5h/uni-bios_2_3.rom
Deleting ./mslug5h/uni-bios_2_3o.rom
Deleting ./mslug5h/usa_2slt.bin
Deleting ./mslug5h/vs-bios.rom
Missing file ./mslug5h/268-m1.bin (for decryption to ./mslug5h/268-m1d.bin)
Decrypting 268-v1c,268-v2c into ./mslug5h/268-vd.bin (PCM2 type 2)
Deleting ./mslug5h/268-v1c.bin
Deleting ./mslug5h/268-v2c.bin
Missing file ./mslug5h/268-p1c.bin (for rename to ./mslug5h/268-pd.bin)
Decrypting CMC data in ./mslug5h
Deleting ./mslug5h/268-c1c.bin
Deleting ./mslug5h/268-c2c.bin
Deleting ./mslug5h/268-c3c.bin
Deleting ./mslug5h/268-c4c.bin
Deleting ./mslug5h/268-c5c.bin
Deleting ./mslug5h/268-c6c.bin
Deleting ./mslug5h/268-c7c.bin
Deleting ./mslug5h/268-c8c.bin
Warn: 2 errors encountered
Ye, as said, needs the version with 268-p1c/p2c. No idea why the M1 would be missing, that's kinda odd. Also, there's a mistake in the error message for PVC decryption, lol.
Ok, for the test suite for the 96 MB boards I now have:
Crossed Swords
Last blade
Metal Slug
Metal Slug 5
Sonic Wings 2
I just get into the actual game and then call it success.
This takes forever, but should be pretty good at finding flaws, from what @Wuerfel_21 just said...
I think that actually works out such that each bank has program or bios in it at least once:
Crossed Swords: prog/bios both in bank 0
Last blade: prog in bank 2, bios in bank 3
Metal Slug: prog/bios both in bank 1
Metal Slug 5: prog in bank 4, bios in bank 5
Sonic Wings 2: prog/bios both in bank 0
@Wuerfel_21 said:
Got a translucent red RetroBit Megadrive controller today. Can confirm that one works as advertised. Is infact very red, too.
Now if only there was real 2 player support.
Is this a slightly veiled announcement you are looking into hub support for the P2 USB driver...? Or something that manages both physical USB ports from the same COG.
But have this thinly veiled announcement that I'm working on sysclk/3 and 8 bit bus support for MegaYume instead (so it can run reliably on the big RAM board). Will appear in https://github.com/IRQsome/MegaYume/tree/dev before merge.
Ok. So far if you've got something working, do you find any noticeable increase in performance with the sysclk/3 vs sysclk/4 transfers for the large games that need the 96MB? I mean was it something that made a big visual difference in practice or helps make things (just) playable vs basically unplayable?
For some reason the first setting that works for sys/3 on the big board is 17 + sync data.. which I translate into your driver as (PSRAM_DELAY-9)<<13 + (PSRAM_SYNC_DATA?0:1)<<12. This however overflows (and thus readback breaks). Is it just not possible to set a delay that long? Where does that magic 9 come from, anyways?
I think it came from the fact that I only had a 3 bit field available to hold it (1 bit lost in the nibble for sync/async) and with the original HyperRAM code used I needed to offset to fit a useful range of delay values in the short bit field. Back then with HyperRAM on P2-EVAL we didn't operate the P2 as high and I think delay values ranging from like 5-6 up to 12 were okay over the P2 frequency range and I felt this was approximately centered in the range. I think it was also partially offset also by some extra instructions I put into the code. With different memories now, boards and higher P2 frequencies maybe this delay needs to be expanded by offsetting it even more and building more static delay into the read code.
@Wuerfel_21 said:
Got a translucent red RetroBit Megadrive controller today. Can confirm that one works as advertised. Is infact very red, too.
Now if only there was real 2 player support.
Well... I got basic hub support working... only for full speed devices though, so it is actually useful for multiple gamepads only (no keyboards, no mouse) with the hope that none of them is low speed only.
Before getting too excited, I still need to properly support multiple hid devices, so this will require a bit more time.
I'm not sure that all keyboards are low-speed. Would have to check my collection.
By "properly support multiple hid devices", do you just mean the descriptor parsing or general device handling? Because as previously exposited, I actually skip that part. Parsing the descriptor is worthless without some sort of controller mapping GUI thing. When the mappings are hardcoded into the program one can just skip the middleman and just read directly from the report.
Though I'd prefer if it didn't need a hub and you could just use two ports directly.
@Wuerfel_21 said:
By "properly support multiple hid devices", do you just mean the descriptor parsing or general device handling? Because as previously exposited, I actually skip that part. Parsing the descriptor is worthless without some sort of controller mapping GUI thing. When the mappings are hardcoded into the program one can just skip the middleman and just read directly from the report.
Proper support means being able to address all connected devices and notify the state somehow, currently it handles one device only, when you connect two or more controllers to the hub, the first configured is the only active one.
Though I'd prefer if it didn't need a hub and you could just use two ports directly.
That's impossible for me to do. Some things may be easy to make it working on two ports, but still there are too many things to duplicate. It needs two ISRs one for each port, then there are the context variables that keeps track of the transaction status that needs to be duplicated or something. Maybe moving all variables to hub, with block read/writes, still a lot of places to update. Honestly this will be too much work for me, and not sure it is worth the effort, AFAIK, all USB controllers on the PC motherboards are actually HUBs to support multiple ports.
@Wuerfel_21 Just verified 96 MB memory board working with MegaYume.
Also, can verify that XBox 360 controller (by Voyee) works.
However, the green xbox button in center keeps flashing green.
I think that means it isn't configured exactly right, not assigned a player #, but works anyway.
Here's my config and also the Windows Batch files I use to compile.
Comments
If player2 is already supported, can one use i2c and usb?
No, because the USB driver starts a cog, so the input high-level cog needs to stop itself to make room for the emulation cores.
You could in theory combine the other drivers (i.e. use SNES for player 1 and pins for player 2), but that's not supported because why-would-you-do-that?
looks like might be nunchuck adapters at ebay.de
not sure if "aus china" means comes from china or ships from china though...
Making some more 96 MB boards and testing it out.
Seems like it only works with basepin of 0 and 16. Doesn't seem to work on 32.
Can that be? Or, maybe I have some kind of pin conflict...
mmmmh maybe? could be trace length nonsense, could be some leftover debugging code driving on P38/39 (LEDs on EC32MB)
EDIT: Just checked, no leftover debug code. Maybe you got audio or smth conflicting on those pins?
Also, speaking of, you sure you're actually testing with something that uses all 6 banks? (this would be anything marked as 96 MB size in the compat list)
Even if the game needs 96 MB, seems you'd have to play the whole game to know if it works right?
Are maybe later levels stored in the upper banks?
In theory, yes. In practice the graphics are stored in semi-haphazard order, so between the attract sequence, the menus and the first level, a significant portion of memory is accessed. (And of course the program/audio/BIOS data ends up in the higher banks, anyways). Also the only way NeoYume will ever use the final bank is by loading a game that's actually large enough to need it. The last file loaded is always the BIOS, which of course fails catastrophically if it isn't working.
So I guess the ideal test would be a bunch of different sized games such that all banks have program/bios in them at one point, which makes failure really obvious. Or just write an actual memory test.
Ok, guess I'll use mslug5 and maybe some other to test the 96 mb boards...
Can't figure out the ruby romfix.rb...
By "neoyume directory" , do you mean on the PC or on the uSD disk?
Can't get either to work...
I made a mslug5 folder under NeoYume on uSD drive and copied presumably encryted files there.
copied romfix.rb to NeoYume folder on uSD drive.
opened dos prompt and navigated to NeoYume folder on uSD drive.
This is what I get:
It only recognizes mslug5h (the un-suffixed mslug5 is an earlier version that has leftover debug stuff when running on AES). The only difference are the program ROMs (called 268-p1c/p2c for the -h version and 268-p1cr/p2cr for the non-suffix version)
Ok, that looks a lot better. Got these two errors... Problem?
Yes, it's a problem... Won't run without...
Ok, tried a different one and it works!
One that is 79,148 kB doesn't work.
One that is 82,885 kB works.
Ye, as said, needs the version with 268-p1c/p2c. No idea why the M1 would be missing, that's kinda odd. Also, there's a mistake in the error message for PVC decryption, lol.
Ok, for the test suite for the 96 MB boards I now have:
Crossed Swords
Last blade
Metal Slug
Metal Slug 5
Sonic Wings 2
I just get into the actual game and then call it success.
This takes forever, but should be pretty good at finding flaws, from what @Wuerfel_21 just said...
I think that actually works out such that each bank has program or bios in it at least once:
Crossed Swords: prog/bios both in bank 0
Last blade: prog in bank 2, bios in bank 3
Metal Slug: prog/bios both in bank 1
Metal Slug 5: prog in bank 4, bios in bank 5
Sonic Wings 2: prog/bios both in bank 0
Got a translucent red RetroBit Megadrive controller today. Can confirm that one works as advertised. Is infact very red, too.
Now if only there was real 2 player support.
Is this a slightly veiled announcement you are looking into hub support for the P2 USB driver...? Or something that manages both physical USB ports from the same COG.
No, not really.
But have this thinly veiled announcement that I'm working on sysclk/3 and 8 bit bus support for MegaYume instead (so it can run reliably on the big RAM board). Will appear in https://github.com/IRQsome/MegaYume/tree/dev before merge.
Ah yes
Ok. So far if you've got something working, do you find any noticeable increase in performance with the sysclk/3 vs sysclk/4 transfers for the large games that need the 96MB? I mean was it something that made a big visual difference in practice or helps make things (just) playable vs basically unplayable?
I think you only need one chip for MegaYume...
Oh, this is just making it work in MegaYume, which currently only supports sys/2.
I've talked about sys/3 for NeoYume before. Yes, it good. sys/4 8 bit is not enough to sustain full 96 sprites on a line, sys/3 is.
Also, @rogloh
For some reason the first setting that works for sys/3 on the big board is 17 + sync data.. which I translate into your driver as
(PSRAM_DELAY-9)<<13 + (PSRAM_SYNC_DATA?0:1)<<12. This however overflows (and thus readback breaks). Is it just not possible to set a delay that long? Where does that magic9come from, anyways?I think it came from the fact that I only had a 3 bit field available to hold it (1 bit lost in the nibble for sync/async) and with the original HyperRAM code used I needed to offset to fit a useful range of delay values in the short bit field. Back then with HyperRAM on P2-EVAL we didn't operate the P2 as high and I think delay values ranging from like 5-6 up to 12 were okay over the P2 frequency range and I felt this was approximately centered in the range. I think it was also partially offset also by some extra instructions I put into the code. With different memories now, boards and higher P2 frequencies maybe this delay needs to be expanded by offsetting it even more and building more static delay into the read code.
Hmmm. The correct offset seems to be different for sys/3 mode. Will have to investigate tomorrow.
Well... I got basic hub support working... only for full speed devices though, so it is actually useful for multiple gamepads only (no keyboards, no mouse) with the hope that none of them is low speed only.
Before getting too excited, I still need to properly support multiple hid devices, so this will require a bit more time.
I'm not sure that all keyboards are low-speed. Would have to check my collection.
By "properly support multiple hid devices", do you just mean the descriptor parsing or general device handling? Because as previously exposited, I actually skip that part. Parsing the descriptor is worthless without some sort of controller mapping GUI thing. When the mappings are hardcoded into the program one can just skip the middleman and just read directly from the report.
Though I'd prefer if it didn't need a hub and you could just use two ports directly.
Proper support means being able to address all connected devices and notify the state somehow, currently it handles one device only, when you connect two or more controllers to the hub, the first configured is the only active one.
That's impossible for me to do. Some things may be easy to make it working on two ports, but still there are too many things to duplicate. It needs two ISRs one for each port, then there are the context variables that keeps track of the transaction status that needs to be duplicated or something. Maybe moving all variables to hub, with block read/writes, still a lot of places to update. Honestly this will be too much work for me, and not sure it is worth the effort, AFAIK, all USB controllers on the PC motherboards are actually HUBs to support multiple ports.
@Rayman yo I just pushed support for the 96MB board into the MegaYume repo. Can you confirm workingness?
@Wuerfel_21 Just verified 96 MB memory board working with MegaYume.
Also, can verify that XBox 360 controller (by Voyee) works.
However, the green xbox button in center keeps flashing green.
I think that means it isn't configured exactly right, not assigned a player #, but works anyway.
Here's my config and also the Windows Batch files I use to compile.