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.

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