ijor

One of the most annoying, but yet interesting issues of synchronous mode is that Pokey might miss serial clock pulses. This seems to be a defect of the edge detector. It doesn't seem to have any relation to the clock frequency. It happens even at the standard SIO 19.2 KHz frequency. The serial clock pulse might be missed when it reaches Pokey too close to the falling edge of the system clock. Note that what matters is the timing inside Pokey which is quite different than what we can observe externally. This is a logic analyzer trace capture when Pokey was transmitting synchronously. It is easier to see the effect of the missing pulse when Pokey is transmitting. Pokey was running a program that was constantly transmitting bytes in increasing order. The trace shows Pokey transmitting hex $0F, $10 and $11. But the middle byte instead of being $10, it became $20. It also produced a frame error and the next byte ($11) started one cycle later. The high bit marked with the red marker number 0, is one cycle too late. If should have been one cycle earlier. The only way this could happen is if Pokey missed one of the previous serial clock pulses. Note that the external serial clock was at 19.2 KHz showing that the issue affects low frequencies as well. This one above is Pokey receiving synchronously. We can't see Pokey internal interpretation of the received data. But we can see when Pokey detected the end of the byte by monitor the IRQ signal. All Pokey interrupts were disabled except the serial receive interrupt. So each pulse of the IRQ signal represents Pokey completed the reception of one byte. The trace shows 3 IRQ pulses marked with 3 markers, "0" in read, "1" in Green and "2" in violet". There are ten serial clock pulses between marker "0" and marker "1" for the second byte. This is normal and expected because each byte has ten bits including the start and the stop bit, even in synchronous mode. But between makers "1" and "2", for the third byte, there are 11 cycles, not 10. Which, in this case it can only happen, again, if Pokey missed a pulse of the external serial clock. You might note that the stop bits seem to be in a strange position. Those are actually data bits and not stop bits. Stop bits were sent intentionally with the wrong polarity (as 0 instead of 1). The idea was to produce a single pulse of the data signal, and locate it far from the start and stop bit. This way we can rule out that Pokey was missing the start bit data transition, because here there is no such transition. Of course that this would produce frame errors on every byte, but for the purpose of this test we didn't care. The last interesting thing to note in both traces, is the pattern of the output clock signal. Pokey has two external clock signals. One is the bidirectional clock that is used for receiving, this is the clock that we drive from the peripheral in synchronous mode. The other is the output clock for transmitting. The transmit clock can be configured to replicate the incoming external clock. This is the configuration used in these traces. In this case Pokey buffers and synchronizes the external clock, then connects it to the clock output one one side, and also to an edge detector that feeds the transmitter logic. As you can see, the output clock doesn't show any missing pulse. It replicates the external pattern faithfully. Which means that the serial clock pulse is not entirely missed by Pokey. Seems that only the edge detectors are the ones that missed the serial clock pulse.

Ah, ok, I understand. Yes, that would probably be doable. Good, but not every Nucleo is good enough. At least not if you want to support all the features. And by that I mean clock aligning (no errors) at the maximum frequency (~597 KHz). I'm using a board like this that usually costs even less than a Nucleo: https://www.ebay.com/itm/Core407V-STM32F407VET6-STM32-Cortex-M4-Development-Board-Motherboard-Module-Kit/182289028741

Not all the SIO protocol is preserved. I'm not using A/C/E because they are a waste in this context, although this could be added, if wanted. But yes, the SIO checksum is fully supported and it is computed on the fly while receiving the packet. Which, believe me, it's not an easy thing to do at this speed. I'll elaborate and post full sources in the other thread.

I assume this would be for 800 mode, because otherwise you could use the PBI, or I miss something? I'm not really familiar with the Incognito hardware. Does it have any kind of MCU or FPGA? Or it is just a CPLD and the firmware runs on the Atari CPU? There are here two sides, as in a typical SIO2XX implementation. The Atari needs a special loader, but it is rather small and I don't see a problem with that. However you need something on the other side to generate the synchronous serial transfer, and it has to be something much faster than Sally or a bare 6502. I used an STM32 MCU. Don't know, in your case you have access to the system (PHI2) clock I guess, right? This should make things much easier to process transfer fully synchronously.

