+DrVenkman Posted October 22, 2018 Share Posted October 22, 2018 aren't all uno's ch340 and ch341 compat..... but the trailing letter differs... No. Pretty sure at least some have FTDI serial chips. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 22, 2018 Share Posted October 22, 2018 (edited) could be on earlier ones, I just looked at about 30 uno listings all ended up as ch340 uno are not full on ardi's in that respect max232's on some.... looks like whatever is handy and cheap is plopped on these china boards looked further and it appears folks have found it can get worse with fake laser id's etched on chips... does not matter, like I said.... finding what chips we all have would be the first step in solving this. Edited October 22, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted October 22, 2018 Share Posted October 22, 2018 The ones I've built (both Type B / micro B) are all CH340G. This may be inconsequential - but has anyone actually traced those vias in the middle of the board to see if they are 100% equivalent of the outer connectors? Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 22, 2018 Share Posted October 22, 2018 According to Arduino themselves, officially it will be the ATMega16U2... It only seems to be clones that have a basic USB->Serial adapter... But, if having that works for some, it should work for all.. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted October 23, 2018 Share Posted October 23, 2018 According to Arduino themselves, officially it will be the ATMega16U2... It only seems to be clones that have a basic USB->Serial adapter... But, if having that works for some, it should work for all.. Yeah, correct. Did more research since my off-the-cuff reply to _The Doctor_ this morning. The SDrive-Max units I've built have used "Hiletgo" branded clone boards with the CH340G. However, the Elegoo-branded clone board I have (from an Arduino starter/experimenter's kit has an ATMega16U2. (This is the board that came with my kit: https://www.amazon.com/Elegoo-EL-CB-001-ATmega328P-ATMEGA16U2-Arduino/dp/B01EWOE0UU/ref=sr_1_3?ie=UTF8&qid=1540256176&sr=8-3&keywords=arduino+uno) Quote Link to comment Share on other sites More sharing options...
Level42 Posted November 27, 2018 Share Posted November 27, 2018 Right well....Not happy.... I’ve been playing around to get my Sdrive Max make nice images of my original floppies....yeah I know, I can download it all, but still... The closes to success I have been is actually making a New image on the Sdrive, formatting it and copying a disk to it. It even worked loading etc, However, I can’t say I found the transfer to sound very normal or reliable. It sounds like there are loads of constant retries going on. During the process of copying and formatting etc. I noticed that after trying to copy Stuntdriver ATR to a real floppy Stuntdriver wouldn’t load from my Sdrive anymore, it seemed the file was damaged....next I realised that it is quite possible Stuntdriver never fits on a real floppy .....or maybe I made a mistake and ruined the ATR on my SD card myself. No Biggy can copy it back of course. However, the worst thing ist happened: my Sdrive Max won’t boot up anymore now.....this was after trying out more stuff. When I now boot up from D0....or rather, try, I get an error that SDRIVE.ATR is missing.....how can that be ??? Somehow, during all the fiddling apparently something was written to the SD card in a bad way....damaging or maybe deleting the SDRIVE.ATR.... Naturally I was so stupid to not have a full backup of the SD ard....no issue, I can all download it again but still quite a bit of work, But the bottom line is that at this moment I would NOT recommend Sdrive for any corporation with a real floppy drive.. My set up: 600XL with U1MB 1050 with Megadpeedy (tried most stuff in original 1050 setting) Sdrive Max with 0.9 firmware 1 Quote Link to comment Share on other sites More sharing options...
Fred_M Posted November 27, 2018 Share Posted November 27, 2018 My experiences so far. SDrive MAX built and flashed by Level42. The diode was put in last Sunday. Firmware 0.9 Setup: 130XE (stock) -> D1: XF551 (XFspeedy turned off) -> D2: SDrive MAX (D1: empty) When I try to boot something from D1 both devices seem to respond. So boot errors 130XE (stock) -> D1: SDrive MAX (D2-D4: empty) -> D2: XF551 (XFspeedy turned off) Booting from D1 works. It is possible to get a directory from D2. Copying with sectorcopier (Copy 2000 and MycopyR) results in reading D1 perfectly but writing to a physical disk (D2) results in writing errors (new disk, tried several). When I unplug the SDrive MAX (D1) and restart the writing on D2 it writes (to the same disk!) perfectly. 130XE (stock) -> D1: Sdrive Max (ATR) -> D2: Sdrive Max (NEW) The computer cannot boot at all. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 27, 2018 Share Posted November 27, 2018 why does everyone keep using 0.9? Oh well. moving on... Quote Link to comment Share on other sites More sharing options...
SS Posted November 27, 2018 Author Share Posted November 27, 2018 (edited) However, the worst thing ist happened: my Sdrive Max wont boot up anymore now.....this was after trying out more stuff. When I now boot up from D0....or rather, try, I get an error that SDRIVE.ATR is missing.....how can that be ??? Somehow, during all the fiddling apparently something was written to the SD card in a bad way....damaging or maybe deleting the SDRIVE.ATR.... I had the same trouble myself and solved it by simply recopying an uncorrupted version of SDRIVE.ATR onto my SD card. If that doesn't work, couldn't you just reflash the entire device? BTW, I still have not been able to get my SDRIVE-MAX to successfully communicate with any other devices on my SIO chain. Edited November 27, 2018 by SS Quote Link to comment Share on other sites More sharing options...
Fred_M Posted November 27, 2018 Share Posted November 27, 2018 I forgot to mention that one ATR on my SDrive Max was damaged too during my testing. Quote Link to comment Share on other sites More sharing options...
Fred_M Posted November 27, 2018 Share Posted November 27, 2018 (edited) why does everyone keep using 0.9? Oh well. moving on... Okay, I just flashed version 1.0b. The SDrive Max is more stable, but still problems. 130XE (stock) -> D1: XF551 (XFspeedy turned off) -> D2: SDrive MAX (D2: MYCOPYR.ATR) Booting from D1 works now. Loading MycopyR. Reading from D2 works fine, after reading D1 starts formatting and write a few sectors before write errors start to appear. When I unplug D2 (Sdrive) - and restart the writing process to D1 (XF551) from memory formatting and writing works perfectly. So when the SDrive is attached I get writing errors. 130XE (stock) -> D1: SDrive MAX (D1:MYCOPYR.ATR) -> D2: XF551 (new blank disk | XFspeedy turned off) Booting from D1 works. Loading MycopyR. Reading from D1 works but an occasional reading time out error (tested several times, always at different sectors), after reading D2 starts formatting and write a few sectors before write errors start to appear. When I unplug D1 (Sdrive) - and restart the writing process to D2 (XF551) from memory formatting and writing works perfectly. So when the SDrive is attached I get writing errors. 130XE (stock) -> D1: Sdrive Max (MYCOPYR.ATR) -> D2: Sdrive Max (NEW) Booting from D1 works now (firmware 1.0b). Loaded MycopyR. MycopyR does not see D2. I cannot format D2, because it is not recognised. Edited November 27, 2018 by Fred_M Quote Link to comment Share on other sites More sharing options...
SS Posted November 27, 2018 Author Share Posted November 27, 2018 why does everyone keep using 0.9? Oh well. moving on... I upgraded to v 1.0b. Most everything else is working fantastically now; I just cannot use the SDRIVE-MAX in my SIO chain. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted November 27, 2018 Share Posted November 27, 2018 I upgraded to v 1.0b. Most everything else is working fantastically now; I just cannot use the SDRIVE-MAX in my SIO chain. I have had very mixed results with the SDrive-MAX's ability to coexist reliably with physical drives. It's very dependent on firmware timing, much more so, it seems to me, than it is on the presence or absence of a diode in the signal path. This has been with v0.7, v0.8, v0.9 and two flavors of 1.0b (the official one from the GitHub repo and the inaccurately named "no diode" modifications made by an AA member). So I've come to the conclusion for now that the highest and best use for the SDrive-MAX is as a standalone, "do it all" storage device for machines without physical drives attached. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 28, 2018 Share Posted November 28, 2018 4 drives and a cassette doesn't do it for me... 8 drives and cassette is a good start... Quote Link to comment Share on other sites More sharing options...
SS Posted November 28, 2018 Author Share Posted November 28, 2018 I've come to the conclusion for now that the highest and best use for the SDrive-MAX is as a standalone, "do it all" storage device for machines without physical drives attached. I have come to pretty much the same conclusion. My plan now is to either figure out the problem with my 600XL or to get a new 600XL (or maybe just a new motherboard if possible), install my Antonia and Sophia boards in it, and use the SDRIVE-MAX as its only SIO peripheral. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted November 28, 2018 Share Posted November 28, 2018 (edited) Okay, I'm past my window to edit posts with some udpated results, but having said that, what I found only supports what I wrote earlier tonight about firmware timing mattering more than anything with regard to inter-device compatibility. On a hunch I checked KRB's Github directory and looked at the current 1.0 branch (https://github.com/kbr-net/sdrive-max/tree/v10). Sure enough, there have been some changes to core functions in the last 2 - 3 weeks, which is newer than the most recent version I had installed. I compiled new .hex files, wrote them to my device and whaddaya know? My SDrive-MAX now coexists nicely with my Happy 1050 (set as D1:). I was able to successfully read and write files from one device to the other in both directions using my 1088XEL. For Level42 - I was also able to create a new blank disk image and format it although I could only do so under Atari DOS 2.5; SpartaDOS 4.49c's FORMAT utility gives an error and says the device doesn't respond. However, booting DOS 2.5 from a floppy in D1: and the new blank image as D2: in the SDrive-MAX, DOS could format the disk and write DOS files to it. I could then swap that image into the D1: slot, turn off my physical drive and boot the computer from the newly-formatted image. I don't know why SDX chokes and doesn't recognize the image, nor did I try booting the computer from a disk version of SpartaDOS or any other DOS. Anyway, I've attached the version I compiled tonight. I'd be curious to see if this version works better for others as well. sdrive-max-10-20181127.zip Edited November 28, 2018 by DrVenkman Quote Link to comment Share on other sites More sharing options...
SS Posted November 28, 2018 Author Share Posted November 28, 2018 OMG - I just wrote a huge response and my browser glitched and wiped it all out. I do not have the energy to write it all again tonight. Short story is that with this new firmware my 1050 and SDRIVE-MAX were able at least to see each other in DOS when directly connected but were unable to read/write. The 1050 was also unable to successfully format a floppy when the SDRIVE-MAX was connected. Somewhat surprisingly though, SDRIVE-MAX and SIO2SD were able to both read and write together when attached to my SIO hub. When I attached the 1050 to the hub, the Atari was unable to see it at all. Quote Link to comment Share on other sites More sharing options...
Level42 Posted November 28, 2018 Share Posted November 28, 2018 (edited) Reason why I was still at 0.9 because I wanted to only change one variable (the diode) at once which is good common practice in IT/tech. I just wanted to post a screenshot of the contents of my SD card.....I was quite baffled to see this.... Edited November 28, 2018 by Level42 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted November 29, 2018 Share Posted November 29, 2018 OMG - I just wrote a huge response and my browser glitched and wiped it all out. I do not have the energy to write it all again tonight. Short story is that with this new firmware my 1050 and SDRIVE-MAX were able at least to see each other in DOS when directly connected but were unable to read/write. The 1050 was also unable to successfully format a floppy when the SDRIVE-MAX was connected. Somewhat surprisingly though, SDRIVE-MAX and SIO2SD were able to both read and write together when attached to my SIO hub. When I attached the 1050 to the hub, the Atari was unable to see it at all. Well, shoot. That's disappointing. My current SIO tree is: 1088XEL --> Happy 1050 (D1:) --> stock 1050 (D2:, but powered off last night) --> SDrive-MAX The 1088XEL's internal Sparkfun SIO2PC-USB device is also connected to the bus (and to an attached RPiZeroW via USB) but none of the slots in RespeQt were loaded with any disk images. I will test further later in the week (powering on my D2: floppy, using the SDrive-MAX with both my floppy drives and RespeQt via the internal Sparkfun board, and also inserting my P:R:Connection back into the mix somewhere. I've rearranged the home network and don't currently have a way to connect the attached Lantronix box to the network until I buy a new wifi extender, so I've had the P:R:Connection out of the chain for a few months. But for testing it wouldn't hurt to reconnect it just to see if it changes anything. Quote Link to comment Share on other sites More sharing options...
SS Posted November 29, 2018 Author Share Posted November 29, 2018 (edited) Short story is that with this new firmware my 1050 and SDRIVE-MAX were able at least to see each other in DOS when directly connected but were unable to read/write. The 1050 was also unable to successfully format a floppy when the SDRIVE-MAX was connected. Somewhat surprisingly though, SDRIVE-MAX and SIO2SD were able to both read and write together when attached to my SIO hub. When I attached the 1050 to the hub, the Atari was unable to see it at all. What happened when the SDRIVE-MAX and 1050 were directly connected was that when I was trying to copy, the SDRIVE-MAX would read the ATR and then the 1050 would start the write process. Then after 10-15 seconds or so, the 1050 would just stop and wait. If I turned off the SDRIVE-MAX at this point, the 1050 would start back up and continue trying to write. Of course, the process needed to return to the read portion on the SDRIVE-MAX at some point so I was unable to complete the full disk copy. The same thing happened when trying to format a floppy with the SDRIVE-MAX attatched. The format process would start up and run for 15 seconds or so and then just stop and wait. If I switched off the SD-MAX at this point, the 1050 would kick back on and finish the disk format process. This all only goes this way when the 1050 and SDRIVE-MAX are directly connected. When both are connected through my SIO hub, DOS2.5 could not see the 1050 at all. It was able to see both the SDRIVE-MAX and the SIO2SD connected through the hub and read/write between them. With previous firmwares, the SD-MAX and SIO2SD were unable to communicate at all and the SIO2SD was completely non-functional when the SDRIVE-MAX was attached to the hub. . Edited November 29, 2018 by SS Quote Link to comment Share on other sites More sharing options...
Fred_M Posted November 29, 2018 Share Posted November 29, 2018 That is similar to my findings with my XF551. I am happy to see that you (sorry! ) have the same results. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted November 30, 2018 Share Posted November 30, 2018 I did a few more tests with my 1088XEL tonight using the SDrive-MAX firmware I compiled and posted Tuesday evening. Tonight I had my Happy 1050 set as D1:, my stock 1050 set as D2: (but powered on tonight), and the SDrive-MAX plugged in with an ATR mounted as D3:. With disks in both physical drives, I was able to format D1: (I didn’t test formatting D2:), and copy files to and from each drive to each of the others. Then to throw a monkey wrench into the works, I booted up Jon’s amazing SIDEloader on my 1088XEL and mounted an ATR image as D4: and rebooted. I was now able to copy files to and from from the floppy drives to the SIDEloader-mounted D4:, copy files to and from D4: to the ATR loaded in the SDrive-MAX’s D3: slot, and copy files to and from D3: and D4: to either floppy. Feeling confident now (read, “an excess of hubris”) I then inserted my P:R:Connection into the mix. I plugged it into the second port on D2:, then plugged the SDrive-MAX into the pass-through port. Suddenly I ran into problems. As soon as I did that, I started getting errors accessing the SDrive-MAX. At this point I called my tests good for tonight. I’ll test some more tomorrow or Saturday. I’ve been running the SDrive-MAX powered off the SIO bus and it just might be too much current draw with both bus-powered devices attached at once. I’ll open up the SDrive-MAX, disconnect SIO power and dig up my Arduino plug-in PSU for any additional tests. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 30, 2018 Share Posted November 30, 2018 (edited) FWIW I can't use P:R: connection with SIO2SD and cassette (SIO powered grey).... but if I use the powered Cassette (brown and creme) or power the SIO2SD independent of SIO all is fine. To further test what you said, I swapped out power supply to the XE's... it worked with a beefier supply.. the machine used had a 5 volt wire run from the switch to the SIO port.. Sounds like power can indeed be and issue. So It's prudent to make sure all your power supply needs are met. I had always used the stronger supplies, I don't remember having swapped in a wimpy one. Sigh, go figure..... I hope I didn't keep this one and gave away my creme brick supply... edit - must be going senile... the better supply was behind an old tower (for kids that don't know that's a large computer, your laptop or pocket computer or phone probably runs circles around such a large behemoth, now get off my lawn!) I am both happy and sad. Happy I found it, sad I forgot why I did it in the first place. I think it was because I sent a better supply out with a computer and swapped my personal XE back in it's place and didn't give it a second thought. Crappy supplies belong in the I've got nothing left that's better use this in case of emergency box Edited November 30, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Level42 Posted November 30, 2018 Share Posted November 30, 2018 So no-one has yet have the same experience as I did ? As the picture I uploaded earlier shows Sdrive Max with 0.9 managed to erase my entire SD card..... I can understand all the other issues we’re experiencing but I’d figure the worst thing Sdrive Max could do is damage an image (which it did before with my Stuntdriver ATR) not the entire SD card.... Haven’t had time to work on it anymore yet.....maybe it just damaged the part of the SD that keeps the directory of its contents.....but even so, it should never be able to do this.... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 30, 2018 Share Posted November 30, 2018 No, never blanked an SD, but as quick as the fixes and updates have come, I've applied them... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.