Jump to content
Farb

SDrive-MAX ATX support

Recommended Posts

Hi,

 

I think you need to solder up the connection - I haven't checked the code, but A5 needs to be connected up to the SIO socket (COMMAND pin for A5), possibly there is a check on the value in the code, which may be undefined if it isn't connected (this is all guesswork though).

 

No, you don't. I flashed my device the first time without anything connected to the Arduino pins aside from the screen plugged into the headers.

Share this post


Link to post
Share on other sites

I took the hex files and put them in sdrive max main folder that contained the flasher etc....

I took the screen and attached it to the ardy..

 

I attached the usb cord to the ardy and the pc with nothing else

 

I made sure I had a proper usb driver

 

I ran the flasher... i gave the ardy time to finish it's flashing then I pulled the usb cord and waited a few moments,

then I plugged the usb cord back in and waited for the ardy to init

then I pressed a key for the second part of flashing to occur... I waited a couple moments for the that flash to finish on the device...

 

remember it takes a while for the programming to occur even though the PC will show it is done... it isn't... you must wait for the ardy to catch up and finalize each step.

 

then you must set up the micro sd card using the X86 (win linux whatever) and put it in the ardy..

 

 

You can plug the usb cord in and use the X86 to power the now programmed sdrive max and calibrate the screen.... then it's time to add the isolation chip and circuitry, etc...

then isolate power... add sio cord etc.... us external power not sio power.... party time!

  • Like 1

Share this post


Link to post
Share on other sites

Thanks,

I followed the suggestion that you need to flash first and solder later to avoid situation when you do not know if broken unit is due to wrong flashing or soldering

 

remember it takes a while for the programming to occur even though the PC will show it is done... it isn't... you must wait for the ardy to catch up and finalize each step.

 

I have waited few mins each time

I think I gave enough time for each step.

To me it looks like firmware does not recognize my screen.

 

Does anyone know how to contact with firmware author?

Does anyone know where in source code TFT definitions are?

Edited by MADRAFi

Share this post


Link to post
Share on other sites

I was not asking for sources, I know them have them downloaded.

I was asking for contact to author of the code or someone who could point me where is definition of LCD recognition

Maybe my screen is slightly different then regular hx8347g

Share this post


Link to post
Share on other sites

A couple of other people have reported problems with the hx8347g earlier in the thread. It does not sound like they were ever resolved.

Share this post


Link to post
Share on other sites

I was not asking for sources, I know them have them downloaded.

I was asking for contact to author of the code or someone who could point me where is definition of LCD recognition

Maybe my screen is slightly different then regular hx8347g

You can log an issue at the Github repository so the developer will have notice of your issue and the opportunity to offer suggestions if he has any.

 

Alternately, you can read through past posts in this very thread where there are links to the project developer’s personal page, which, if I recall correctly, had an email link to the author.

Share this post


Link to post
Share on other sites

I want to thank Klaus, author of the firmware for the support.

It turned out my screen has different pin layout and cannot be used.

Share this post


Link to post
Share on other sites

Heya. I just put this together and am having some kind of oddness happening to me and was looking for some help.

I have an Elegoo Uno R3 and the Elegoo TFT screen as well as having the SDrive on its own power supply via the barrel jack. When I power up the Atari the screen on the SDrive gets corrupted, but I can just tap the ready on the bottom and then close that window and it redraws the screen fine. However, I think because of this the Atari wont boot from the SDrive on power on. I can get the SDrive to work by typing "bye" and going to the diagnostic screen then pressing the reset button. From there, the Atari will boot from the SDrive and it functions as normal. The SDrive is the only connected SIO device and has the proper diode and there is no 5v connection from the SDrive to the SIO port. I've tried the V0.7 release, the 1.0b2 and 1.1b with the same issue.

Edited by KittyFae

Share this post


Link to post
Share on other sites

IIRC, I also must press RESET & Reboot. Mine is powered only by SIO, though. If yours has power on before boot then I believe you may have software corruption. That screen thing is very strange. Have you tried re-flashing it?

Share this post


Link to post
Share on other sites

IIRC, I also must press RESET & Reboot. Mine is powered only by SIO, though. If yours has power on before boot then I believe you may have software corruption. That screen thing is very strange. Have you tried re-flashing it?

It does have power before the 130XE is turned on. I've tried reflashing it and trying 3 different versions and the screen glitches out and wont cold boot the same way on all three. Does the same thing on the 800XL too.

