sdrive SDrive-Simple - Yet Another Hardware Variation

[+mytek]

@kbr is there any way that you can generate the  SDrive-ng-V2 SDrive.hex and SDrive.eep files and upload them here? I plan on doing a direct flash to the ATMEGA328P

 

I tried various ways to 'make' the files from the zipped download , but nothing was working for me.

 

Do the same fuse settings apply that I used previously?

 

[+mytek]

@woj just curious if you know how to compile (make) the two required programming files at this LINK for the ATMEGA328?

[woj]

@mytek Has built clean on the first try, but I have no way of checking if they work, or are the right files, or what options in the source have been enabled, etc.

SDrive.hex SDrive.eep

Edited September 2, 2023 by woj

[+mytek]

Thanks @woj for doing that 👍

 

I have a breadboard test circuit built, but have run out of time today. Tomorrow I'll flash the chip, and try it with the fuse settings I posted. If that doesn't work I can try the ones listed on the sdrive-ng-V1 webpage. Or if @kbr sees this maybe he can set me on the correct path.

 

sdrive-ng-V1 Fuses

[kbr]

I recommend you to use the bootloader-sdNG.hex, then you are able to update the firmware from a sd-card in place.

FUSE must be set like sdrive-ng-V1, especially the hfuse to enable bootloader support.

After flashing the bootloader.hex you need only the SDrive.bin present at the root directory on a sd-card inserted, and power on.

 

PS: But should we start on a new thread?

bootloader-sdNG.hex

SDrive.bin

Edited September 3, 2023 by kbr

[+mytek]

5 hours ago, kbr said:

I recommend you to use the bootloader-sdNG.hex, then you are able to update the firmware from a sd-card in place.

FUSE must be set like sdrive-ng-V1, especially the hfuse to enable bootloader support.

After flashing the bootloader.hex you need only the SDrive.bin present at the root directory on a sd-card inserted, and power on.

Sounds like an even better plan 👍

 

5 hours ago, kbr said:

PS: But should we start on a new thread?

I will eventually be starting an independent topic related to using this within a multi type device for the 576NUC+, but that is still down the road a bit. And since this thread is about building something that is in essence a simpler repackaging (fewer buttons & LEDs, or touch screen) of the full Sdrive-ng or SDrive-Max, I think for the time being we can continue the discussion here.

 

I could certainly see this becoming the basis for an evolving SDrive-Simple-V2 design.

[+mytek]

Worked like a charm 👍

 

Breadboard prototype connected to 576NUC+.

 

Based upon Updated schematic for my intended target.

576NUC+RPSX_SDrive_V2_schema.pdf

 

Set up Two Disk Demo, and then hit Reset.

 

First Disk Loaded & Waiting for 2nd Disk...

Pressed Disk Rotate Right Button, and then hit Return...

Success!!! Demo Started...

[kbr]

Good Job 👌

 

There is a lack of documentation, code cleanup and so on, but i stopped working on this project, when sdrive-max has started.

 

[+mytek]

1 minute ago, kbr said:

Good Job 👌

Thanks   It was very satisfying to see the firmware updating directly from the SDrive via the sdrive.bin file on the SD Card. Makes for easy customer updates.

 

1 minute ago, kbr said:

There is a lack of documentation, code cleanup and so on, but i stopped working on this project, when sdrive-max has started.

Yes it did take a bit of initial head scratching, looking around the web, and your help (and thank you too @woj) to put all the pieces together, but using the SDrive-ng-V2 version really fulfills all that I needed in my newest project. It'll help fill in for what the inclusive A8Pico Cart aspect lacks. And although your SDrive-Max is quite impressive, I just needed something a bit simpler this time around.

 

Having the rotate disk function working is uber cool 👍

 

By the end of my project there will be a bit more documentation for people seeking information on the SDrive-ng, as well as files to download, all available in one central location at AtariBits.com, I'll also be sure to include links to what you've already posted as well.

[Forrest]

Mytek,

Does the ATMEGA328P you were programming have the Arduino bootloader previously flashed, or was this a blank chip before you programmed it?

[+mytek]

4 hours ago, Forrest said:

Mytek,

Does the ATMEGA328P you were programming have the Arduino bootloader previously flashed, or was this a blank chip before you programmed it?

It was blank. Although if something like the TL866II Plus is used to flash it, you can erase anything that might have been previously flashed, including the Arduino Boot Loader.

 

New chips are once again available from Jameco.com for around $3.50 HERE.

[kbr]

21 hours ago, mytek said:

Thanks   It was very satisfying to see the firmware updating directly from the SDrive via the sdrive.bin file on the SD Card. Makes for easy customer updates.

That was the intention

 

21 hours ago, mytek said:

And although your SDrive-Max is quite impressive, I just needed something a bit simpler this time around.

People wanted cool displays , that was while i aborted the work on sdrive-ng, because of the poor response. The other barrier was to build it by self, i think.

[+mytek]

4 hours ago, kbr said:

People wanted cool displays , that was while i aborted the work on sdrive-ng, because of the poor response.

Well you certainly accomplished that with the addition of the color touch screen display - quite a leap forward in technology from the former LEDs of the original and ng versions.

 

4 hours ago, kbr said:

The other barrier was to build it by self, i think.

