sdrive SDrive-Simple - Yet Another Hardware Variation

[+mytek]

21 minutes ago, kbr said:

The timing differences on scope between sdrive-max(black) and sdrive-ng(grey) are marginal, captured with pokey-div 5.

Channel 1 is the command frame from atari, the small spike on channel 2 is the ACK from device, followed by COMPLETE, data and checksum.

I still haven't had a chance to wire up my prototype to an 800XL to see what it does. But the problem only seemed to exist at Divisor 0 and 1 during my tests with the 576NUC+. At Divisor 5 (the one you captured the scope trace at) works flawlessly on my set-up, which makes sense seeing that the timing differences are relatively small.

 

Whats your comparison look like at Divisor 0 ?

[+mytek]

OK I had a bit of spare time today, so I wired up the prototype SDrive-ng board to a stock 800XL that only had the SIO capacitors removed. It worked all the way down to Divisor 0 no problem. This is the same prototype I had connected to the 576NUC+ last month that couldn't do Divisor 0 or 1.

 

Next I once again tested the 576NUC+ with one of my assembled NUCplus4 boards, and sure enough it wouldn't work at Divisor 0 or 1 either. And I was using the same ATMEGA chip pulled from my prototype.

 

Next I swapped out the NUCplus4 daughter board for an SDrive-Max version (sans LCD). It worked down to Divisor 0 no problem. So definitely something a bit different timing-wise on the 576NUC+. Although I guess it could be something odd with the Pokey chip. I'll check this out tomorrow and swap the Pokey from the 800XL into the 576NUC+.

 

@kbr I was also thinking that if it is a timing issue specific to the NUC, that perhaps the SDrive-ng firmware could be made to match better with the SDrive-Max and I could give that a try as well. Because there probably isn't an easy way to alter the 576NUC+ timing chain without major surgery (my main clock circuit is rather unique, and there are other downstream changes as well).

 

Here's the NUCplus4 SDrive schematic for reference:  NUCplus4-SDrive_schema.pdf

And the 576NUC+ Project schematic also for reference:  576nuc_project_schema.pdf

[kbr]

I can't believe any more, that this little difference of about 1ms is the problem, it is already within the specs.

An other aspect is the signal quality, maybe some bits can not be captured correctly. I got often checksum errors if the bit rate is to high, and the same hangs as you provided on my unmoded machine. It works stable up to pokeydiv 5, copymate can do up to 3, but i think they are ignoring checksum errors...

 

[+mytek]

6 hours ago, kbr said:

I can't believe any more, that this little difference of about 1ms is the problem, it is already within the specs.

An other aspect is the signal quality, maybe some bits can not be captured correctly. I got often checksum errors if the bit rate is to high, and the same hangs as you provided on my unmoded machine. It works stable up to pokeydiv 5, copymate can do up to 3, but i think they are ignoring checksum errors...

 

I don't know how often communication errors occur when operating at Divisor 0 or 1 with the SDrive-Max vs. the SDrive-ng, but at least on my 576NUC+ the ng version pretty much locks up every time right from the get go, whereas the Max doesn't. However I do recall instances where the Max needed to be dialed back for certain files to fully load, so obviously it's timing wasn't perfect either. And thus far the ng if kept to Divisor 2 and above works very well in my early tests. Of course I still need to run through more example files to see how reliable it really is at Divisor 2.

 

So yesterday I swapped the Pokey out of the 800XL that worked fine all the way to Divisor 0 into my 576NUC+. There was no change, Divisor 0 and 1 were still a no go.

 

My plan today is to run some experiments with the primary crystal oscillator on the NUC, one of which will be to substitute a 3.58Mhz packaged and calibrated crystal oscillator in a can which should certainly rule out any issues with the main clock frequency being off. Since every thing else on the NUC works well, I doubt this is an issue, but I'd like to rule it out none-the-less.

 

You mentioned signal quality as a possibility, I'll be keeping that in mind as I play around with the NUC, and breakout the scope to take some comparative readings.

 

Note: Although being able to run the SIO at the highest speed is always nice, from a practical point of view most people that demand absolute reliability in file saving and loading would normally compromise at Divisor 6.  I believe this is the default out of the box for both SDrive and FujiNet when accessing SD cards.

[+mytek]

@kbr your comment about signal quality got me thinking, and made me recall that I had made a change in the location of the SIO 4.7K pull-ups vs. the 100 ohm series resistors.

 

576NUC+ SIO

 

800XL SIO

 

 