Share this post


Link to post
Share on other sites

remember to allow each flash section to sit a bit and let the ardy catch up, then disconnect wait a moment reconnect, then let the second part flash... then let is catch up....catch up can take up to a minute... then all should be fine unless something is wrong with the ardy, or firmware choices

 

so double check all wiring... post some pictures... if we don't see it- it may be time to think something is defective..

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

How confident are you with your soldering? Is it possible you have a dodgy connection somewhere when you connected the SIO lines to the UNO? I guess it's also possible you have a bad ATmega chip on the Arduino.

Share this post


Link to post
Share on other sites

remember to allow each flash section to sit a bit and let the ardy catch up, then disconnect wait a moment reconnect, then let the second part flash... then let is catch up....catch up can take up to a minute... then all should be fine unless something is wrong with the ardy, or firmware choices

 

so double check all wiring... post some pictures... if we don't see it- it may be time to think something is defective..

I tried it again and let it sit for a while between flashes and still the same issue.

 

 

What chip is on your display?

ILI9341

 

 

How confident are you with your soldering? Is it possible you have a dodgy connection somewhere when you connected the SIO lines to the UNO? I guess it's also possible you have a bad ATmega chip on the Arduino.

Soldering is fine, beeped it out with a multimeter to make sure. I've done a ton of soldering prior to this project.

 

Could be a bad chip somewhere, but it just strikes me as odd that everything works after the bye/reset thing. I'll order another Uno and see what is up.

Share this post


Link to post
Share on other sites

Hi,

 

Have you tried just powering it from the 8-bit, e.g. unplugging the barrel connector.

 

Also you can use the Atari key to reboot the drive-loader, once you have selected the ATR images you want to use. There is a manual for the sdrive loader, I saw it posted here a few weeks earlier as a PDF.

 

Hope this helps!

Share this post


Link to post
Share on other sites

remember to allow each flash section to sit a bit and let the ardy catch up, then disconnect wait a moment reconnect, then let the second part flash... then let is catch up....catch up can take up to a minute... then all should be fine unless something is wrong with the ardy, or firmware choices

 

so double check all wiring... post some pictures... if we don't see it- it may be time to think something is defective..

Just to make sure _The Doctor_'s comment is clear: be sure you flash eeprom_writer.hex BEFORE you flash SDrive.hex. If you don't do this, strange behavior with occur.

  • Like 2

Share this post


Link to post
Share on other sites

Just to make sure _The Doctor_'s comment is clear: be sure you flash eeprom_writer.hex BEFORE you flash SDrive.hex. If you don't do this, strange behavior with occur.

I've made sure to do them in the correct order and waited a minute or two after each step of the eeprom_writer.hex, the reset, and the final sdrive.hex flashes.

Share this post


Link to post
Share on other sites

I've made sure to do them in the correct order and waited a minute or two after each step of the eeprom_writer.hex, the reset, and the final sdrive.hex flashes.

Are you using USB or the 6 pin header on the board to program them? The reason I ask is that I tried to program mine with the six pin header and a USBasp. It **seems** to work, and the SDrive will boot, but I get funky behavior. Programming via the USB port is fine. Also, I get mixed results via my Mac & OS X. I get reliable results via Parallels on that same Mac.

  • Like 1

Share this post


Link to post
Share on other sites

Are you using USB or the 6 pin header on the board to program them? The reason I ask is that I tried to program mine with the six pin header and a USBasp. It **seems** to work, and the SDrive will boot, but I get funky behavior. Programming via the USB port is fine. Also, I get mixed results via my Mac & OS X. I get reliable results via Parallels on that same Mac.

I am using USB and Windows / avrdude to program it

  • Like 1

Share this post


Link to post
Share on other sites

I am using USB and Windows / avrdude to program it

That's what I use.

Share this post


Link to post
Share on other sites

Got in a different Arduino Uno R3 today and everything works now. Seems the first one was faulty. Thanks for all the tips, suggestions and help!

  • Like 3

Share this post


Link to post
Share on other sites

FWIW: I just programmed one tonight with XLoader for Windows. Almost a pleasant experience! I ran the MCUFriend code to ID the chip and it came up ILI9341 *BUT* the text was reversed. When the X in the corners came up to calibrate the screen, the touch screen and program hung. Ended up switching to the 9329 versions and everything worked fine.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...