S0urceror / MSX-USB

Schematics, drivers, debug tools, to make USB devices on the MSX a reality
GNU General Public License v2.0
65 stars 18 forks source link

CH376S v2 and v3 stability #10

Closed cristianoag closed 2 years ago

cristianoag commented 2 years ago

I built one of the MSX-USB boards, programmed the ATF1504AS and the SST39SF040 (with nextor.rom found here in the repo). Initially I built the board with a CH376S v2 and noticed it was super unstable. Sometimes it was detecting the USB stick ok and loading MSX-DOS, sometimes it was just saying "USB not detected". Sometimes it was loading the MSX-DOS but after some time disk operations couldn't be executed anymore with a disk error. Super strange.

Troubleshooting I replaced the ATF1504AS by another one, same behavior. Replaced the SST39SF040 by another one, same errors. Then I decided to solder a female pin header and experiment with multiple CH376S versions. I noticed that with v3 it is a lot more stable. I managed to even load a game from the USB, but still had some issues (less frequent tough).

For example right now with V3 I executed a dir just ok. Went here to write this and when I came back, when executing dir again I just got no files on the disk. 0 bytes in 1 file! :/

20220130_190822679_iOS 20220130_220405175_iOS 20220130_220202432_iOS

Is it something you also observe? Am I missing something? Any tips?

cristianoag commented 2 years ago

More time investigating. I flashed the nextor.rom image available here https://github.com/issalig/MSX-USB/blob/master/drivers/NextorUsbHost/dist/nextor.rom and that one seems more stable. Now I can use CH276S v2 or v3. Errors are still happening, but it seems that old version works better with v2.

S0urceror commented 2 years ago

Hi Cristiano,

v3 is indeed a bit more stable then v2. I recently did some test together with Issalig and fixed a couple of things. Could be he has that version on his Github. I have attached this version (NEXTOR.ROM) to this email as well.

Let me know how this goes.

P.S. I am also working on a completely different driver (MSXUSBNext) that only supports USB drives not other USB devices. This thing allows you to choose a .DSK image from a FAT16 or FAT32 formatted USB. I have also included that version here.

Regards,

Mario

