ijor

Thanks. An 1088XLD is not the typical machine, though. But it might be a clue that it is probably ok for machines without the caps. I still think that it has good chances to fail on computers with those caps. I realize that it is always possible to remove the caps. I just think that it should be noted that using an open collector buffer has its drawback. It might be a non issue for some people. Important to be aware about it, nevertheless.

Same EA titles definitively need the floating bus emulation for an 800 model. This is indeed, a collateral side effect of checking for an invalid custom OS, such as Omnimon. They won't run correctly on Atari800 if it doesn't support floating bus emulation, at least not on 800 mode. And btw, the earliest EA releases require an 800, they don't run on XL/XE machines. Altirra supports two different level of floating bus emulation. One is always enabled and that is enough here. See Phaeron's comment about the details of the two different options:

Some minor error feedback to the Altirra Hardware Reference Manual. Hope it is the right place. Sorry if there is a dedicated thread, I couldn't find it. Signals are swapped at PB0 & PB7.

The slew rate for an open collector is relevant for the falling edge only, it has no raising edge by itself. The raising edge and the maximum frequency depends on the pullup resistor value and capacitance. Yes, of course, every ST has an open collector chip at the FDC outputs. But the analog components are designed specifically with this in mind. The Read data line from the floppy has a very strong pullup, 220ohm, and no capacitor. In comparison, the 8-bit machines have 4K7 pullups and most models include capacitors. Besides, it is a fact that even at USD rates, drives already have problems on computers with capacitors on the SIO lines. USD bitrate is less than half the bitrate than divisor zero. Thanks. On which computer exactly? Or more important, with or without the capacitors?

Anybody tested SIO divisor zero (126 Kbps bitrate) with the 7407 buffer? The problem of using an open collector driver is that the higher speeds probably won't work, at least not with computer that has the "infamous" caps on the SIO signals. A diode should have the same effect, I understand?

Thanks for the info and the table. Interesting, and also a bit strange. This doesn't match my tests, although my tests were mostly with synchronous mode. The problem I found was only when transmitting faster than nominal, not at a slower bitrate. And the fix, again, was to extend the start bit, not the stop bit. I think Hias experience with his high speed SIO patch is similar to mine. This certainly deserves more testing. Thanks again.

Copy protected images usually require emulation as accurately as possible. Any kind of disk acceleration patch would disrupt the timing severely and emulation would then be far from being accurate. The results are unpredictable. Some protected titles might still work, others will not. Many titles have multiple versions, sometimes with completely different protection, and it is perfectly possible that one would run with acceleration enabled and other would not. Determining exactly why one run with acceleration and the other not, would require some work and debugging that usually is not very interesting and might even change depending on the emulator version. These protected images are supposed to run with maximum accuracy. Thanks for letting us now anyway. It's perfectly fine if you like to try first with acceleration enabled. As long as you understand that some might not work like that, that's ok.

Interesting project. But I was asking about the exact frequencies when using divisors 0-3. I ask because it is very relevant if the UART frequency is slightly faster or slightly slower than the corresponding Pokey frequency. If you used 125 Kbps for divisor zero, meaning slightly slower than nominal, that explains why it works at all. Being slightly slower compensates for the late Pokey capture. It would still be ideal to stretch the start bit a couple of microseconds, but of course, you can't do that with a standard UART. I also assume that the frequency you use for divisor 3 (and probably for divisor 2 as well) is instead slightly faster than the Pokey one. And that might explain why you had to use two stop bits. Two stop bits might also compensate for the late capture. However, you should not need two stop bits for divisor zero because in that case the frequency you use is slower, not faster, and in that case two stop bits would not help. Btw, I think you are rotating the bits the wrong direction. Bits are sent LSB first.

Yes, the other output bits at the same PORT are used while seeking. They don't exactly set the current track, but they set the state of the 4 phase stepper which will change when you seek to a different track. The port map is available in several places including, of course, the schematics: https://atariage.com/forums/topic/283585-1050-field-service-manual-51-page-version/?do=findComment&comment=4275240 The SIO output bit is at PB0.

Why you need to reset the Happy? Are you setting Unhappy mode? This is hardly ever need. On almost all cases setting slow mode is good enough. You can't run the Happy software to revert the Unhappy mode, precisely because it is Unhappy and doesn't accept any custom commands anymore. That's the whole point.