This is not a trick or an April 1st joke. It is very real. The video is a live capture of a real Atari 8-bit computer without any hardware modification whatsoever. The numbers displayed were computed on real time when processing the transfer.

This is a detailed technical description about Pokey and SIO synchronous mode using an external clock. It is a continuation of a research I started years ago in this thread: https://atariage.com/forums/topic/139769-sio-synchronous-mode I am compiling a detailed document that would be available here together with sources and other technical data: https://github.com/ijor/sioSync In the meantime a quick highlight of the main issues for those technically oriented. Max bitrate is one third of the main system clock, which would be ~597 KHz. Pokey can't shift a serial bit in less than 3 cycles. I will elaborate about this later. The start bit must be more than PHI2 5 cycles. So the maximum effective speed is about 33 PHI2 cycles per byte, or ~ 54 KBPS. Higher frequencies require using push pull signals, including the serial clock. The pullups on these signals are too weak for open drain operation at the higher frequencies. Without special precautions Pokey sometimes might miss a pulse of the serial clock. This would create errors about once every 100 packets transferred regardless the bitrate. It is possible to avoid this by aligning the serial clock correctly to the system clock. This can be done purely with software without any hardware modification, although it might be challenging at the highest frequency. The software side at the Atari it is also challenging at the maximum frequency. At 33/34 cycles per incoming byte both interrupts and Antic DMA must be disabled. Even then, it is difficult, but not impossible, to update the checksum on the fly. Will follow up with more details.

Hyper fast SIO loader at 600 Kbps ... SioSync-Test1.mp4 Using synchronous mode, of course. Technical details, docs and link to source code, shortly in a separate thread.

It is the same power up reset signal that attempts to reset the horizontal and vertical counters. That circuit that looks like a synchronization chain it's really a power up detector, or again, it attempt to do so. If you analyze the first NOR of the circuit, the one with three inputs, it would assert only if external resets toggles too fast. That should not happen, except at power up before the clock stabilizes.

That is not accurate. It is cleared, or more correctly, it is supposed to be cleared, on power-on only. Not on hardware reset. And likely by design because you don't want to disrupt ram refresh operation during reset. Should probably be included together with the vertical and horizontal counters that you comment about the power-on circuitry that doesn't seem always to work.

That protection, present in several Broderbund releases, actually seems to target The Chip, not the Happy. The protection issues command 'T' ($74). That is an Archiver/The Chip command. Not a Happy one. This is true, but most extended Happy commands are not available until you run the Happy software. The Happy will not ack command 'T' by default.

1 - Order would matter, of course. Because at the very least it would alter the timing. But not sure exactly which is the best order. I'm not really a musician. 2 - Doesn't matter. The register is 4 bits only. 3 - Yes, it resets the envelope.

That is conceivable, and I'd say it is even possible in other platforms, but extremely unlikely in the Atari 8-bit. Weak bits were originally created in such a way that, from a given point, the rest of the sector would read random, non-deterministic, data. Furthermore, because the technique wasn't very precise, the "weak start point", the position in the sector where it starts to be weak, was never too close to the end of the sector. So the number of "weak bits" in the sector would be significant and then it would be extremely unlikely that a weak sector would read identically in two different revolutions. On later 16-bit platforms, duplication and creation of weak bits was much more precise and sometimes used a completely different technique. Then you could indeed get a match reading a weak sector in two revolutions.