From: Cristiano Goncalves @.> Date: Monday, 31 January 2022 at 02:25 To: S0urceror/MSX-USB @.> Cc: Subscribed @.***> Subject: Re: [S0urceror/MSX-USB] CH376S v2 and v3 stability (Issue #10)

More time investigating. I flashed the nextor.rom image available here https://github.com/issalig/MSX-USB/blob/master/drivers/NextorUsbHost/dist/nextor.rom and that one seems a more stable. Now I can use CH276S v2 or v3. Errors are still happening, but it seems that old version works better with v2.

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/10#issuecomment-1025295515, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KAJBVJO37PM3EXGTPDUYXQJXANCNFSM5NEY2JPQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.Message ID: @.***>

cristianoag commented 2 years ago

Great if we can have a version dedicated to storage and another focused on extensibility. I haven't received any file attached... I think github stripes files out when sending e-mails. Can you send to **@.*** instead?

We can use the Nextor MAPDRV tool to map dsk files into different units. Maybe we just need to concentrate in support larger partitions.

If you can also explain how you're connecting the CH376S to OpenMSX we can actually help you with the code. I'm planning to use a Linux running on the raspberry pi so I can connect the CH376 to its pin headers. Is that the approach you're using? I'll have to recompile OpenMSX to adapt that approach tough.

S0urceror commented 2 years ago

Hi Cristiano,

My setup looks like this:

For the MSX in openMSX it looks like it is talking to the real device with the same response. Only timing is different than on the physical hardware. Sometimes that is were the problems come from. But most of the times it is devices that are not behaving as the standard says.

Regards,

Mario

From: Cristiano Goncalves @.> Date: Monday, 31 January 2022 at 18:01 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, Comment @.> Subject: Re: [S0urceror/MSX-USB] CH376S v2 and v3 stability (Issue #10)

Great if we can have a version dedicated to storage and another focused on extensibility. I haven't received any file attached... I think github stripes files out when sending e-mails. Can you send to @.**@.> instead?

If you can also explain how you're connecting the CH376S to OpenMSX we can actually help you with the code. I'm planning to use a Linux running on the raspberry pi so I can connect the CH376 to its pin headers. Is that the approach you're using? I'll have to recompile OpenMSX to adapt that approach tough.

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/10#issuecomment-1025998685, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KGY3FTDMNBUWF6V32DUY2557ANCNFSM5NEY2JPQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

cristianoag commented 2 years ago

Amazing. I will work asap to setup my dev environment. Looking into your code I see those stability issues may be caused by the way you are doing time synchronization on your code. I see you have routines to wait across the code and I think the recommended approach would be hooking something to the timer interrupt routine (DRV_TIMI:) instead. I agree it is a much more complex code, but to have MSX-USB rock solid we may need to attack that front as well.

S0urceror commented 2 years ago

I do waits by counting down a number of HALTs. When interrupts are enabled this should give an approximation of 1/50th or 1/60th of a second. I made sure to be a bit on the upper end of the needed wait. This is not so critical. Unless you have a drive that needs a lot more time to respond.

From: Cristiano Goncalves @.> Date: Monday, 31 January 2022 at 20:40 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, Comment @.> Subject: Re: [S0urceror/MSX-USB] CH376S v2 and v3 stability (Issue #10)

Amazing. I will work asap to setup my dev environment. Looking into your code I see those stability issues may be caused by the way you are doing time synchronization on your code. I see you have routines to wait across the code and I think the recommended approach would be hooking something to the timer interrupt routine (DRV_TIMI:) instead. I agree it is a much more complex code, but to have MSX-USB rock solid we may need to attack that front as well.

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/10#issuecomment-1026140218, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KFT6FQ3RJ56GE3X6FDUY3QUJANCNFSM5NEY2JPQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

cristianoag commented 2 years ago

Lol. Only my oldest thumb drive actually works with msxusb. And I have more than 20 laying around here. Only one works ok. I would say it it is pretty old.

Get Outlook for iOShttps://aka.ms/o0ukef


From: S0urceror @.> Sent: Monday, January 31, 2022 5:01:21 PM To: S0urceror/MSX-USB @.> Cc: Cristiano Goncalves @.>; Author @.> Subject: Re: [S0urceror/MSX-USB] CH376S v2 and v3 stability (Issue #10)

I do waits by counting down a number of HALTs. When interrupts are enabled this should give an approximation of 1/50th or 1/60th of a second. I made sure to be a bit on the upper end of the needed wait. This is not so critical. Unless you have a drive that needs a lot more time to respond.

From: Cristiano Goncalves @.> Date: Monday, 31 January 2022 at 20:40 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, Comment @.> Subject: Re: [S0urceror/MSX-USB] CH376S v2 and v3 stability (Issue #10)

Amazing. I will work asap to setup my dev environment. Looking into your code I see those stability issues may be caused by the way you are doing time synchronization on your code. I see you have routines to wait across the code and I think the recommended approach would be hooking something to the timer interrupt routine (DRV_TIMI:) instead. I agree it is a much more complex code, but to have MSX-USB rock solid we may need to attack that front as well.

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/10#issuecomment-1026140218, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KFT6FQ3RJ56GE3X6FDUY3QUJANCNFSM5NEY2JPQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FS0urceror%2FMSX-USB%2Fissues%2F10%23issuecomment-1026155794&data=04%7C01%7C%7C397c4e3821d9444da3be08d9e4f473f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637792560833770420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yndwBBCQ1ssJelWtj6l4Ca%2FnntSzUpqiMDl8cUZN8A0%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALSAPKQZ32YJ3R3BS6DX2JLUY3TBDANCNFSM5NEY2JPQ&data=04%7C01%7C%7C397c4e3821d9444da3be08d9e4f473f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637792560833770420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mzNw2%2B%2B5JylL6e2OPPhdKwYPVIlQQrj2mBz2B1wiNmE%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

cristianoag commented 2 years ago

Well. Not mixing this issue with the other one reported by issalig on the flash drives not supported. The only one that actually work for me has the following output from lsusb:

Bus 001 Device 006: ID 058f:6387 Alcor Micro Corp. Flash Drive Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x058f Alcor Micro Corp. idProduct 0x6387 Flash Drive bcdDevice 1.03 iManufacturer 1 Generic iProduct 2 Mass Storage iSerial 3 DCA6127E bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0

It is funny that I have other one that has exactly the same parameters. Both work on Linux and Windows, but just one work with MSXUSB.

cristianoag commented 2 years ago

Here is the thing. Did a collection of all USB thumb drives from all members of my family. Got another one that work flawlessly. I think the issue is in fact with the other one I have that kind of work, but not 100% compatible. Let's close this one and stop spending time with this. The issue is only that there are so few types that actually work ok.

cristianoag commented 2 years ago

Still facing the issue. It is just less frequent with the new flash drive.