Great. Very clever, Ivop. But there are a few problems. First, I'm not sure that divisor zero is reliable with open collector drivers. This has to be tested and even then it might not be fully conclusive. Does any of the SIO2xxx devices work with divisor zero using open drain outputs? The second issue is that at divisor zero you might need to stretch the start bit to compensate for the Pokey late capture. I need to make the math to be sure how long ideally the start bit should be, but probably a couple of extra cycles would be enough. Of course, ideally this extra cycles should be borrowed from the already longer stop bit. Finally, your method requires the whole table to be rebuilt for every track because the correct bitmasks depends on the state of the stepper. You might need a very fast update routine for this task as well. That's very strange. I made tests at frequencies even higher than divisor zero (using synchronous mode) and didn't found a longer stop bit helped too much. The two critical issues were, again, not using open drain and stretching the start bit. What were the exact frequencies you tried? If the device bitrate was slightly faster, it is possible that the extra stop bit compensated for the Pokey late capture issue. But not sure how the caps would make much of a difference at divisor zero.

That would be very slow. It would work, but it would take more cycles than using a simple conventional loop. Btw, I realized that I forgot about the issue of the drive SIO output being open collector. I think this eliminates the possibility to use 250 Kbps altogether. Not sure if it would work at 125 Kbps. I think all devices using divisor zero use push pull drivers. So besides all the other issues this remains to be tested and confirmed. Seems better to be a little more modest and try a "conventional" loop to transmit at just a "mere" ~89 Kbps using 11 cycles per bit and Pokey divisor 3. If it works it would probably still be a record.

Sad news, RIP Curt

No, you can't because that would disrupt the timing. Writing the stop bit must be done as fast as any other bit or it would create frame errors. And then using a JSR (or JMP) instruction would produce a fatal delay. But how could you do that efficiently? Unless you could find a very fast method to do that, the overhead is too much and you spoil all the advantage of using such a high bitrate transmission. Once again, no, that's impossible. You are bit banging at 250 KBps and Pokey can't work at such a high frequency. It's not a software issue, it is a limitation of Pokey. The maximum frequency Pokey can operate asynchronously is at ~127 Kbps. I initially showed the code for 250 Kbps just for showing how fast the 1050 can transmit, at least in theory. This can't be really used, at least not against Pokey. Conceivable, 250 Kbps could be used when connected to a PC.

The problem is not exactly the rotational latency. But yes, generating all those instructions like that is so slow that makes the whole thing not worth.

You don't need to set the port direction at all. That is performed only once at reset time. The SIO signals are unidirectional, and they are open collectors. There is no need to ever change it to input. But yes, what you suggest is perfectible possible if you have enough RAM. As a matter of fact, a fully unrolled code for the whole sector is the only way to transmit the whole sector at a 250 Kbps effective rate. But 250Kbps is not realistic. As I said, Pokey can't operate asynchronously at that frequency. And regardless, the overhead necessary to precompile the code is too expensive. Precompiling the opcode would probably require something like 10 cycles per bit, I guess. Add to this the 4 cycles per bit to for the actual transmission, and at the end this turns to be slower than using non precompiled code. Using 125 KBps with Pokey divisor zero might not be much better. The extra 4 cycles you can spend between each bit might, conceivable, make a difference and allow for some clever optimization. It might be even possible to process, at least partially, the next byte while you are transmitting the current one. But don't know. Might be it would also require a too expensive overhead between bytes or between sectors.

No. In first place the 1050 has a RIOT, not a PIA. The chips are quite similar, but the RIOT doesn't have a control register, you can always address the PORT register directly. In second place, when I said unrolled loop I didn't mean at the byte level, but at the bit level. You still obviously have to loop for each byte. So, for the maximum theoretical limit of 250 Kbps, the code would be something like this: ; Process start of byte LDA ValueFor0 ; Actual values depend on the stepper output bits, LDX ValueFor1 ; that share the same RIOT port STA PORTB ; Xmit start bit ; Might need a couple of cycles delay here to compensate for Pokey late capture STX PORTB ; Xmit bit 0. Opcode would be precompiled depending on byte STA PORTB ; Xmit bit 1. Precompiled STA or STX opcode ... STX PORTB ; Xmit stop bit ; Loop for next byte

