kbr

You have to always leave the cfg menu with the Save button, if something was changed, otherwise it will be dropped. The Scroll option enable/disable the scrolling (long) filename on top of the display during file selection.

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.

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.

Strange! But sorry, i meant this level fix in the SIO lines: Would be only necessary at the DATA-IN line.

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

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

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

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.

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

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?

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.

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

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

That was the intention 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.

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.

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

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.

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

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.

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

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.

looks like the EEPROM was not written correctly.

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

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!

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.