Notice on the 576NUC+ the pull-ups are directly on the SIO Jack side, whereas on the 800XL they're after the series 100 ohm resistors instead. At the time this was done to facilitate a much easier trace path on the very crowded motherboard of the 576NUC+. It didn't seem like a big deal at the time, nor had I seen any problems with accessing SIO devices using this scheme (FujiNet, SDrive-Max, SIO2PC, ect.), so that's the way it got implemented. However that change might be playing into what's happening with the SDrive-ng.

 

EDIT: Atari's way creates a resistor voltage divider which would drop the incoming voltage by 0.1V which doesn't seem significant, whereas my circuit would not impose any voltage drop. I would think that both methods would suffice equally well on the pull-up aspect, but perhaps the 100 ohm series resistor feeding into the Pokey (and PIA) does something a bit different with the pull-ups on the one side vs. the other. Enough so that it creates the issue I'm seeing with the SDrive-ng.

[kbr]

An other thing is, the arduino board has 10K resistors between the serial pins and it's serial2usb converter. Or do you have the level fix with a 7407 installed?

(this should give a better signal quality)

 

EDIT: The diode at the DATA-IN line may also give negative effects, this is not the best solution, instead of an open collector...

Edited October 29, 2023 by kbr

[+mytek]

16 minutes ago, kbr said:

An other thing is, the arduino board has 10K resistors between the serial pins and it's serial2usb converter. Or do you have the level fix with a 7407 installed?

(this should give a better signal quality)

Presently just using the resistor divider scheme for level shifting - will try 7407. However this doesn't explain why it works in one scenario and not the other (could be on the edge, tipping one way or the other).

 

20 minutes ago, kbr said:

The diode at the DATA-IN line may also give negative effects, this is not the best solution, instead of an open collector...

I could also try 7407 here as well, but per my comment above i doubt that'll fix the issue I'm seeing.

 

Thanks for the suggestions

[+mytek]

I temporarily connected without the diode, which is fine since I would be testing only the SDrive-ng all by itself without anything else attached to the SIO bus. And then I tried using 74LS07 buffers powered by 5V but used 10K pull-ups on the outputs connected to 3.3V. With the buffers it acted like the SD Card had nothing usable on it and displayed the message to hit return for a memory dump (very odd). I put the resistor dividers back in and it all worked once again.

 

Next I tried swapping the PIA and the CPU from the 800XL, no dice still won't handle Divisor 0 and 1. Tried adding 22pf caps from each side of the 576NUC+ clock crystal to GND and same result (haven't tried replacing the entire oscillator circuit with a canned one yet). I really don't think I'll get this to work for those two faster SIO speeds, but I'm OK with that.

[kbr]

Strange!

 

But sorry, i meant this level fix in the SIO lines:

Would be only necessary at the DATA-IN line.

Edited October 30, 2023 by kbr

[+mytek]

18 hours ago, kbr said:

Would be only necessary at the DATA-IN line.

I bypassed the diode yesterday, and today I inserted a 74LS07 gate in the path. Nothing changed. Basically the SDrive-Simple which was based on the SDrive-Max and had the diode in the Data-In line. It works at full speed, so I wasn't really expecting any change today.

 

Whatever differentiates the 576NUC+ from a standard 800XL is a mystery to me, but whatever it is the SDrive-ng doesn't like it when going to higher speeds. Doesn't seem to affect the max or SIO2PC-USB, both of which can go all the way down to Divisor zero.

 

EDIT...

Here's all of what I've tried to date, and my observations.

• Established that identical SDrive-ng hardware works from Divisor 0-9 on 800XL, while only from 2-9 on 576NUC+
• Swapping the following parts: Pokey, PIA, and Sally from the same 800XL to the 576NUC+ doesn't change this pattern
• On the SIO Data-In line using a direct connection, a diode, or a buffer from a 74LS07 makes no difference
• On the 576NUC+ adding 22pf capacitors from each crystal lead of the primary clock to ground makes no difference (crystal clock circuit is different)
• Using the SDrive-Simple (based on the Max), or an actual externally connected SDrive-Max, or a FujiNet (either from the SD or a TNFS server), or SIO2PC-USB all on the 576NUC+ works with Divisor 0-9
• The placement of the 4.7K pull-up resistors vs. the 100 ohm series resistors on the SIO jack is reversed on the 576NUC+ vs. any other Atari

 

[+mytek]

Looking at the SDrive-ng vs. the SDrive-Max (or SDrive-Simple, sans touch screen LCD), the Max worked the same as on any other system (Divisor 0-9 was possible). However without the touch screen display the biggest and most desired omission was the inability to Swap disks (also called disk rotate). Originally when approaching the new 4-in-One NUCplus4 daughter board project, I wanted to not only add back in the missing Swap feature, but also provide for hot-plugging of the SD Card in a way that an inserted disk would give a visual (LED) indication of insertion, as well as reinitialize with the new SD Card same as if changing a floppy on an Atari disk drive. It also needed to completely take the SDrive out of circuit if there was no SD Card present. The SDrive-ng basis made all this a reality, as well as adding selectable Disk ID, so that if used with another drive (e.g., floppy), it could be re-designated as Disk 1-4.

 

