[SDrive-Simple - Yet Another Hardware Variation]

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.

[SDrive-Simple - Yet Another Hardware Variation]

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.

 

[SDrive-Simple - Yet Another Hardware Variation]

Strange!

 

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

Would be only necessary at the DATA-IN line.

[SDrive-Simple - Yet Another Hardware Variation]

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...

[SDrive-Simple - Yet Another Hardware Variation]

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...

 

[SIO2BT]

On 10/25/2023 at 9:53 PM, TheMontezuma said:

Regarding a micro-controller between Atari and BT - I got some promising results with ESP32 (no need for OS patch!), but had no time to finish it:

https://github.com/TheMontezuma/SIO2BT_ESP32

Nice, i am working on a similar project right now, but have nothing published yet, because it's in raw alpha state...

[SDrive-Simple - Yet Another Hardware Variation]

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.

[SDrive-Simple - Yet Another Hardware Variation]

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.

[SDrive-Simple - Yet Another Hardware Variation]

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?

[SDrive-Simple - Yet Another Hardware Variation]

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.

 

[SDrive-Simple - Yet Another Hardware Variation]

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

 

[SDrive-Simple - Yet Another Hardware Variation]

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...

 

[SDrive-Simple - Yet Another Hardware Variation]

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.

[SDrive-Simple - Yet Another Hardware Variation]

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.

 

[SDrive-Simple - Yet Another Hardware Variation]

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

[SDrive-Simple - Yet Another Hardware Variation]

Just use the sdrive-ng, it has a drive rotate button(LEFT/RIGHT) already.

 

Well, there are some missing features like ATX support, but a better SIO highspeed capability because of the 14.318MHz crystal.

If i am lucky, i could try to backport some new features from the sdrive-max, if really needed.

 

PS: Better use this never version, if you really plan to build it.

[XF551 Repair Question]

On 7/1/2023 at 1:50 AM, kheller2 said:

Is there a disk in the drive?  Otherwise, I read, that it will go to that menu you see.

 

http://blog.3b2.sk/igi/post/Hyper2b-XF-10-MANUAL.aspx

 

See Chapter 8, you have set the right operating mode?

[SIO2BT]

Nice project!

Handling the whole SIO protocol over bluetooth is cheap, but a big timing issue. Things like ATX support would be unthinkable. Patching the atari OS is a no go for me!

I think, there should be a small microcontroller to handle the SIO protocol, and only the payload should be transmitted via bluetooth.

 

[SDrive troubles - help appreciated]

Sounds like you haven't flashed the eeprom_writer.hex before.

 

[SDrive-MAX ATX support]

Maybe there would be a solution for simple 8 or 16k ROM's via a special loader, but all others with more logic you can forget. Also some ROM's are checking, if they are running on ROM, and won't work on RAM without hacking the code.

[SDrive-MAX ATX support]

On 3/7/2021 at 4:12 PM, Gregkrkpl said:

Hello.
I dug up my old XEGS Atari. I built the Sdrive-MAX. looks like it works. But I have a problem. does not load sdrive.atr and other files. I've tried everything. I checked the connections, even with a meter, I bought 2 arduino boards, I bought another card, I tried other files. I marked 1050 options in config etc.
interestingly, CAS files are loaded. it takes the same amount of time as with a real tape recorder. so I assume it works. power supply from atari and usb (not all at once). when I turn on the atari and "farts" I see that the TX diode is flashing quickly on the arduino board .
what am i doing wrong, how to fix it.
Regards Greg

looks like the EEPROM was not written correctly.

[SDrive-MAX ATX support]

On 2/11/2022 at 4:32 AM, CMR said:

Is there any chance .bas files will ever be loadable?

No, .bas files are not supported directly yet, put it into an ATR with a DOS, then you can use it for reading and writing.

Or boot a DOS first into BASIC, insert the .bas file into D2:, and load them with: RUN "D2:*.BAS"

But this is readonly!

 

There would be a special bootloader necessary for it, does anyone know a device, witch support them directly?

 

On 9/5/2022 at 11:55 PM, Ricky Spanish said:

Quick question: I cycled the FastSIO from $06 69000 to $0A 53000 then pressed [Ctrl] + W to write and confirmed with "Y", yet it doesn't seem to save the new configuration. If I unplug the S-Drive max then plug it back in, I need to cycle it back to $0A 53000. Is there something I'm doing wrong ? Thanks.

This is a relic of the original design from sdrive, this options are saved in the sdrive.atr on the SD card only!

So you have to boot sdrive.atr once after power cycle to restore this options.

[Cloning an SDrive-MAX]

On 3/19/2022 at 2:06 AM, dzzy1982 said:

I was actually able to flash this using the hex files and avrdudess. It did give me an error on verification of the eeprom, however it does seem to be working fine. Is there any reason one could not use an arduino nano in this application with a microsd breakout reader?

I'm not sure, but the NANO uses an other pinout, i think, and SDM does not use the arduino IDE, so there would be any adaption necessary.

 

The arduino bootloader for USB update does not support accessing the EEPROM, thats why you get an error there!

And thats why i have written an extra eeprom_writer.hex application to do that.

 

But you are able to read the flash from the device for duplication, e. g.:

avrdude -c arduino -p m328p -P /dev/ttyACM0 -U flash:r:sdrive.hex:i

PS: But this only works with original arduino devices, not with the @mytek variant without a bootloader!

[SDrive-Simple - Yet Another Hardware Variation]

Yes, i am thinking about a motor control also, but this is nothing what you can use without a display, for this project here.

 

I don't have all under control, there are many relics from Bob & Raster(👏many thanks to the prime fathers of this project at this point 👏), which i don't understand fully.

The compiler warnings disturb me also, but i am only a hobby coder, and have not so deep experience. So many thanks for your hints, i will have a look on it by time!

 

BTW: I have released a new beta yesterday, it would be nice, if someone could testing: https://github.com/kbr-net/sdrive-max/releases/tag/v13b2

Especially with bigger images, which needs the use of PERCOM, and ATX support.

[SDrive-Simple - Yet Another Hardware Variation]

Sorry for the confusion, but i'm using a little bit other development strategy: I do all newer changes in an other (beta) branch, so that the master branch is always holding the latest stable version.

 

It would be time to release 1.3, but there is a missing goal feature right now, and the flash memory is exhausted. So i'm thinking a lot about optimization or things that could be removed, and finally i got stalled...