SD2SNES, sending rom over USB?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: SD2SNES, sending rom over USB?
Hey, saturnu,
thanks a lot, this could indeed come in handy.
However, when trying to issue any command like you posted, I get a "character device file does not exist" error, whatever that means. I tried it with --device=0 through --device=5.
What am I doing wrong (aside from not using Windows )?
thanks a lot, this could indeed come in handy.
However, when trying to issue any command like you posted, I get a "character device file does not exist" error, whatever that means. I tried it with --device=0 through --device=5.
What am I doing wrong (aside from not using Windows )?
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
I looked at the code. You need to specify the full path of the serial port device in /dev, i.e. --device=/dev/ttyS0. It's going to vary based on disto, kernel, and serial port IC; sometimes it's /dev/ttyACMx. You'll need to dig around in dmesg and so on to figure out what the appropriate device name is. Important: the device needs to be a character device, not a block device. ls -l will show you this; see the far left field ("d" meaning directory, etc.)? "c" means character device, "b" means block device, etc..
The port may need to be pre-configured for 9600 baud, 8N1 (tou can accomplish this with stty), BUT, it looks like init_portio() should do this for you through cf*speed() functions and setting the appropriate terminal capabilities on the device.
P.S. -- I want to say that it makes me very happy to see this type of code in this day and age. Yeah, there's a lot of use of magic numbers in it, so it needs to be cleaned up, but it's a great example of serial I/O interfacing on *IX -- something that isn't done much any more. Seeing it made me happy. :-)
The port may need to be pre-configured for 9600 baud, 8N1 (tou can accomplish this with stty), BUT, it looks like init_portio() should do this for you through cf*speed() functions and setting the appropriate terminal capabilities on the device.
P.S. -- I want to say that it makes me very happy to see this type of code in this day and age. Yeah, there's a lot of use of magic numbers in it, so it needs to be cleaned up, but it's a great example of serial I/O interfacing on *IX -- something that isn't done much any more. Seeing it made me happy. :-)
Re: SD2SNES, sending rom over USB?
first you need to put the usb firmware into the /sd2snes folder.
after starting the snes, the os should detect the new usb device.
under windows you may want to install the sd2snes.inf file, but for me using windows 10, the cdc device was recognized out of the box.
check out the device manager "Ports (COM & LPT)" to see what COM number is mapped to the device.
if there is something new under "Other devices" try to use the sd2snes.inf as a driver.
i'm not sure from memory, if you need to start usb2snes.exe as administrator or not.
COM6 would be:
# usb2snes.exe --device=6
under linux it's using the cdc_acm module
# lsmod
Module Size Used by
cdc_acm 32768 0
# dmesg
[ 1022.869276] usb 1-11: new full-speed USB device number 4 using xhci_hcd
[ 1023.055115] cdc_acm 1-11:1.0: ttyACM0: USB ACM device
[ 1023.055253] usbcore: registered new interface driver cdc_acm
[ 1023.055254] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
in this example it's
# usb2snes --device=/dev/ttyACM0
in your case ii looks like you want to use a COM-Port number within linux. ^^
what you really need to specify is the char device filename.
after starting the snes, the os should detect the new usb device.
under windows you may want to install the sd2snes.inf file, but for me using windows 10, the cdc device was recognized out of the box.
check out the device manager "Ports (COM & LPT)" to see what COM number is mapped to the device.
if there is something new under "Other devices" try to use the sd2snes.inf as a driver.
i'm not sure from memory, if you need to start usb2snes.exe as administrator or not.
COM6 would be:
# usb2snes.exe --device=6
under linux it's using the cdc_acm module
# lsmod
Module Size Used by
cdc_acm 32768 0
# dmesg
[ 1022.869276] usb 1-11: new full-speed USB device number 4 using xhci_hcd
[ 1023.055115] cdc_acm 1-11:1.0: ttyACM0: USB ACM device
[ 1023.055253] usbcore: registered new interface driver cdc_acm
[ 1023.055254] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
in this example it's
# usb2snes --device=/dev/ttyACM0
in your case ii looks like you want to use a COM-Port number within linux. ^^
what you really need to specify is the char device filename.
Re: SD2SNES, sending rom over USB?
Thanks, guys. I'm on Linux, and honestly, I have no idea how to determine a specific USB port's (that my USB-->USB mini cable is connected to, with the sd2snes connected on the other end, and powered) device name. My workstation has 8 USB 2.0 ports, in case that helps.
Aww, never mind. I can still go by the old method of transferring my ROM onto the card, etc.
Aww, never mind. I can still go by the old method of transferring my ROM onto the card, etc.
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
it's an easy way to get around using extra proprietary drivers or libusb (on any of the major os). ^^koitsu wrote: something that isn't done much any more.
... and you don't have to hassle with driver signing by microsoft (or the installation of unsigned drivers).
btw: the project has a pid
http://pid.codes/org/ikari_01/
Re: SD2SNES, sending rom over USB?
[$tt@nana ~]. lsusb --tree
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 11: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 11: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
or just use
[$tt@nana ~]. dmesg
to see if a new device registered
try /dev/ttyACM0 instead of /dev/ACM0
or /dev/ttyUSB0
/dev/ttySx are more or less real oldschool serial ports
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 11: Dev 5, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 11: Dev 5, If 1, Class=CDC Data, Driver=cdc_acm, 12M
|__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
or just use
[$tt@nana ~]. dmesg
to see if a new device registered
try /dev/ttyACM0 instead of /dev/ACM0
or /dev/ttyUSB0
/dev/ttySx are more or less real oldschool serial ports
Re: SD2SNES, sending rom over USB?
Thank you, saturnu! With dmesg, I was indeed able to identify the sd2snes' port, but still ...
... I get a "device: file open error" even though the ROM file definitely exists, as you can see in the screenshot (note that the error persists even if I use ./furryrpg.sfc instead of plain old furryrpg.sfc). The exact same thing happens for SRAM, BTW.
Sorry to keep you bothering with this, but the --verbose option doesn't really offer any substantial help either, so ...
... I get a "device: file open error" even though the ROM file definitely exists, as you can see in the screenshot (note that the error persists even if I use ./furryrpg.sfc instead of plain old furryrpg.sfc). The exact same thing happens for SRAM, BTW.
Sorry to keep you bothering with this, but the --verbose option doesn't really offer any substantial help either, so ...
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
"device: file open error" isn't talking about the ROM not being open-able, it's talking about the /dev/ttyACM3 device. I will give you the root cause/answer at the end, but here's the code:
Flags O_RDWR = open device with read-write capability, O_NOCTTY = don't assign a controlling terminal (this matters for tty devices, which sometimes serial devices can be classified as). In other words: the Linux kernel (and/or device drivers) rejects the open() call (returns -1); the author of this code could do well to use perror() or strerror() to print human-readable errno so that you could at least get a little more detail. In this case, I would bet money errno==EACCES (Permission denied). Had the program done that, you would've had a little more idea what might be wrong (maybe).
But the root cause of why this isn't working? You're running this program as yourself, a non-root user. Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands). I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
You can even see that the usage syntax for this command (usb2snes -h or --help) advocates it in the code (I have no clue why this usage syntax tries to show a *IX device path as \dev\ttyACMx -- these slashes are backwards/wrong, *IX uses / not \.)
Code: Select all
if( check_chr(device) != 1) {
printf("character device file does not exist!\n");
return -1;
}else{
fd=open(device, O_RDWR | O_NOCTTY);
if (fd==-1) {
printf("device: file open error\n");
}
}
But the root cause of why this isn't working? You're running this program as yourself, a non-root user. Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands). I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
You can even see that the usage syntax for this command (usb2snes -h or --help) advocates it in the code (I have no clue why this usage syntax tries to show a *IX device path as \dev\ttyACMx -- these slashes are backwards/wrong, *IX uses / not \.)
Code: Select all
if( gopt( options, 'h' ) ) {
#ifdef __unix__
//unix
fprintf( stdout, "Syntax: sudo ./usb2snes -d \\dev\\ttyACMx [options] ...\n\n");
Re: SD2SNES, sending rom over USB?
Thanks, koitsu, but no thanks. Sorry, but we aren't living in the early 2000s any more, where you had to open a root shell just to enable WiFi functionality for your state-of-the-art notebook. If this (i.e., root access to my system) is what this software requires to run, then goodbye and Godspeed, software.koitsu wrote:Serial devices (and most devices in general!) cannot be opened by non-root users. Try putting sudo in front of the entire command you're doing, or switch to root entirely (sudo -i then run the commands).
Reverting back to vanilla 0.1.7c in 3 … 2 … 1 … bam.
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
A better option than becoming root would be to either add yourself to the "dialout" group (at least that's what it's called on debian, you can look at the /dev/ttyACM* node to find out what group owns it), or to change the permissions on the /dev/ttyACM* node so that you can access it as an unprivileged user.
Re: SD2SNES, sending rom over USB?
for me it's uucp and yes the backslash instead of a slash is of course a typo. ^^
crw-rw---- 1 root uucp 166, 0 31. Aug 21:38 /dev/ttyACM0
# usermod -a -G uucp saturnu
crw-rw---- 1 root uucp 166, 0 31. Aug 21:38 /dev/ttyACM0
# usermod -a -G uucp saturnu
Re: SD2SNES, sending rom over USB?
Not going to do any of that, either.lidnariq wrote:A better option than becoming root would be to either add yourself to the "dialout" group (at least that's what it's called on debian, you can look at the /dev/ttyACM* node to find out what group owns it), or to change the permissions on the /dev/ttyACM* node so that you can access it as an unprivileged user.
Does ucon64 require root privileges? Does it require any workaround BS (sorry)? No! No, it doesn't. I know because I've been using ucon64 with my SWC devices for ages, even on 64-bit Linux systems.
So why would any new transfer software require higher user privileges than ucon64 does? … Right. Don't use this software (sorry, saturnu).
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
I covered this in:
If you want to accomplish this, go look at the ownership and permissions on /dev/ttyACM3. It's probably owned by root, possibly group wheel. Check the permissions: does group have read/write access, or just read? If the group has read/write access, then add yourself to whatever that group is (it might be wheel, it might be dialout, it might be something else), then you should have the ability to R/W the device without being root.
If the group has no read/write access at all, then you need to look into what is managing the devices on your Linux distro to figure out how you can improve/change the permissions for that device. As stated: devfs and systemd are the two main ones on Linux right now. You *absolutely* can do this, including giving it its own group (lidnariq mentioned the group dialout, but it can be whatever; see /etc/group).
As a crappy workaround, you could also avoid worrying about the group entirely and just tweak whatever (devfs/systemd rules) to make the device have permissions of 0666 (specifically: globally read/write) so that you don't even need to worry about the group. The security risk here is that any user (including any non-root process or daemon) could be able to access the device. It's your call.
...but now I'm apparently having to do exactly that.I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
If you want to accomplish this, go look at the ownership and permissions on /dev/ttyACM3. It's probably owned by root, possibly group wheel. Check the permissions: does group have read/write access, or just read? If the group has read/write access, then add yourself to whatever that group is (it might be wheel, it might be dialout, it might be something else), then you should have the ability to R/W the device without being root.
If the group has no read/write access at all, then you need to look into what is managing the devices on your Linux distro to figure out how you can improve/change the permissions for that device. As stated: devfs and systemd are the two main ones on Linux right now. You *absolutely* can do this, including giving it its own group (lidnariq mentioned the group dialout, but it can be whatever; see /etc/group).
As a crappy workaround, you could also avoid worrying about the group entirely and just tweak whatever (devfs/systemd rules) to make the device have permissions of 0666 (specifically: globally read/write) so that you don't even need to worry about the group. The security risk here is that any user (including any non-root process or daemon) could be able to access the device. It's your call.
Re: SD2SNES, sending rom over USB?
No.koitsu wrote:I covered this in:...but now I'm apparently having to do exactly that.I won't get into an explanation of how to change the file permissions on a device if you *really need* be able to do this as a non-root user (devfs or systemd on Linux is responsible for that).
Again, check out ucon64. There's just no need for root permissions in this day and age.
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Re: SD2SNES, sending rom over USB?
you don't have to apologize, to honest - i don't really care if you use it or not. ^^
it's ok that you are a linux beginner and i think someone else can still profit from the infos on this thread.
it's ok that you are a linux beginner and i think someone else can still profit from the infos on this thread.