Yeah the DIY aspect can be a bit much for many people to take on. Personally I love it, but I'm kinda crazy in that way 🤪

 

--------------

 

I discovered something interesting today when I was running through the SIO divisors with the ng-V2 firmware. Everything from divisor 2 on up works flawlessly from what I can tell, but divisor 0 and 1 get stuck when trying to load either an XEX or ATR image. It reads for about 1 second , goes dead for a good number of seconds (about 35 secs), and then reads for another second or two, repeat. I'm using a stock XL OS with the exception of Hiassoft's HSIO patch for high speed operation.

 

I'm currently testing this on my 576NUC+, and just temporarily I switched back to the SDrive daughter board hardware that was based on the SDrive-Max V1.3b firmware. With the Max version, all divisors work.

 

This isn't a deal breaker on divisor 0 and 1 not working, since divisor 2 is still very fast. But I was wondering if you had any thoughts?

[kbr]

19 hours ago, mytek said:

This isn't a deal breaker on divisor 0 and 1 not working, since divisor 2 is still very fast. But I was wondering if you had any thoughts?

I am surprised, because the sdrive-ng has the better baud rate matches. It could only be a timing issue, there was anything changed between the devices. I don't have tried it by my self ever, because i have no highspeed modified computer. An other guy has tested anything with highspeed for me in past, but only for SDrive-MAX.

In a spare time i will have a look at the code, how that could be...

 

[+mytek]

17 minutes ago, kbr said:

I am surprised, because the sdrive-ng has the better baud rate matches. It could only be a timing issue, there was anything changed between the devices. I don't have tried it by my self ever, because i have no highspeed modified computer. An other guy has tested anything with highspeed for me in past, but only for SDrive-MAX.

In a spare time i will have a look at the code, how that could be...

Well if you do come up with something you want me to test, just let me know. Because of the easy firmware upgrade process this will be a snap, and also not an issue for releasing the design with the presently available firmware.

[kbr]

Now i had a look at the code, but i can't see any dramatically differences because of the SIO timing. The only thing, i have removed the T2 delay after lifting the command line, because of the display LED_ON routine, which makes also a delay, but i don't really know, how long exactly. Maybe this is more than the 100µs, as sdrive-ng does, display routines are very expensive.

But the specs says T2 should be 0-16ms, so both should be correct.

 

The differences in baud rate:

Pokeydiv     1      0

sdrive-ng  111859 127839

sdrive-max 111111 125000

 

Edited September 24, 2023 by kbr

[+mytek]

2 hours ago, kbr said:

Now i had a look at the code, but i can't see any dramatically differences because of the SIO timing. The only thing, i have removed the T2 delay after lifting the command line, because of the display LED_ON routine, which makes also a delay, but i don't really know, how long exactly. Maybe this is more than the 100µs, as sdrive-ng does, display routines are very expensive.

But the specs says T2 should be 0-16ms, so both should be correct.

 

The differences in baud rate:

Pokeydiv     1      0

sdrive-ng  111859 127839

sdrive-max 111111 125000

 

If you need me to run a test on any potential firmware changes, just let me know and I'll do it on my NUCplus4 hardware

[kbr]

Thank you, but i have no idea, on witch screw we should drive at the moment...

It would be very helpfully to know, at witch phase the communication stops. But this could only be analyzed by scope, i think.

 

[+mytek]

6 hours ago, kbr said:

Thank you, but i have no idea, on witch screw we should drive at the moment...

It would be very helpfully to know, at witch phase the communication stops. But this could only be analyzed by scope, i think.

 

Understood. At some point down the road I might delve more into this, but I gotta confess even putting a scope on it probably won't help me understand what's going on since I would also need to learn much more about the high speed SIO process itself.

[_The Doctor__]

showing scope trace data up to the fail would show KBR the timing issue and give a clue as to which signal is too long or short, this will help him adjust the timing window start and stop length and placement within the frame. It is how he will know which screws to turn to get things back on track.

[+mytek]

18 minutes ago, _The Doctor__ said:

showing scope trace data up to the fail would show KBR the timing issue and give a clue as to which signal is too long or short, this will help him adjust the timing window start and stop length and placement within the frame. It is how he will know which screws to turn to get things back on track.

There is no apparent transition between fail and working as far as I can presently tell when set to divisor 0 or 1. It simply doesn't appear to work at all and just sits there spinning its wheels the whole time. But who knows maybe with a scope looking at the data and command line it will reveal something useful. I will try this later when I have some spare time from my other activities.

[kbr]

omg, i always typed "witch" instead of "which" 🤭

 

I think i have to modify one of my computers that i can test it by myself...

 

An other question: Is this NUC 100% timing compatible to an original Atari?

[kbr]

On 9/5/2023 at 12:13 AM, mytek said:

It reads for about 1 second , goes dead for a good number of seconds (about 35 secs), and then reads for another second or two, repeat.

This sounds like it's running in SIO timeout, so the computer is waiting for data from the device, some bits may be dropped.

[+mytek]

4 hours ago, kbr said:

An other question: Is this NUC 100% timing compatible to an original Atari?

 

Yes it is. And it can run an Sdrive-Max or SIO2PC-USB down to divisor 0 on it.

 

I still have one of these bread boarded, so when I get back into town later this week let me hook it up to stock 800XL and see what it does on that setup.

[kbr]

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.