So to add disk swap to SDrive-Max via a physical switch, would have required reprogramming of the firmware and a separate fork in the development path. The SDrive-ng eliminated this by already bringing the Swap feature in it's firmware via a push button switch. It also supported high capacity SD Cards same as the Max. And since the hot-plugging and card insertion indication was done by add-on hardware, this could just as easily have been added to the Max version. However the selectable Drive ID was also tied to the touch screen display of the Max, hence not available for dipswitch selection.

 

Why not just include FujiNet and use it's SD Card aspect?  Well from an ease of use viewpoint especially when no WiFi is present, and also due to the method employed for the disk assignment aspect, the SDrive-ng and SDrive-Max are just a bit faster to use when only the SD drive is desired. Also on the 576NUC+ by leveraging the TK-II PS/2 keyboard, expanded disk menu navigation is available. However there will be a very small plug-in WiFi only version of the FujiNet so that all of it's other very cool wireless features can be used (e.g., remote access of TNFS servers and virtual printer support). Of course we lose cassette support, but I won't miss that anymore than I did back in the late 80's when I could finally afford to buy a floppy drive and then never looked back.

 

So getting back to the mysterious inability of the SDrive-ng at handling Divisor 0 and 1 only on the 576NUC+ system, I'll have to admit I'm flummoxed as to the reason. Will this in itself change my design direction?  No because those Divisors are not 100% compatible with all of the disk files in the wild on any of the alternative drives either, and I sometimes find myself having to back off for certain files to reliably load. And finally I'm building this new system first and foremost for my personal use and entertainment, although most likely the schematics and gerbers will still get released to the public when I'm done.

[kbr]

Interesting aspects, but it doesn't leave me alone, what the reason for this effect is.

Btw. i have tested with the highsio patch from hias(software only), and it's amazing, i can go up to pokeydiv 2 on my unmodded machine .

So i am wondering any more, if you also use this patched OS...

 

EDIT: May be PAL or NTSC any possible reason? sdrive-ng has better baud matches for NTSC. SDrive-MAX matches better for PAL at pokeydiv 1.

At pokeydiv 0 it is slightly different:

 

                    PAL     NTSC

sdrive-ng  127839  127029  128006

sdrive-max 125000

But in PAL, sdrive-ng is at both(1 and 0) a little bit overdriven.

 

Edited November 1, 2023 by kbr

[+mytek]

28 minutes ago, kbr said:

Btw. i have tested with the highsio patch from hias(software only), and it's amazing, i can go up to pokeydiv 2 on my unmodded machine .

So i am wondering any more, if you also use this patched OS...

Yes that is what I'm using as well. And up to Divisor 2 seems to work reliably for me as well. What are you using to test this speed aspect? I believe you mentioned a copy program a while back. If that is indeed what you are using, what is your test procedure, and can you upload the file here?

[kbr]

I have no fixed testing procedure, but mostly i used "copymate 4.4", or "turbodos diskcopy". They have both it's own highspeed routines, i think.

My first test is mostly, if turbodos is generally booting.

Edited November 1, 2023 by kbr

[+mytek]

Well I tried my 1MB load test AtariBlast.atr, which transfers itself into the 1MB System RAM before running...

 

SDrive-ng (Divisor 2): 1 min 40 sec

SDrive-Max (Divisor 0): 1 min 34 sec

 

I don't think I need to worry about matching the lower Divisor setting of the Max 

 

I suspect that although the Max was able to work at Divisor Zero, it probably wasn't all that perfect when transferring data, and there were likely some retries, thus accounting for only a 6 second decrease in load time as compared to the SDrive-ng while running at Divisor 2.

[tmp]

most of these large xex/atr are (unfortunately) compressed so the load time is dominated by decompression (cpu) and not transfer speed

[CJ Atari]

Just reporting that I was able to get three of the SDrive-Simple-II up and running. Thanks to all those that made this happen!

 

[+mytek]

On 2/24/2024 at 4:16 PM, CJ Atari said:

Just reporting that I was able to get three of the SDrive-Simple-II up and running. Thanks to all those that made this happen!

 

I'm glad this worked out for you. Some day I plan to revisit this and perhaps create a revised version based on the latest SDrive-ng code which allows for a disk swap button. At that point it would be very much like Lotharek's recently released one in an SIO plug housing, but still meant for internal installation.