The 250 Kbps figure was just to show how fast it is possible to transmit, in theory. Pokey can't operate at such a high frequency, except on synchronous mode that the 1050 can't use anyway. So the maximum we can normally use is divisor zero that is ~127 Kbps. Yes, there is a granularity issue and it is not possible to use an arbitrary frequency. But the frequencies of the sender and the receiver don't need to match exactly. They just have to be close enough. Async serial transmission can tolerate about a 5% difference. And here that we can adjust the length of the start bit, we can achieve a more optimal alignment that could tolerate close to 10% difference in the frequencies. So at divisor zero the drive would transmit at 125 Kbps and Pokey would receive at ~127 Kbps (slightly different depending on PAL or NTSC). As you can see, the difference is about 2% in the worst case which should be good enough. Of course, this has to be tested to confirm the theory. But again, to achieve such high speeds you need to implement some kind of precompiled code that would either require considerable overhead between bytes, or either use considerable amounts of RAM. If I'm not mistaken, a "standard" code loop could be as fast as 11 cycles per bit, perhaps even 10 (or 9?) cycles using some undocumented opcodes tricks. Still, at 11 cycles per bit and Pokey divisor 3 would give you ~89 Kbps. Not bad Yes, the other direction, from the computer to the drive, is a completely different game.

So how fast the 6502 on the 1050 can bitbang the SIO output? You can't go very fast with "traditional" shifting and rotating bits. A better 6502 coder might correct me, but I don't think it is feasible to do it at 8 cycles per bit, not even unrolling the bit loop. But what about the old self modified trick? Something as simple as this should work: STX PORTB ; 4 cycles STA PORTB ; 4 cycles ; repeat for a total of 8 instructions "Just" modify the opcodes according to each bit and preload the correct values on the X and A registers, and you can transmit as fast as 4 cycles per bit, for a whooping 250Kbps! Of course, there is a considerable overhead to modify the code, and you must do it for each byte. So even if you, technically, could transmit so fast, the delay between each bytes would slower the effective bit rate. An alternative that might require less overhead is to use precompiled code covering all the 256 values, and you just jump to the appropriate address for the byte you want to transmit. The problem here is, of course, the amount of RAM. Now, you don't need a full separate routine for each byte value because it is possible to share a lot of code. And even at 7 or 8 cycles per bit you still have time to add a JMP or Branch instruction between each bit: ; Transmit 1 0 0 0 STX PORTB ; 4 cycles JMP x01 ; 3 cycles, might need to spend an extra cycle ; Transmit 0 0 0 0 STA PORTB ; 4 cycles STA dummy ; Spend 3 or 4 cycles x01 STA PORTB ... Not sure exactly how much RAM it would require. It is complicated to calculate because you can include conditional branches as well. There might still be in addition, a problem of granularity to achieve a closer match to the Pokey frequency. But seems that 8 cycles per bit should be close enough for zero divisor. All of this ignores the hardware side. As Nezgar said, there might be circuit limitations at the drive external logic.

Once more again, the SCP software can't write back most 8-bit images. This is because the data on most disks isn't aligned to the index hole and the SCP software can't currently locate a proper write splice point in the middle of the track. That's why using a8rawconv is recommended because it usually is much better at locating a write splice point. Of course, if the data is aligned to the index hole, then the SCP software should be able to write back correctly. Many original disks are aligned to the index hole, MULE is a good example. Disks formatted with a XF551 are aligned as well. Jim (SCP designer) said recently that he will improve the software for this purpose. So this might change in the future.

It would be interesting to test how fast the 1050 CPU can xmit. It doesn't matter so much if receiving would be slower. The most important direction of transfer is from the drive to the computer, and it is possible to use an asymmetric protocol. We now know something very important that it wasn't known at the time of the Speedy and the Turbo. It is the Pokey late capture. It is then, conceivable, that it might be possible to achieve faster rates by taking this into consideration and extending the start bit to compensate.

It works with the SCP hardware through the USB interface, not with internal old school floppy drives. There is no need to compensate. The software only needs to detect correctly the type of drive you are using (48tpi or 96tpi), and also its RPM (300 or 360 RPM). It seems that your problem is again, the double step issue.

I never tried, but I understand respeQt can write back .PRO image to both a Happy or a Chip modified drives. Of course, that won't work for every protection. But for simple ones it should work.

It is certainly about time to contact the manufacturer. That's one of the advantages of buying a Goex instead of a Gotek. You can get some manufacturer support.

I understand you are trying to copy a disk directly and not dumping an image, and then write back the image, correct? I think this is a rare usage. Most people either create an image, or either write back one. So not sure how much help are you going to get with this procedure. Anyway, the SCP software usually can't locate a correct write splice. You need to use a8rawconv to drive the write back procedure. And for the same reason a copy directly would fail most of the times. So don't copy. Make an SCP image instead, then write it back using a8rawconv.