+MacRorie Posted October 25, 2018 Share Posted October 25, 2018 Sorry to start a new thread, but this doesn't seem to fit on the other SDrive threads. I have built a couple of SDrives. If I apply power, they seem to work (0.9 firmware): Screens look correct, I can plug them into an A8 (XEGS) and they start to boot, but then hang. I think the crux of the issue is that at startup, the SDrive cannot seem to find SDRIVE.ATR even though it is on the uSD AND, if I try to load it in D1: the SDrive sees it and will put it at D1. Any thoughts? Thanks for your time on this. Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 25, 2018 Share Posted October 25, 2018 Did you make sure the eeprom file was written first? Or, at least just do it again and then put the sdrive.hex on it. The symptoms you indicate are typically caused by bad eeprom data. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 25, 2018 Share Posted October 25, 2018 (edited) do you have d1: empty and D0: loaded and selected with the SDrive.ATR remember you have to wait a bit between writing for the uno to catch up during flash.... if you don't it will corrupt depending on uno, the unit might not co-operate with any other devices on the sio chain.. If sdrive.atr is on microsd card in proper fat and place the sdrive will show no error in ready screen. If D0: is not blue and you want it to be selected at all times then tap config and set then save... Edited October 25, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted October 25, 2018 Share Posted October 25, 2018 (edited) As far as I remember correctly, you have to flash the eeprom file first, Reboot the Sdrive-max!!! And then flash the other file. If you flash both files without rebooting it won't work. ( unplug the USB to power off n' on) Stefan Edited October 25, 2018 by Stefan Both Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 25, 2018 Share Posted October 25, 2018 correct but you must wait a decent period of time between and after for the flashing to actually complete. Bars will appear on screen to show progress only with a screen that is set up with the uno already. You might just have a black screen until it's all been done at least once. Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted October 25, 2018 Share Posted October 25, 2018 Ah, right... I forgot that Stefan Quote Link to comment Share on other sites More sharing options...
+MacRorie Posted October 25, 2018 Author Share Posted October 25, 2018 do you have d1: empty and D0: loaded and selected with the SDrive.ATR remember you have to wait a bit between writing for the uno to catch up during flash.... if you don't it will corrupt depending on uno, the unit might not co-operate with any other devices on the sio chain.. If sdrive.atr is on microsd card in proper fat and place the sdrive will show no error in ready screen. If D0: is not blue and you want it to be selected at all times then tap config and set then save... Well, as I mentioned in the first post, D0: cannot find SDRIVE.ATR even though it is on the the card. Also, if I try to load D1:, it can see SDRIVE.ATR, but that is not where it goes, so kind of pointless. Also, this problem surfaces before even connecting it to the Atari. Quote Link to comment Share on other sites More sharing options...
+MacRorie Posted October 25, 2018 Author Share Posted October 25, 2018 Did you make sure the eeprom file was written first? Or, at least just do it again and then put the sdrive.hex on it. The symptoms you indicate are typically caused by bad eeprom data. I did, but just in case, I did it all over again. I connect it to my USBasp and the ICSP header on the Arduino. I flash the eeprom-writer file. I disconnect. Attach USB cable for power. Watch "Writing eeprom . . ." and then "Verifying eeprom . . ." and then "Done" I disconnect. Reconnect USBasp. Flash Sdrive.hex. Reboot. Set touch screen parameters. Troubleshoot window reports "SDRIVE.ATR not found" I then try another Arduino, I try another uSD card. I try freebasing, but decide that's a bad idea. I come here and type this message. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 25, 2018 Share Posted October 25, 2018 reformat the microsd card I think as fat 32 then make sure sdrive.atr is in root all lower case... all parts must match both firmwares and the .atr Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 25, 2018 Share Posted October 25, 2018 (edited) no, don't go by what you see on pc screen go by what you see on uno screen! the pc reports all done before the uno catches up. the uno buffers it and verifies it to the pc.... but it is still flashing.. Edited October 25, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
lemiel Posted October 26, 2018 Share Posted October 26, 2018 How long uno catches it? Quote Link to comment Share on other sites More sharing options...
Level42 Posted October 26, 2018 Share Posted October 26, 2018 I added a 10 second pause in my OSX flashing script which seems just about right with a second or two tolerance, Quote Link to comment Share on other sites More sharing options...
Gavin1968 Posted October 26, 2018 Share Posted October 26, 2018 Sorry to start a new thread, but this doesn't seem to fit on the other SDrive threads. I have built a couple of SDrives. If I apply power, they seem to work (0.9 firmware): Screens look correct, I can plug them into an A8 (XEGS) and they start to boot, but then hang. I think the crux of the issue is that at startup, the SDrive cannot seem to find SDRIVE.ATR even though it is on the uSD AND, if I try to load it in D1: the SDrive sees it and will put it at D1. Any thoughts? Thanks for your time on this. The problem with powering them directly from the A800 is that they do not get powered up in time to book the machine. If you connected them to an 850 or a floppy drive and they were able to get power from them before the A800 boots then it will work. Quote Link to comment Share on other sites More sharing options...
+MacRorie Posted October 26, 2018 Author Share Posted October 26, 2018 The problem with powering them directly from the A800 is that they do not get powered up in time to book the machine. If you connected them to an 850 or a floppy drive and they were able to get power from them before the A800 boots then it will work. That is an interesting situation, I would think this would render it unusable in most situations it would be found (i.e., replacing floppies). However, I would think that if you reboot the UNO after powering on the A8, it should render that possibility moot. In this case, doing so does not solve the problem. :-( Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted October 26, 2018 Share Posted October 26, 2018 That is an interesting situation, I would think this would render it unusable in most situations it would be found (i.e., replacing floppies). I suppose it depends exactly on what one would be doing, but for the stock systems I've tested the SIO powered MAXs on I simply power on the A8 holding down Start. Then select whatever's wanted on the MAX and just Option/Reset the A8. You can also save mounted images/slots on the MAX. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 27, 2018 Share Posted October 27, 2018 (edited) if you end up at the basic prompt, just type B. or BYE then hold option and press reset.. for menu.. although if coded properly the menu could shut off basic all by itself... if you hold option already then you just keep holding it and press reset... I power mine separately... and diode protect the sio power line... Edited October 27, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
+MacRorie Posted November 1, 2018 Author Share Posted November 1, 2018 Sooo, apparently there is a LOT of difference when you flash via USB and via the ISCP. IN fact, the difference is so substantial that the new boot loader prevents you form re-flashing it via USB! The only reason I was able to figure it put was I used a USB set up on a brand new, out of the package UNO. It flashed right away and loaded sdrive.atr without any complaint. So, I knew it was not the uSD card nor was it the UNO itself. So, I thought, maybe it was the hex files I was using. Nope, tried some fresh from a known good source and they failed as well via the ISCP. So, I tried another blank via USB. No problem. Tried to erase the chip on an "old" one via USB. Nope. avrdude errored out trying to start. I eventually had to dig up the factory bootloader+an EEPROM blanker, compile it to hex, and then burn THAT via ISCP and then flash the SDrive stuff via USB. Managed to get all of them working//seeing sdrive.atr. tl;dr: DO NOT flash via the ISCP port. If you do, I have a file for you :-) 5 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 1, 2018 Share Posted November 1, 2018 (edited) Sooo, apparently there is a LOT of difference when you flash via USB and via the ISCP. IN fact, the difference is so substantial that the new boot loader prevents you form re-flashing it via USB! The only reason I was able to figure it put was I used a USB set up on a brand new, out of the package UNO. It flashed right away and loaded sdrive.atr without any complaint. So, I knew it was not the uSD card nor was it the UNO itself. So, I thought, maybe it was the hex files I was using. Nope, tried some fresh from a known good source and they failed as well via the ISCP. So, I tried another blank via USB. No problem. Tried to erase the chip on an "old" one via USB. Nope. avrdude errored out trying to start. I eventually had to dig up the factory bootloader+an EEPROM blanker, compile it to hex, and then burn THAT via ISCP and then flash the SDrive stuff via USB. Managed to get all of them working//seeing sdrive.atr. tl;dr: DO NOT flash via the ISCP port. If you do, I have a file for you :-) If there's a way to find it, you and I will always make the snafu. Nice to see it sorted. I think you enjoy these puzzles! The problem will rear it's head again for someone out there. They will find this thread... they will want the factory boot loader + EEPROM blanker hex to burn via ISCP to their borked uno... might as well post it. Edited November 1, 2018 by _The Doctor__ 2 Quote Link to comment Share on other sites More sharing options...
gooner4life7 Posted July 8, 2019 Share Posted July 8, 2019 think this is what i have done as i used ISCP and now it will not flash. this what i get when i try avrdude -carduino -pm328p -P com3 -U flash:w:eeprom_writer.hex avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude done. Thank you. any help on how to fix this would be great. Quote Link to comment Share on other sites More sharing options...
NISMOPC Posted July 8, 2019 Share Posted July 8, 2019 BIG thanks to BigBen, I use this executable exclusively for flashing. No need to flash separate files, etc. Does it for you... ...just make sure you have the correct hex file in the main folder where the *.bat file is. As long as you are using Windows you choose your COM Port and this works perfectly. No issues. Just follow the directions as it tells you what to do. 1 Quote Link to comment Share on other sites More sharing options...
gooner4life7 Posted July 8, 2019 Share Posted July 8, 2019 just tryed that i get the same more or less. SDrive-Max programmer Please enter the COM port number of the Arduino Uno (only numbers) Press enter for help COM:3 Was chosen COM3 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x4e avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x4e avrdude done. Thank you. Remove the USB from the PC and plug it in again RESET at the UNO is not enough!!!!!! wait until the COM is active on the PC again then press the button Press any key to continue . . . not sure why Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted July 8, 2019 Share Posted July 8, 2019 Check the first link in my sig... 1 Quote Link to comment Share on other sites More sharing options...
NISMOPC Posted July 8, 2019 Share Posted July 8, 2019 17 minutes ago, gooner4life7 said: just tryed that i get the same more or less. SDrive-Max programmer Please enter the COM port number of the Arduino Uno (only numbers) Press enter for help COM:3 Was chosen COM3 not sure why Have you checked your device manager to confirm that COM3 is in fact being used? I have run into situations where I've used different USB ports on front of PC and it re-assigned the COM ports or COM3 was used for a previous SDrive I had connected, etc. That would be my first point of verification. 1 1 Quote Link to comment Share on other sites More sharing options...
gooner4life7 Posted July 8, 2019 Share Posted July 8, 2019 (edited) 19 minutes ago, Mr Robot said: Check the first link in my sig... hi there i flashed it with ISCP it boot up but i get sdrive.atr not found so i looked on google with this problem and i found and tried your guide but for some reason it will not flash at all now. any help how to reset the uno would be great Edited July 8, 2019 by gooner4life7 Quote Link to comment Share on other sites More sharing options...
gooner4life7 Posted July 8, 2019 Share Posted July 8, 2019 5 minutes ago, NISMOPC said: Have you checked your device manager to confirm that COM3 is in fact being used? I have run into situations where I've used different USB ports on front of PC and it re-assigned the COM ports or COM3 was used for a previous SDrive I had connected, etc. That would be my first point of verification. just checked again now. and yes its showing as com3 ?? 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.