ijor
-
Content Count
2,621 -
Joined
-
Days Won
2
Posts posted by ijor
-
-
7 hours ago, Shannon said:While I'm thinking about it. I noticed something interesting about some of the EA disk protection. In particular I'm thinking of the game M.U.L.E. But I'm sure other EA games are affected by this as well.
...
So out of curiosity I tried it on Altirra under the same config ( A800 48k ) and the game loads fine. After some reading it appears to have something to do with the Atari 800 having a floating bus or something like this? So I guess the floating bus is not emulated in the Atari800.
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.
QuoteAltirra has it as an "option" in the menu but it must duplicate some of the behavior of the bus with that option unchecked.
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:
-
1
-
-
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.
QuoteTable 44: 1050 RIOT I/O port assignments
...
PB7 Output SIO data input (device to computer)
PB0 Input SIO command
Signals are swapped at PB0 & PB7.
-
1 hour ago, TGB1718 said:Why would that be ? the slew rate of this chip is around 20ns, with pull up resistors it operates
in the MHz range.
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.
1 hour ago, TGB1718 said:I recently used one of these in my Atari STE debugging problems on the Read data line from the floppy
drive, I put it between the floppy drive and the FDC chip to clean up the signal and it performed very
well indeed and that's a much higher bit rate than the 8 bit SIO.
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.
1 hour ago, DrVenkman said:Normally I run mine no faster than about Divisor 6 for SpartaDOS 3.x compatibility, but I just set mine to Divisor 0 and loaded a game - worked great.
Thanks. On which computer exactly? Or more important, with or without the capacitors?
-
On 4/4/2020 at 12:41 PM, TGB1718 said:Sounds like your SDrive doesn't have the 7407 buffer chip mods to make it work with other SIO devices
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?
-
4 hours ago, ivop said:Div 0,1 and 3 were slower. Div 2 was faster. I don't know why, but at 8N2 they worked. At 8N1 they stuttered.
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.
-
1
-
-
15 hours ago, Shannon said:I just noticed that the "Mr. Do (Datasoft)" version in the latest archive? CRC "57ACB209" will cause a crash in emulators within a few seconds of starting a new game. In Altirra this can be remedied by turning off Acceleration D : Patch I/O. However I also have discovered that the version available on Atari Mania CRC "CADB7C54" does not have this issue and will not cause a crash with the acceleration on.
Anybody interested in looking at the two dumps to determine the difference between them?
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.
4 hours ago, Shannon said:As for Altirra.. it actually has drive D : acceleration code that can handle most ATX protection formats. I've only occasionally had to turn it off.
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.
-
5 hours ago, ivop said:I never went higher than the exact 125kbps an ATMega328 can deliver. I noticed that divisor 3 and lower did not work reliably at 8N1, but started to work when I switched to 8N2.
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.
-
1
-
-
1 hour ago, E474 said:I don't understand the comment about rebuilding the tables for each track, unless some of the bits in PORTB_DATA are used for specifying the current track? Out of curiosity, which bit in PORTB_DATA is used for SIO (actually, does anyone have a description of which bits mean what, and maybe also for PORTA_DATA)?
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:
The SIO output bit is at PB0.
-
3 hours ago, Larry said:Is there a simple way to reset a Happy Drive via software?
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.
2 hours ago, DrVenkman said:Can't you run the Happy Warp software to set or reset UnHappy mode?
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.
-
2 hours ago, ivop said:Here's one with a LUT of 2kB. 8 cycles per bit, 12 cycles for stopbit. Not tested, but here you go:
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.
2 hours ago, ivop said:My sio2world code uses 8N2 for divisors 3 and lower, without snapping the caps in your Atari.
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.
-
2 hours ago, E474 said:I think adding NOPs between outputting each bit would bloat the code too much, so maybe it is better to JSR to either OUTPUT_BIT_SET or OUTPUT_BIT_CLEAR in the TRANSFER_DATA code? Providing these routines are on the same page, you are only updating one byte in the TRANSFER_DATA routine per bit output. Not sure how many cycles per bit, but code would look something like:
TRANSFER_DATA
JSR OUTPUT_BIT_SET
JSR OUTPUT_BIT_SET
JSR OUTPUT_BIT_CLEAR
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
-
19 hours ago, E474 said:You could also replace the send stop/send start bits with a jsr to a routine to do this as this would result in smaller unrolled code.
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.
5 hours ago, E474 said:For processing the bit value in each byte, probably quicker to use an 8 byte buffer to store each STA or STY opcode, depending on the value of each bit of the byte being processed, and then update the appropriate set of 8 instructions in the TRANSFER_DATA unrolled code
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.
5 hours ago, E474 said:STA PORTB_DATA
STY PORTB_DATA
...
I think the code from @HiasofT would be the best basis for extending to support this transfer speed, so it could be possible to actually have read from drive speeds at this speed.
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.
-
15 hours ago, Rybags said:Generating bit-bang instructions for about 1300 transitions per sector might potentially cause sufficient delay that rotational latency screws up any speed gains?
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.
-
2 hours ago, E474 said:Either way, if you only need to set the port control direction at the start, and can just do sequential (bit) writes afterwards, you might as well unroll the code for writing a whole 256 byte sectors worth of data, and update the writes to STA or STY depending on the actual sector data.
...
and then have a routine that converts each bit of each byte of sector data into STA or STY opcodes in the TRANSFER_DATA code.
That would give just over 6K of unrolled code, ...
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.
-
5 hours ago, E474 said:I am a little bit rusty on programming PIAs, but isn't the (unrolled) code going to be something like:
LDX #PORTB_SET_SPECIFIC_BIT_DIRECTION_TO_OUTPUT
LDA #FIRST_BIT_OF_FIRST_BYTE
STX PORTB_CONTROL
STA PORTB_DATA
LDA #SECOND_BIT_OF_FIRST_BYTE
STX PORTB_CONTROL
STA PORTB_DATA
...
LDA #EIGTH_BIT_OF_BYTE_256
STX PORTB_CONTROL
STA PORTB_DATA
I think I am missing start and stop bits for each byte sent, but that would be extra unrolled code. Prior to transmitting the sector, you would update the immediate #opcodes according to the sector data. The LDA, STA, STX code would be 8 bytes/bit, so for 256 bytes would be 256 * 8 bits = 2k, 2k * 8 bytes = 16 k of unrolled code. So I don't think that would work.
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 -
11 hours ago, Nezgar said:@ijor 250kbps is pretty cool, but wouldn't it be hard to get a consistent arbitrary speed like 125kbps? It wouldn't be a straightup loop - you'd have to add varying amounts of delay cycles to achieve specific rates, ideally multiples that line up with code loops... bit timing I would think would be quite inconsistent "jittery", with some bits sustaining longer than others, plus the Atari running at a different clock frequency will be 'sampling' those bits at different intervals as well... And of course wonky the other direction as well.
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.
-
5 hours ago, cwilbar said:1. write out 2 disks from your .scp image; one with the bundled archiver software, one with a8rawconv ...
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.
-
8 hours ago, Larry said:I presume that a8rawconv will find the SCP 48TPI floppy drive through the USB? (Or does it need to be inside my PC to write using Phaeron's software?)
It works with the SCP hardware through the USB interface, not with internal old school floppy drives.
8 hours ago, Larry said:I think I may know what the issue is -- it is the 288 vs 300 rpm's. If the SCP software does not compensate (like an XF551), it would fail. Here is a screenshot of a disk copied with SCP then read with a 1050 with the Archiver/Editor.
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.
-
45 minutes ago, Larry said:And I managed to make some .pro images of several disks that have pretty mundane copy protection. One small benefit of the ProSystem is that the files it produces are quite small -- certainly as compared to flux image. And you can mount and use the .pro images with APE. I remember that some folks here were not happy that the PS software is not open source (same as APE software). But it is "free" if you own an APE USB interface and the licensed software, so there is nothing extra to buy. You just need an Atari computer and a 1050 or other drive. (IIRC) you can write out the images with a Happy Drive. I don't think that it can write to an Archiver, but not sure about that.
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.
-
1
-
1
-
-
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.
-
11 hours ago, Larry said:Source Device SuperCard Pro (D0)
Target Device SuperCard Pro (D0)
When using just a copy option, it sounds like the drive is trying to go past track 39 -- makes a thumping sound starting at track 20
I'm also concerned that both the Read and Write densities are set to "High." Low is grayed out and I can't select it. When I make a copy of a regular SD Dos disk and try to boot it, my 1050 acts like it is reading the first track OK, then goes into "Boot Error" and retries until I shut it off.
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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
using the SDRIVE-MAX in conjunction with other drives
in Atari 8-Bit Computers
Posted · Edited by 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.