SDrive-MAX ATX support

[flashjazzcat]

Just now, DrVenkman said:

Someone like @phaeron or @HiassofT who know SIO protocols inside out and upside down...

Small correction.

 

[+DrVenkman]

Okay, I just tested my SDrive-MAX in the following configuration:

 

Atari 1088XLD (*) --> Happy 1050 (D2:) --> Happy 1050 (D1:) --> P:R:Connection (**; the in-built SIO pigtail plugged into D1:) --> SDrvive-MAX (ATRs loaded into D3: and D4:, D1: and D2: slots left empty and disabled).

 

(* the XLD, being based on the 1050 drive board, has two SIO ports wired in parallel; however for this test I used only one, so that everything stretches out in one long chain as it would on a vintage Atari computer).

(**The P:R:Connection also as an Atari Terminal Cable connected to R1: running to a Lantronix MSS100 but that's irrelevant to the test).

 

After booting into SpartaDOS X, I was able to access all four drives (two real and two virtual) without issue. 

 

Things I tested:

• Directory reading across all four drives
• Formatted the ATR in D4: on the SDrive-MAX
• Copied a ~6K .COM program from the physical floppy in D2: to the ATR in D4:
• Copied that same .COM program from D4: to the physical floppy in D1:

My particular SDrive-MAX was built on a typical generic "gooduino" from @Mr Robot's excellent guide. It uses SMD components and Atmega chip, and is fitted with one of Steve's SIO isolation boards. I assembled this unit myself using a vintage SIO cable, the SIO isolation board was purchased pre-built though I installed it into my existing SDrive-MAX a couple weeks back. My board is powered by an external Arduino UNO 9V PSU that plugs into the power jack on the board.

 

So bottom line is I have no problems with the P:R:Connection on my SIO chain, even with the SDrive-MAX plugged into the end, and thus furthest along the chain.

[NISMOPC]

19 minutes ago, DrVenkman said:

So bottom line is I have no problems with the P:R:Connection on my SIO chain, even with the SDrive-MAX plugged into the end, and thus furthest along the chain.

Leads me to believe there might be an issue with the P:R:Connection itself OR since these R3 boards are mass produced, a bad SMD component and Atmega chip board. Which is very reasonable to assume. Cheap eBay purchase.

 

As for the socketed DIP chip board, I checked and re-soldered all solder joints, checked the connection to SIO connector (authentic SIO cut in half) with multi-meter and all connections appear to be good and passing thru. This leads me to believe THIS board got shorted when the RX connection came loose. I will replace this board and pray that it fixes the issue. This was the board that I had no issues with until that RX cable came loose while moving it around (w/o case).

 

Thanks for all your input and testing DrVenkman! Gives me some direction and actions to take.

[+DrVenkman]

I hope you don't have an issue with the Arduino but stuff happens, I know. 

 

And I don't mean to add salt to any wounds, but after the above post, I realized I didn't actually test the PRC as such. So from the SDX command line I loaded PRC.SYS (the R: handler), then fired up ICE-T and confirmed I can talk to it via the Atari, then quit back to SDX and confirmed I can still access all the drives (physical and virtual on the SDrive-MAX). So in my experience everything *should* work correctly. 

Of course, in an ideal world we'd all have flying cars by now and be vacationing on the Moon but here we are.  

[phaeron]

SIO Command must go low prior to the start of the command frame and then high after the end of last byte of the command frame, when the computer is ready to receive the ACK. If it goes high before the end of the last byte, some devices will reject the command frame (particularly the XF551).

 

Serial framing errors occur when the UART/USART sees a valid start bit and begins shifting in a byte, but the stop bit is invalid. This refers to the framing on each byte and not the SIO command/data frame. Framing errors can happen due to transmission errors, baud rate mismatches, and reception beginning in the middle of a byte being sent.

 

What adds to the confusion is that any timing or transmission errors that derail the SIO command protocol can get either the computer or the device desynced, typically the device getting left hanging and then interpreting the start of the next command as part of the last. This causes the device to try to receive and transmit at the wrong times, leading to some error ping-pong between the computer and the device. The OS will retry commands up to 13 times, which is usually enough to get everything back on track, but in the meantime the overlapped commands will give all sorts of serial errors that can be confusing for diagnosis.

 

For a PC-based device like RespeQt, the most likely culprit would be a timing issue, since USB serial ports generally suck at that. But for an embedded device like an SDrive, I'd be more inclined to suspect transmission errors.

 

[_The Doctor__]

without having the stuff in our hands to look at, in order for the super helpful folks on atariage to gain insight, watching the sio stream using APE or respeqt using a sio2whatever device and sending screen shots of the info area showing the stream during operation and error could give some indication or what's going on and be slightly more helpful

Edited July 7, 2019 by _The Doctor__

[Kyle22]

Possibly helpful, but not as much as a multiple trace scope or logic analyzer.

[_The Doctor__]

I gots my logic analyzer right here!

[Gavin1968]

On 6/16/2019 at 6:49 AM, Mclaneinc said:

Maybe somebody in the UK will do them at some point,

I ship world wide by the way, and I hear you about the eyes, I have a rather large magnifying glass I use when I build them myself. 

[Mclaneinc]

Hi Gavin,

 

I think someone said you ship anywhere but it was the cost of shipping and then the import duty that put me off, all word of your stuff was excellent, it simply was the last bit where I get hammered every time...Even today I got a 14.92UK bill for duty over my daughters cardigan she purchased (yeah I get to pay it   ) from the US.

 

As for the eyes, yeah...I have a USB microscope and a big magnifier also for when I bother to build.

 

Paul..

[+mytek]

I've shipped to England several times and only had the recipient hit by customs once. The secret I found out was to not use my company name anywhere, but instead make it personal with my own name on the address label and USPS customs form. I also wrote down a simply declaration, simple calling it vintage computer parts no matter what was inside. I think the minute UK customs sees something that indicates the shipment is from a company, they jump all over it.

 

[darwinmac]

For current Sdrive Max users, I have some questions regarding ATX support. I tried looking through the entire thread trying to find out the extent of ATX support, but I got lost in the 35 page thread.

 

1. Is there any idea of the types of ATX copy protection types that are supported?

2. Does it make any difference in ATX support if SIO power or external power is used?

3. Do you have 3-4 ATX titles that you know work on Sdrive Max so I can make sure there is nothing wrong with my unit.

 

It appears I'm running firmware version 1.1 and I am using SIO power since the external power cord doesn't reach my surge protector where the 8-bit equipment is plugged into. I use the Sdrive boot program to select what gets loaded into D1 since I don't have power until my XEGS is turned on. Unless it becomes necessary, I don't want to get into where I purchased the Sdrive Max because I don't want to start the pricing discussion again.

 

I ask these questions because, in my limited use, I haven't had a lot of luck getting ATX files to load correctly using Sdrive Max. I may have simply been unlucky.

 

So far, I've tried ATX files for: Micro League Baseball, Lords of Conquest, and BC's Quest for Tires. All three of the ATX files came from Farb's 8-bit preservation project. Someone had a large ZIP file loaded onto their website where it could be downloaded. All of the ATX files work successfully in my emulator of choice (Atari800MacX) so I'm confident the ATX files aren't corrupted.

 

These have been my observations:

BC's Quest for Tires: Even though I hold down the Option key after tapping the Inverse key to start a reset of the XEGS, I get a "READY" prompt which tells me BASIC was loaded. I get the same prompt even if I don't hold down the Option key.

 

Lords of Conquest: I get a "Remove Cartridge" error even though no cartridges are loaded into my XEGS

 

Micro League Baseball: I get the same "Remove Cartridge" error even though no cartridges are loaded

 

The only ATX files I have been able to load are Micro League Baseball data disks. Even though the disks are in ATX format, I doubt those disks are copy protected.

 

Thanks for your help.

 

Bob C

[toddtmw]

I’ve not used an XEGS. Are you holding option when you are originally booting?

[Mr Robot]

You are booting with basic enabled and then pressing Inverse to reboot. You can’t disable basic like that. 

 

Press shift+ctrl+Inverse to cold reset and disable basic. 

[+DrVenkman]

What the other guys said.

As for some sample ATX files from Farb’s collection, I’ve personally successfully tested ARCHON, MULE, SEVEN CITIES OF GOLD, SPY VS. SPY, THE GOONIES, GHOSTBUSTERS, BRUCE LEE and who knows how many others in just the last week or three. 

[darwinmac]

1 hour ago, toddtmw said:

I’ve not used an XEGS. Are you holding option when you are originally booting?

I’ve tried both with no difference. None of the three mentioned ATX titles will work with the SDM. 

 

With my old SIO2SD device, I’d hold down the X key from the SIO2SD boot program, let go of the X key, and hold down the Option key. That would disable BASIC when using that device. I haven't figured out how to do the same thing with the SDM device. Now, as I think of it, the "Remove Cartridge" refers to BASIC being loaded. I should've thought of that, but I was simply looking for a cartridge that I didn't have loaded in the XEGS.

 

42 minutes ago, Mr Robot said:

You are booting with basic enabled and then pressing Ctrl+inverse to reboot. You can’t disable basic like that. 

 

 Press shift+ctrl+Inverse to cold reset and disable basic.

Actually, I was using just Inverse to reboot the SDM. I would then hold down Option to try to disable BASIC. I’ve tried using shift+ctrl+inverse to cold boot. I wasn’t sure if that disabled BASIC as well as doing a cold boot so I tried both holding down and not holding down Option. Neither method had any effect. I still have the same behavior with these ATX files as I had previously. 

 

Bob C

Edited July 9, 2019 by darwinmac
Clarity

[NISMOPC]

Finally got this bloody thing figured out. This is regarding my socketed DIP chip board issues. Still have SIO conflict with the SMD chip board/sub-board and the P:R:CONNECTION only, but...

 

Tried to remember how my SD-Max socketed DIP chip board was set-up before all of this went down hill. Initially thought when the TX connection came lose it shorted the board out, but then I kept thinking it was the RX connection that I changed. Then it came to me. I originally did NOT bend the chip pin#2 up and connect the SIO #5 wire to that pin. I connected the on board RX directly to pin #5 of the SIO.

 

So, I removed the wire and solder, removed the chip, gently bent the #2 pin back down, re-inserted chip and soldered #5 SIO wire to RX connection on board.

 

IT WORKS! NO ISSUES! NONE! Even logged on to The Basement BBS to test out my WiModem232 with P:R:CONNECTION.

 

                                                                                                 SDrive-Max (SIO) w/5V USB power

130XE => 1050 (D1) => 1050 (D2) => P:R:CONNECTION (SIO) <

                                                                                                 WiModem232 (R1) w/5V USB power

 

When I shut down the 130XE, the SDrive-Max now shows the proper "SIO:CMD Timeout" and I have full operation of the unit.

 

Pics...

 

Edited July 9, 2019 by NISMOPC
Corrections

[darwinmac]

I found the solution to my problem. I was used to being able to delay slightly (maybe .5 - 1 second) before holding down the Option key when doing a cold boot from SIO2SD and still have BASIC disabled. That doesn't seem to be the case with Sdrive Max. I was thrown off by the lack of a timing delay.

 

I have to hold down the Option key prior to pressing Shift-ctrl-Inverse to make sure the Option key is detected on the reboot. That makes an interesting 4 finger "salute" on the XEGS. However, when I do this, BASIC is disabled and the ATX files work as anticipated. It isn't necessary to hold down Option prior to starting the Sdrive boot program.

 

I haven't tried a warm boot (only Inverse) while holding the Option key to see if that would work as well.

 

In any case, my problem is now solved and I thank all of you for your assistance.

 

Bob C

[Mr Robot]

9 hours ago, NISMOPC said:

Finally got this bloody thing figured out. This is regarding my socketed DIP chip board issues. Still have SIO conflict with the SMD chip board/sub-board and the P:R:CONNECTION only, but...

 

...

 

So, I removed the wire and solder, removed the chip, gently bent the #2 pin back down, re-inserted chip and soldered #5 SIO wire to RX connection on board.

 

Well done getting it working! Is it time to go back to the SMD one and very carefully check all the connections?

[Mr Robot]

6 hours ago, darwinmac said:

That makes an interesting 4 finger "salute" on the XEGS.

If you have a U1MB installed with FJC's BIOS you can also press Select+Reset for a cold boot

[NISMOPC]

1 hour ago, Mr Robot said:

Well done getting it working! Is it time to go back to the SMD one and very carefully check all the connections?

It all depends. I generally go all out when I get in the mood in resolving an issue that I know shouldn't be there. I end up eating, drinking and sleeping with the issue until it's resolved. Going to take a mental break from this now that the one I wanted to work is working properly. Then I'll attack the SMD version at some point.

Edited July 9, 2019 by NISMOPC

[NISMOPC]

Out of curiosity, how difficult is it to add more screens (drivers) to the compatibility list for the SDrive-Max?

 

I have a brand new Himax HX8347-D TFT ID:4747 TFT screen in my parts bins and was able to get the atmega328-hx8347g hex files to load , but the touch is not responding. So I just wondered if this is something that can be easily done. Give me reason to build another SD-M

 

It appears to be a 2.8" screen and has the Palm Pilot style lower section with icons that reference [home] [mail] [docs] [phone] [music].

[hawk]

Hey NISMOPC,

I am in the same situation.  I have purchased a cheap 2.8" screen that has TFT ID:4747 that I figure is also a HX8347-D.

 

When I loaded the HX8347-G firmware, the display was correct, but the touch screen didn't work.

 

When I loaded the HX8347-I firmware, the touchscreen worked, but the display was mirrored horizontally.

 

These results led me to believe that it was possible to get this display working, so I built my own firmware version for HX8347-D, choosing the -I display options and the -G touchscreen options.  I didn't work.  It functioned the same as the -G version.

 

I can't find the options for the display that differ between the -I and -G versions.

 

Any help would be appreciated.

Hawk

[+DrVenkman]

On 7/13/2019 at 7:11 AM, hawk said:

Hey NISMOPC,

I am in the same situation.  I have purchased a cheap 2.8" screen that has TFT ID:4747 that I figure is also a HX8347-D.

 

When I loaded the HX8347-G firmware, the display was correct, but the touch screen didn't work.

 

When I loaded the HX8347-I firmware, the touchscreen worked, but the display was mirrored horizontally.

 

These results led me to believe that it was possible to get this display working, so I built my own firmware version for HX8347-D, choosing the -I display options and the -G touchscreen options.  I didn't work.  It functioned the same as the -G version.

 

I can't find the options for the display that differ between the -I and -G versions.

 

Any help would be appreciated.

Hawk

I got a Github email this morning that there’s now a 1.21b beta firmware build.  The one entry in the release notes states:

 

”Testing Firmware for HX8347D, a combination of HX8347G(screen) and HX8347I(touch)”

 

 

[NISMOPC]

3 hours ago, DrVenkman said:

I got a Github email this morning that there’s now a 1.21b beta firmware build.  The one entry in the release notes states:

 

”Testing Firmware for HX8347D, a combination of HX8347G(screen) and HX8347I(touch)”

 

 

Great news! I might have to give it a test run for my extra TFT screen and R3 board.