I know this is an old thread, but I just found it and I think it is worth to provide an answer, well at least the for ST side. The maximum bitrate for the serial port in the ST, a standard ST, is 19200 bps. And this is a hardware limitation, not a software one. The ST doesn't bitbang the serial port. It has an UART, actually USART, chip. This the 68901 usually called MFP. The 19200 bps limitation arises from the maximum serial clock that the hardware can generate. The MFP can receive an external clock to drive the serial communication, but in the ST this clock is actually wired to the output of an MFP timer itself. That is, one of the MFP own timers is used to generate the serial clock. The math is as following: 2.4576 MHz /4 /2 /16 = 19.200 KHz 2.4576 MHz is the frequency of the crystal that clocks the MFP timers. /4 because that is the minimum prescaler of the MFP timers. /2 because each time the timer overwarps it toggles the output pin. But you need two toggles, one up and one down to generate the clock's cycle pulse. /16 because the MFP (normally, see below) divides the serial clock by 16. That's the origin of the maximum 19200 bps. Having said that, it is worth to note that it is possible to configure the MFP to use serial clock directly without dividing it by 16. That would bring the serial rate to a whooping 19200*16 = 307 Kbps! However this configuration is meant to use in synchronous mode. In synchronous mode both ends of the transmission share the same clock signal, not just the same clock frequency. The MFP receiver can't work reliably at asynchronous without using the /16 configuration (and there is no configuration in between, it's 1/1 or 1/16). But that's a limitation of the receiver. In theory, it is perfectly possible to transmit using the 1/1 serial clock divisor. This is because from the point of view of the transmitter, transmission is actually always synchronous. I didn't test it and I don't know if somebody tried, but I suppose this should work. And it should be possible to implement some kind of "asymmetric" protocol receiving at 19.2 Kbps and transmitting at 307 Kbps. This could be very useful to transmit files from the ST. It would probably require custom software at the other end, besides special software at the ST side as well, of course.

I don't know if there is an ST program that can directly extract files from .ST images. But as mentioned in this thread, there definitely are programs that can write ST and MSA images back to floppies on the ST.

The Gotek can't run Pasti/STX images directly. It must be converted to some internal format. Some Pasti images convert fines, other are not that easy to convert. In such cases you must convert from a raw flux level image, like SCP.

There seems to be quite some misinformation here about that. The gotek can run almost any disk copy protection and custom formats. Of course, it requires the correct image. Not just an ST or MSA one.

Can your newer solutions do what the OP asked, which is to write back images to real floppy? And can those solutions perform that for free or they cost money? Because that's what the OP asked. He said he has lots of empty floppies and want to write back images. Furthermore, he explicitly said he doesn't want to invest any money. May be you are claiming that hard disk adaptations are better, or virtual floppies are more convenient. Well, may be. This is a matter of personal preferences. Some people like hard disk versions, some people like to use a Gotek, and others prefer a real, old school, floppy. I see no reason why not to answer the question and let him decide what he prefer to do. May be he will prefer to use real floppies or may be not.

2 - Yes, there are tools that run on an ST that can write an ST or MSA image back to real floppies. Yes, the images could be present in a hard disk. 3 - No. Not MSA converter, that is a Windows utility. You can use the original Magic Shadow Archiver, and I believe Pera has its own ImageRunner program for ST as well. Strange that he didn't mention it. Pera?

Please scan them and post them.

At https://docs.dev-docs.org/ there are plenty official and third party documents about the ST hardware and software. This is the main, official, hardware manual: Engineering Hardware Specification of the Atari ST Computer System This is the keyboard low level software manual: Intelligent Keyboard (ikbd) Protocol

I don't think there is an US release of Spy vs Spy for the ST, or at least I never seen it. The Pasti image at Atarimania is actually the Uk Databyte release.

Yes, please share you flux level dumps. See this thread at atari-forum: https://www.atari-forum.com/viewtopic.php?f=104&t=28228 kodak80 is currently the active maintainer of the archive.

Greaseweazle is a cheaper an open source alternative to SCP and Kryoflux. It is rather new, but some people are dumping ST disks successfully with it. It doesn't replace a drive. For that purpose you need a Gotek. They are two different things. One is for dumping disks and is connected (through USB) to a PC. The other is for disk emulation and connects directly to the ST.

Interesting info @BillC , thanks. Btw, in the linked thread above, Jurgen @tf_hh claims that he never saw a 220 PSU behaving like the "Ingot". May be it was just by chance, but he probably checked lots of damaged 220V PSUs.

I just find the issue very interesting. True, it is not very relevant to the original post, except may be for the purpose of understanding why FREDDIE was specifically affected by a potential PSU problem. But as somebody that reverse engineers chip die layouts, and specifically I reverse engineered the whole Atari chipset, I am very interested in all the fab and MOS process details. Sorry if I got carried away here and I got a bit off topic.