Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ijor

Members
 View Profile  See their activity

  • Content Count

    2,621

  • Joined

  • Days Won

    2

Posts posted by ijor

  1. Posted · Edited by 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.

     

    SioSyncXmt-FrameErr.png

     

     

    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.

     

    SioSyncRcv-MissClk.png

     

    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.

    • Like 1
    • Thanks 1

  2. Posted · Edited by ijor

    1 hour ago, flashjazzcat said:

    No: this would be in XL/XE mode using the inbuilt PBI math pack overlay ROM. It already has an implementation of Hias' HSIO driver with SIO2BT support added. So, the need for OS patching is totally done away with.

    ....

    CPLD for logic, but everything procedural is done on the 6502.

     

    Ah, ok, I understand. Yes, that would probably be doable.

     

    1 hour ago, flashjazzcat said:

    I still have a Nucleo development board here (borrowed), which I guess would work. Looking forward to the full details!

    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

  3. Posted

    44 minutes ago, xxl said:

    the SIO protocol is preserved? data added to the checksum when completing data in SERIN?

     

    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.

    • Like 3

  4. Posted

    1 hour ago, flashjazzcat said:

    This is extremely interesting. If the source isn't too big, I could attempt to implement a driver in the U1MB/Incognito PBI BIOS.

     

    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.

  5. Posted

    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.

     

    • Like 3

  6. Posted · Edited by ijor

    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.

    • Like 14
    • Thanks 1

  8. Posted

    12 minutes ago, phaeron said:

    Your re-schematics show the refresh counter being tied to the synchronized reset signal, is that not correct?

    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.

  9. Posted

    Quote

    On power-on or reset, ANTIC automatically clears the following items:

       -   Refresh row address counter

    ...

    Chapter 4 - ANTIC47

     

    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.

  10. Posted

    On 2/25/2021 at 12:48 AM, Nezgar said:

    As an early copy protection mechanism, IIRC Brøderbund's "A.E." checks if your disk drive responded to Happy commands, and if so issue a format command and show "Gotcha!" on the screen.

     

    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.

     

    Quote

    The thing with the Archiver -- unlike most other "enhanced" drives -- is that it's extended commands were not available by default until a special "open code" was sent to the drive, or it was turned on with a special disk in the drive, so it was pretty immune to detection. The code was a 2-byte code unique to each drive, so it would take up to 65,536 attempts to even attempt brute forcing it by software.

     

    The happy for instance you had to explicitly set it to "unhappy" to disable the extended commands and track buffering.  ...

     

    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.

     

     

    • Like 1

  11. Posted

    5 hours ago, xxl said:

    I have got some questions:

    - the order of writing to the registers - which is the best - maybe it does not matter which register we save earlier, which later?

    - ENVELOPE SHAPE / CYCLE CONTROL register (Register R13) where lower 4 bits are used, upper 4 bits must be set? cleared? or whether it does not matter and it will not affect the operation of YM

    - if during the sound I will write the ENVELOPE SHAPE / CYCLE CONTROL register (Register R13) with the same value, it will affect the sound?

     

    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.

    • Like 1

  12. Posted

    On 1/28/2021 at 3:50 AM, Hammer said:

    This was an Atari disk I was talking about, in case it wasn't clear. My question though was - isn't it possible that 2 of the copies just matched randomly? Should there be an option to encode the sector as weak even if 2 of the copies happen to match (as long as there's at least 1 or 2 that are different)?

     

    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.

  13. Posted · Edited by ijor

    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.

     

     

    • Like 3

  14. Posted

    2 hours ago, bfollowell said:

     

    .st images are disk images and cannot be ran from or accessed by an US ... So, in addition to your US, you're going to have to spend $20-$30 to get a Gotek or a Goex and replace your floppy drive which, honestly, you should do anyway. Diskettes are far too fragile and old to continue to use them.

     

    Am I missing anything here guys? Is there an app that the OP can use to access files from an .st image from his US?

     

    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.

  16. Posted · Edited by ijor

    6 hours ago, stephen_usher said:

    The sorts of files that Greaseweazel will produce are useful for duplicating floppies onto new floppies or converting to files used by emulators. If the floppies are non-standard then usually the Gotek can't use them.

     

    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.

  17. Posted

    11 hours ago, ParanoidLittleMan said:

    I did not mention Floppy Image Runner because now there are some newer solutions, which work with less RAM. Look my previous reply here.

     

    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.

    • Like 1

  18. Posted

    On 1/28/2021 at 12:34 AM, 800_Rocks said:

     

    1) What are the options to convert some or all of the files in a .ST disk image so I can write them on the PC connected SD-Card that works in the UltraSatan? 

     

    2) Can I copy the .ST disk image to the SD-Card, take it to the UltraSatan and run a program there to convert the .ST image to either a real 3.5" floppy OR just copy the contents to a folder on the 'hard drive'?

     

    4) I see the MSA Converter program.  Would that help?  Is the MSA Converter I find at this URL safe/trusted?  http://msaconverter.free.fr/index-uk.html

     

    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?

    • Thanks 1

  23. Posted

    On 12/26/2020 at 4:23 PM, 800_Rocks said:

    6) I have been reading about the Greaseweasel (https://github.com/keirf/Greaseweazle) as a way to get most any format/filestructure floppy into an image file on a PC.  How many are doing this with old ST/E diskettes?  Are you having success?  Do you recommend?  Can you share your Greaseweasel setup/specs?  Are there any Greaseweasel docs/guides that are very ST specific?  Can you (would it make sense to) replace the original ST/E 3.5" floppy drive with a Greaseweasel capable drive?

     

    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.

     

    • Thanks 1

  25. Posted

    On 12/24/2020 at 10:29 AM, shoestring said:

    I really don't know why that even matters tbh.

     

    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.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...