Apple II DISK Emulator using STM32

In post #47, 'VIBR' wrote:

" I understand the use of the 74LS123 (channel B) to trigger a clock on the stm32 side. I assume that the clock will clear the 74LS393 buffer after 16us ? after that I am a bit lost. I would need a step by step to understand the way the SPI RX will be fed ... "

Uncle Bernie comments:

Sorry I can't provide step-by-step instructions for that because I don't know what the ST32 can do internally, and what needs to be done with an external circuit. But I can provide some theoretical background as to the "why" and "how to do RX = write mode":

Unless your ST32 has a master clock that is phase locked to the Apple II motherboard clock, which most likely is the case, as it can't be done from the 20 pin floppy cable itself, you have got what is called a "plesiochronous system":

https://en.wikipedia.org/wiki/Plesiochronous_system

This problem with such systems is that their clock frequencies, even if nominally being the same, will never be exactly the same (even if you would use two or more very accurate atomic clocks) and this inevitably means the relative phase of the different clock domains will wander and this will occasionally cause a "clock slip" or "sync slip" in which clock domain #1 has seen N clocks and clock domain #2 has seen N+1 or N-1 clocks. Unless measures are taken to handle this situation, the state machines in the two different clock domains will get out of lockstep, or out of sync, and so they won't properly "talk" to each other anymore.

It is not trivial to handle this situation because signals from one clock domain need to be synchronized with signals from the other clock domain, and so, occasionally, the synchronizer flipflop will get metastable and its output is unknown, neiter logic "0" nor logic "1". The number of so-called "patent solutions" to this metastability problem are legend, but none really works as claimed. All they can do is to decrease the probability of such a metastable event happening. The system must always be designed to be able to detect when things go astray and then the communication protocols must have a way to reset and recover and resume normal operation. Which for real time systems with required guaranteed response times can be a formidable design challenge.

Note that any floppy disk storage system has exactly this problem because the data stream coming from the read head is jittery, and not phase locked to anything. So the synchronizer flipflops WILL get metastable from time to time, the read attempt will fail, and the system will detect that and initiate another read attempt.

In the DISK II system, this was a reliability issue because of the low synchronizer clock frequency of 2 MHz (Q3 on the bus). It was good enough to sell, and worked reasonably OK (otherwise APPLE, the corporation, would not exist anymore) but the issue was known and Apple engineers made numerous changes to Apple's floppy disk systems over time. For instance, the IWM increased the clock frequency of the synchronizer flipflop from 2MHz to 3.5, 4, 7 or 8 Mhz, depending on the configuration of the IWM and whether it was set to SLOW or FAST mode having 4us vs. 2us bit cells.

For your ST32 based floppy emu, you don't have any motherboard clock available on the 20 pin floppy disk cable, so you need to derive the SPI clock in write mode (receiving the bit stream from the DISK II controller) from the WRDATA signal, which toggles for each flux change, and this is governed by the famous "Woz machine" on the DISK II card which is clocked by Q3 (actually, the inverted Q3). The crude digital phase locking technique with the counter which I proposed in the above thread cannot be avoided. Note that it won't be 100% failsafe because of the plesiochronous nature of the system and because of possible metastability of the synchronizer which in this case is the counter. To avoid metastability would require to use a clock signal from the Apple II motherboard to phase lock your ST32 master clock  to. Which you only have if you would put your floppy emu on a slot card. But I think the proposed solution with the counter can be made robust enough to be acceptable for typical users ... it's not a life support system or an autopilot for airliners.

Such is the nature of this kind of system design. The plesiosaur went extinct for a reason (... just joking ;-)   . . .   but the bottom line of this post is that even with a humble floppy emu we are dealing with a system design that is not trivial, and we need to avoid pitfalls which for the ignorant are inevitable.

So if you ST32 can generate the SPI RX clock from WRDATA all by itself, fine, just detect the WRDATA change(s) and reset the counter for each change. Use the appropriate counter output which gives you a rising edge SPI clock in the middle of a bit cell (2us after the WRDATA changes). The ability of the counter to run for four bit cells (or 16 us) would allow to handle cases where no WRDATA change occurs for 2 or more bit cells. Apple II GCR allows for no more than 2 "0" bit cells in a row but violations of this rule are possible. The problem, as I see it, and why the counter must be "longer" than a single bit cell, is the clock frequency of the Apple II (14.3181818 MHz) which, depending on the clock of your ST32, may not lead to a power of 2 for the required counter rollover. It may be necessary to add some logic to make all of that work correctly. Hence, my suggestion to use a GAL, which is flexible. If you tell me which clocks you can make on a ST32 pin, I can run some simulations to see how long the counter must be and which logic is required. Of course, if the ST32 could do some kind of digital PLL by itself to phase lock the SPI clocks to WRDATA changes, then you can do everything with proper configuration of the ST32. Not that due to the nature of the WRDATA signal, you will NOT get a change for each bit cell. So some form of phase locked SPI clock generator is required. You could do that with a real PLL (such as the CD4046) but this is analog / mixed signal design which is not well suited for your plugboard. 

(Disclaimer: 25 years ago I have designed CMOS ICs for plesiochronous fiber optical communications systems with clock speeds up to 3.125 GHz - data rates in the optical fiber were of course much higher - and have some patents on the special circuit solutions and sampling phase control to deal with very small "eye" openings in the communication channel. Just mentioning that I see this problem in the floppy emu as sort of child's play for bloody beginners ... not implying that 'VIBR' is one of those, as he might be a communications electronics engineer, but the problem with the plesiochronous nature of the system at hand is there and cannot be ignored. And also be assured that there is absolutely no way to make the problem go away 100% unless the ST32 clock is phase locked to the Apple II motherboard clock.... but as mentioned, this needs a signal not available on the 20 pin cable, so a robust alternate solution must be sought, and the WRDATA signal is the only way to do that.)  

- Uncle Bernie

TMAP Chunk

The ‘TMAP’ chunk contains a track map. This allows you to map physical drive tracks with the track data contained within the image file ‘TRKS’ chunk. This system is used because, on a 5.25 drive, the physical drive head is larger than the width of the written track and so the track is also visible from neighboring quarter tracks. For example, the data of track 1.00 is actually visible while reading from track 0.75 or 1.25. Instead of storing copies of track data for every possible quarter track, we use the map to point multiple quarter tracks to a single track image.

Track	0.00	0.25	0.50	0.75	1.00	1.25	1.50	1.75	2.00	2.25	2.50	2.75	3.00
Maps	00	00	FF	01	01	01	FF	02	02	02	FF	03	03

The data of the ‘TMAP’ chunk begins at byte 88 of the file and is 160 bytes long.

Each map entry contains an index number for the track data contained within the ‘TRKS’ chunk. If the map entry is 0, then the correct track data to be using is the first entry in the ‘TRKS’ chunk. Any blank tracks are given a value of 255 (0xFF) in the map and the emulator should be outputting random bits in this case.

The mapping changes slightly between 5.25 and 3.5 disks. This is the format for the table for the layout of a 5.25 disk. The table only shows to track 35, but can also accommodate 40 track disks. All unused map entries should have a 255 (0xFF) value.

https://applesaucefdc.com/woz/reference2/

 

In post #58, 'VIBR' wrote:

WRDATA is inversed (74LS06) to channel 2 of the 74LS123

The 74LS123 will trigger a pulse based on WRDATA that will reset a counter (74LS393),

The counter is clock by a STM32 clock at 1Mhz (1 us) to Pin 1 CP of the Counter

Every 4 clock cycles the counter is reset (PIN 6 Q3  to PIN 2 MR ), Every 4 clock cycle SPI1 is as well clock

WRDATA is link to SPI1_MISO to gather input.

I used a schotty diode to avoid WRDATA to clock the SPI when resetting the counter 

Do I get it right ?

Uncle Bernie comments:

Almost right, with a few bugs and a few weaknesses.

1. The 74LS06 has an open collector output and would need a pullup resistor for a good 'H' signal.

2. It would be better to use a Schmitt trigger in lieu of the 74LS06, because the cable may cause poor signal integrity. The "B" inputs of the 74LS123 are Schmitt Trigger inputs. Positive edge triggered, but this is OK, as the WRDATA signal toggles for each "1" bit sent to the disk. You may connect WRDATA directly to "B".

3. Counter clock of 1 MHz seems fast enough (faster, such as 2, 4, 8 Mhz would be better to get a more accurate "hit" of the bit cell center) but the nature of this plesiochronous system must be studied to see if clock slips can happen.

4. Do not reset the counter with itself, let it just roll over 11111111->00000000, which will only happen if there are no WRDATA changes for a longer time, which means that the write mode is off anyways (do not use this clock source for read mode)

5. A bit cell is 4us wide, so for reaching the middle of the bit cell, two 1 Mhz clocks are needed. Here is how the counter would react:

0000 Reset state (WRDATA rising edge causing a short (i.e. 50ns) aysnchronous reset pulse of counter.

0001 1us later

0010 2 us later (half bit cell)

0011 3 us later

0100 4 us later (end bit cell, start new bit cell)

0101 5 us later

0110 6 us later (half bit cell)

0111 7 us later

So you would use the rising edge of Q1 (the 2nd bit) to clock your SPI.

The 1N4148 protection diode on the 74LS123 is not needed, as advertised in the datasheet. Earlier oneshots needed it only for larger capacitors. You should also check your timing components to have more realistic values. Look at Figure 4 of the 74LS123 datasheet which can be downloaded from the TI website. You do not want a reset pulse which is too wide, aim for something below 500ns, and more than what the 74LS393 needs as a minimum clear pulse width.  Try 47pF and 10 kOhm (from the chart). The C should be large enough to swamp the parasitics on the Cext pins and traces (keep them as short as possible, plugboard NOT recommended, but if you insist to use it, you could lift the pins by bending them and solder the 47pF to them) and the R should be larger than 5 kOhm. You should get something around 250ns pulse width from that, but be aware that the chart in the datasheet is for "typical" silicon, and your results may vary. Do not try to use smaller capacitors. Instead, change the resistor to get your target pulse width.

The Apple II Q3 clock is 14.31818 MHz / 7 = 2.04 MHz, so the bit cells will come in faster than your 1 Mhz clock advances the counter. Each bit cell is 8 Q3 clocks, or 3.91 us wide. The error per bit cell is 89ns, so after 4 bit cells with no WRDATA rising edge (which should never happen in normal DISK II operation outside of writing copyprotection trickery) the accumulated error is 355ns, and so the SPI clock will still be only off from bit cell center by this amount, which is harmless.

Keep in mind that this system only captures the WRDATA stream and you need to detect the bit changes (compared to the previous bit) to arrive at the bit cells with a "1" in them. If you can do that in software, fine. Doing it in hardware would be easier for the software, but would cost more ICs.

- Uncle Bernie

- no need to add a 74LS14 if you use the B input of the 74123. Which already IS a Schmitt Trigger input.

- 2 MHz clock and use of the next higher Q output of the counter indeed would make the whole system more robust

- to detect a signal change on WRDATA with external logic, you need a flipflop to capture the "old" state of WRDATA and then a XNOR gate to compare that old state with the current WRDATA. You can use a XOR an the /Q of the flipflop to the same effect. Clock the flipflop with the inverted SPI clock coming from the counter  (such that the output of the XOR = SPI input does not change in the vicinity of the active SPI clock edge). You may need a second flipflop after the XOR ... with the same clock, to prevent WRDATA changes spitting into the soup. Once you have built the hardware, you will see what is needed and what not.

For tracing writes, you need another track buffer which is for this "write" SPI channel. You will need some gating of the SPI input signal with WRREQ to receive only '0' bytes when nothing is written. WRDATA will toggle erratically even if WRREQ is off. Where it gets tricky is when WRREQ is turned off. You need to hurry and copy the written bytes to the "real" track buffer at the correct positions of that track. Again, the always running timer which corresponds to the revolving floppy disk is your friend here, to determine where the write was started and where it stopped (interrupt or timer capture by WRREQ changes ?).

What happens during writes is that the RWTS software looks for the correct sector header which it reads from the "read" track. Once the correct header is found, it will turn on the WRREQ and write the sector data including a leader and a trailer. You do not need to worry about deciphering any of that, it's just a bit cell stream like any other. But for testing purposes, you may put some backdoor into your ST32 code to be able to access the write track buffer ... and this debugging ability is why I recommend a separate write track buffer. Theoretically, you could watch WRREQ and then reconfigure peripherals in the ST32 to write directly into the read track buffer at the right place. But if anything goes wrong with this, your read track buffer contents may get ruined and the sector headers may be gone, and everything falls apart. Hence, keep it simple. Have  a separate write track buffer with its own DMA channel.

Note that none of the known copyprotections using "fat tracks" or "spiral tracks" ever writes into these special  tracks, and only these need more track buffers to be kept in memory at the same time. For normal read / write operations, you just need two track buffers, one for reading, one for writing, and once you have debugged the writing process, you might be able to combine them into one track buffer. But even I would not dare to try to pull this feat off before the process works with the two buffers. There are just too many plates spinning (nice metaphor for floppy emulator work ...), too many moving parts, so the "divide and conquer" approach is probably the better one.

For the testing of copy protections I can't give any specific advice. In the end it boils down to finding WOZ files, and then testing, testing, testing ... the BMOW Floppy Emu IMHO is the most mature product of this type out there, and certainly worth its money (I wonder how Steve can do that at this low price). But at least for my own mission (integrating a floppy emu into the Replica IIe project) his floppy emu is too elaborate and too powerful, and hence, too expensive to put into my planned kits. It's just a BOM problem. More parts cost more money to buy and to install. On-motherboard floppy emus could avoid a lot of these parts, i.e. the little display could be gone, and all the buttons, and could be replaced with some built-in software running on the 6502. You could start this from the keyboard and then choose a set of disks you want to emulate from a menu provided by the ST32. The display would be the normal Apple II screen. For a given game, there will be a number of disks and sides (1A, 1B, 2, ...) and these could be displayed on a single digit 7-segment display and two LEDs for the side (A or B). The keyboard would "talk" to the ST32 and allow to choose which of them. If you want to change to another game, you neeed to reboot the Apple II anyways. I think such simplifications could bring number of hardware components and costs down. But these simplifications of course are not possible with any stand-alone floppy emu like the BMOW one. It must have the display, the buttons, the acrylic case, the flat band cable, and all these components cost money and drive costs. Frankly, I don't think you can make a lower cost stand alone floppy emu than the BMOW. But when a floppy emu gets integrated on a Replica 2e motherboard, your ST32 based version sure can save some components and some costs. This ST32 could also handle the keyboard and mouse interface conversion (to be able to use industry standard PS/2 keyboards and mice, and maybe USB ones, too). At the moment I'm only 'dreaming' about synergistic effects but I will watch your project for progress !

Good luck !

- Uncle Bernie

Hi Vincent -

to answer your questions in your post #64:

1. Get the timing RC of U2A right. Datasheet demands R >= 5kOhm. Suggest to start with 10 kOhm / 330pF and then adjust R for desired pulse width.

2. Remove 1N4148 diodes at the oneshots. These are NOT needed for the 74123. The 74121 and 122 need them but only for larger capacitors having much charge inside.

3. Check timing requirements for the CLR input of the 1st oneshot (U2A). I can't tell because I don't know how TIM3 works.

4. The write protect pulldown is too weak. You may ground that signal to turn write protect off. But I think it might be worthwhile to dedicate an output of the ST32 to drive it. This allows choice of write protect from the emulator or the WOZ file. I don't know if the following foul "copy protection" method I saw on the Atari maybe 42+ years ago ever was used on the Apple:

in this protection, the original disk had no notches so it was write protected. But a copy, since it was written by the "software pirate" had to have a notch to allow writing. The "copy protection" would detect the absence of the write protect after booting it, and clandestinely wrote trash to a sector needed later in the game. The "software pirate" of course would see the early stages of the game running fine and declare victory and send the copies out to his pirate friends. (Ouch). I would call this a "poison pill copy protection". One of the very simple ways to protect a floppy disk without any copy protection formatting. Once the "scene" learned about this, added manual write protect turn on / turn off switches were put in. The most elaborate ones hat three positions, PROTECT, NORMAL, UNPROTECT. The middle one would take the signal from the write protect sensor, and the other two would override it. The same mechanism could be put into your floppy emu.

5. Suggested WR channel circuit here:

WR_channel.jpg

Note that I changed it a little bit over your circuit and my previous suggestion. Now, both D-FFs are clocked by the mid-bitcell clock Q2 made by the 74393, and the EOR output will go '1' for each change on WRDATA detected. This information is held in the 2nd D-FF until the next bit cell clock. Consequentially, the SPI now must be clocked by the inverted Q2 (or programmed to grab the data on SPI data input at a negative edge, if that is possible). This clocking scheme avoids issues with SPI setup and hold time violations. I've also added a function where WRREQ will keep the SPI input "0", if WRREQ is deasserted ("H", it is actually active "L", to enable write, but Apple's schematics often have no inversion bar over the signal name). You also need to use WRREQ based interrupts to handle the write operation turn on and turn off, but this little CLR circuit is faster and will turn all 'trailer' bit cells after WRREQ deassertion to zero bits in the write track buffer.

I did not simulate or test this circuit, so no guarantees of any kind given or implied. But I think it should work OK.

Depending on which clock(s) you can generate with the ST32, all the logic could be put into a single small PLD, such as a 16R6 or so. This would do away with the nasty oneshots and make your floppy emu not only cheaper to own, but also more bulletproof to build one without having an oscilloscope to check the oneshots. Can you make a ~2 MHz clock ?

You also may have noticed that some copy protections require different bit cell densities. It may be worthwhile to check if the SPI clocks in the ST32 can be programmed to such a fine resolution. But this is not mandatory. The effect of different bit cell densities can also be faked in the WOZ file by manipulating the bit sequence. This is because the DISK II controller's "Woz Machine" always samples the RDDATA stream at the Q3 clock frequency and it has no PLL.  So knowing what the "Woz Machine" does could be used to get the same effects  (seen by the copyprotection check) as if there were a "density frequency modulation" on the floppy disk itself. But this is my conjecture ... I don't know what the various existing floppy disk emulators do. All I know - and only from the "Tome" book - is that some Apple II copy protections use different bit cell densities and the check counts the CPU cycles needed to read certain portions of the track. I do not have any such original disk in my collection to verify any of that. But from knowing how the RDDATA stream gets sampled at a fixed frequency, a bit stream at another frequency can be constructed which has the same effect (back to "plesiochronous systems"). There will be a clock slip effect from time to time. The question is how the copyprotection nit-picks about the details it "sees". The real floppy disk will have a slight timing jitter for the clock slip event to happen, and this could be used to construct 'instable' bits which sometimes register as a "0" and sometimes as a "1". I don't know if they exploited that and how the WOZ file would handle that properly. This is for the "Apple II copyprotection experts" on the lofty "Applesauce" level or higher ranks. And I don't belong there ... different type of expertise. I just wanted to alert you that these things / tricks may or may not exist.

Tell us about your progress with the write process !

- Uncle Bernie

Check if your DISK II controller is still oprational for writing with a physical DISK II drive with a diskette inside. Check that this setup is still operational when you add your "emulator" to the DRIVE 2 connector of the controller card.

Still you haven't done the tests I proposed. 

I remember of an old simple emualtor based on Atmel that explicitly did not support "diskette" formatting. But writing on a formatted "diskette" was working with it. You can try to see how Locksmith 6.0 Fast backup tries to write to your "emulator".  I am inlcined to think that a very short WRREQ single attempt is made which is not within the logging scope of your logical analyzer. This attempt is sufficient to dislike your "emulator" and signal an I/O ERROR.

You cannot expect any newdata when " LS74_CLK2 is L". Only on the rising edge of the clock pulse (e.g. for the shortest moment when the clock signal changes from 0 to 1) the '74 memorizes the logical state of its D input. During the rest of the time (e.g. the majority of time) it is idle and simply ignores all changes that happen on the D pin.

Either for some setup reason your logic analyzer is not showing/missing short pulses/glitches, or the wiring is bad, or the 74LS74 is defective, or you have unintentionally connected the logic analyzer to different signals. But your clock must be dependent on the WRDATA as far as I understood but instead the clock is absolutely regular?..

I was writing about all signals, not only one. Looking at your breadboard setup one can never be sure for connections. I advise you to use soldering instead.

VIBR wrote:

The role of the LS123_5_Q to reset the LS393, is because it is not automatically auto rolling to 0 after 15 steps ? 

No. 

Hi Vincent -

to answer your question in your post #67, here are my comments based on the schematic there. The thread now has progressed to 91 posts, so I'm late, but I will also inspect your schematic in post #91 in due time. Here my hints for the schematic in post #67:

C1 should be pF, not nF

Use 74LS14 in lieu of 74LS06, as you want Schmitt Triggers to condition all the signals coming from the flat band cable. This also saves the pullup resistors.

The WRDATA to the 74LS74 change detector should come from a Schmitt Trigger, too. Polarity does not matter, as it's a change detector.

Also, avoid high resistance pull down or pull ups (some in your schematic have 100k). Instead, size their resistance such that they can make good TTL "L" or "H" levels for any expected LSTTL load in these nodes. This may look as an superflous effort, but why not ... if you put resistors in at all, why not maximize their usefulness. You never what you or other people later want to wire to these nodes.

Don't use the 10k series resistors on switches. Instead, use pullup resistors such that the switch grounds them and has to draw current (some single digit mA) to establish a "L" level. This allows for easy detection of failing switches whose contacts got too high ohmic due to corrosion, wear and tear, especially if you could measure the logic level with an ADC. For some types of switch contacts, having a few mA of "working current" may also be beneficial to maximize their life time.

One word of caution on 5V tolerance: I've downloaded the ST32 datasheet but so far had no time to digest it. You need to exercise some care about the alleged "5V" tolerance they promise for the ST32 I/O ports on the front page of the datasheet. The key question to be answered is whether this 5V tolerance also exists when the ST32 has no power supply voltages, or insufficient power supply voltages to make the inner circuitry work as expected.

I know, I know, as an IC designer, that 5V tolerance under all conditions is possible with some process technologies, and very careful and competent circuit and layout design, but I've blown up enough CMOS ICs whose manufacturers made bold claims as to their latch-up robustness: for instance, Lattice claimed for their first mid Y1980's GAL16V8 that they would "not latch up under any condition". This bold claim disappeared from later data books. And I had to redesign one of my products whose GALs blew up all too often in the field. The issue was that their substrate charge pump which was meant to accomplish this robustness needed a power supply to work its "magic", and of course hot-socketing of the PCB could blow those GALs up before the charge pump had pumped the substrate down. Much the same mayhem could be wrought with the first CMOS based DRAMs. All of which used substrate charge pumps to avoid the negative power supply pins. One negative voltage spike on any of their pins caused by transmission line effects (reflections) during or shortly after power up (before the charge pumps could complete their job) could blow these ICs up. And of course the power supplies of these DRAM banks were powerful enough to make them smoke, once the latched-up condition was established. The bottom line is that all claims from any manufacturerer as to the robustness of their ICs must be put under scrutiny. But ST had gained a stellar reputation for the toughness of their ST62 MCU family. If they did not lose the know-how, the ST32 may also be tough and hard to kill. Still, with the specific dangers lurking on the 20-pin flat band cable when connected to a DISK II controller card, we should probably add some protection circuits to avoid blowing up the floppy emu when the cable is inserted turned 180 degrees. I can help you with that, if you want.

Comments on the new schematic of post #91:

After a short glimpse on your schematic in post #91, I don't think the LS125 to gate off the WRDATA signal is a good idea. The LS125 does not have Schmitt Trigger inputs, so it's not smart to use it for conditioning signals coming from a long flat band cable.

WR_REQ deassertion clearing the 2nd D-FF in the 74LS74 is enough to keep its output low during that time (SPI will receive all '0' bytes, but the SPI clock still will run, otherwise the last byte in the pipeline before WR_REQ deassertion (ending the write) may get stuck in the SPI machinery. But I'd think you want to capture this byte, too. It's typically a trailer byte of 0xFF the RWTS sends to the floppy drive just before turning off the WR_REQ.

To handle the start and stop of the write process properly, you need an interrupt on change of WR_REQ anyways, and you need to be able to discern if the WR_REQ was asserted (active low !) or deasserted, to start or stop the write process. The reason why I suggested the 'forever running' write receiving process is that this gives you plenty of time to deal with write process start and stop without ever losing any bytes sent by the DISK II controller. The write buffer can't be made smaller anyways, because you need to be able to capture a whole track during the formatting process. Only for writing regular sectors, you could use a smaller write track buffer and start / stop DMA based on WR_REQ. But when you turn off the SPI clock (and the rest of the write channel circuitry) then you are guaranteed to lose a few bytes in the beginning of any write. Typically, these are gaps involving SYNC bytes (1111111100 1111111100 ...) so you could make a guess on what you have lost, and replace them, but why if you can just keep the machinery running all the time ? It's a needless complication, IMHO. The machinery I proposed will write always into the write track buffer, even when the WR_REQ is deasserted, and the system is reading, but it will only write bytes of all zeros (0x00) as long as WR_REQ is deasserted, and this can help your software to find out what was written where.

This leads to the questions in your post #88:

It is correct that you keep the RDDATA generating process from the 'read track buffer' and the read index timer runnig all the time, including the wraparound to the begin of the track buffer when one revolution is complete. A timer interrupt could do this BEFORE the pipeline runs dry, as even a blazing fast ST32 will need some time to process the interrupt and to restart the DMA at exactly the currect point in time, without losing any byte, and without adding any byte. This would be the ideal case, a seamless rotation of the same track forever, like in the real floppy disk drive. But IMHO the timing in the software may get tricky unless you have a hardware FIFO between the DMA channel and the SPI peripheral.

Here are your questions and my comments:

A1/ When the write process start, WR_REQ gets LOW, I assume I have to save the RDDATA index, and the same at the end of the write process WR_REQ gets High ?

You can do this, as you have the interrupt reacting to the WR_REQ changes. You could also record the state of the DMA channel into the write track buffer at that time. This information will help to look for the exact positions in the write track buffer where the WR_REQ actually started and stopped. You certainly have some latency in the interrupt process so you need to go "looking" for the all zero bytes before and after the actually written bytes which were moved into the buffer automatically (by SPI and DMA). What I think you can get from the typical peripherals is an approximate position and the fine positioning must be done by looking at the bytes being all zeros (WR REQ was off, or the place never was written) or non zero bytes (something was written there). 

A2/ I record the WRDATA from the incoming SPI when WR_REQ gets LOW and I stop when WR_REQ gets High ?

Actually, as discussed above, your WR_REQ interrupt process most likely would be too slow to capture the whole story. So it's better to keep the machinery running all the time.

B/ I copy the WRDATA to the RDDATA at the begining of the index (A/). ?

No. At least after each WR_REQ deassertion, you need to look for what was written into the write track buffer, and then copy the non-zero bytes there into the right positions of the read track buffer (which is the actual image of the emulated track). This must happen fast enough such that when the RWTS starts to look for what it just wrote, that the data must be updated and ready. Even for a ST32 this may be too much to handle in the time available. So I would recommend that after WR_REQ has been asserted, start copying the information from the write track buffer into the read track buffer, which can be done with a background process. Do not forget to set the position of any non-zero byte you took out from the write buffer in this copy process to zero, so mark it as "taken / fresh / empty space". I think this process will work fine with plenty of time for regular sector writes. But for a full track formatting process it still might be too slow, I can't say, as I don't write the software. So you might detect a track formatting process and then just flip the read and write buffers once the WR_REQ is deasserted. You still need to clear the new write buffer to all zeros before the next write happens.

If space left from the index is not enough I copy the remaining part at the begining of the buffer.

If you can't close the 'ring' by manipulating DMA in due time, to restart at the begin of the write buffer upon completion of a revolution, you need to allow the DMA to overshoot the buffer end a little bit (have enough spare bytes there) and you restart the DMA past the begin of the buffer. While the write process commences there automatically (by SPI/DMA interaction) your software can figure out how to 'heal' the wraparound splice by copying appropriate bytes from the overrun area to the beginning of the buffer. Let me emphasize again that you can't lose or add even one byte in the process, except for all zero bytes, which indicate that at this part of the track buffer, WR_REQ was deasserted and write was turned off. Oh, and forget about notions of "index". The Apple II disk system has no index hole sensor, so there is no "index". The tracks can start and stop anywhere. But some copy protections check for the relative angle between tracks, so this must be accounted for.

C/ I copy the track to the SDCard ?

Once a track has been written to, mark it as 'dirty'. Only when the head moves away from that track, initiate the flush to SD card process for that dirty track (you now can see why having a pool of track buffers is helpful, if you have them, you can allocate and deallocate track buffers very quickly. Having a lot of RAM is your friend...)

So far my comments / suggestions. Hope they get you back on the right track (no pun intended ;-)

You are making good progress.

- Uncle Bernie

VIBR wrote:

- If you erase the full track using LockSmith, then the WR_DATA will be full of 0 how to determine the right start and the right end ? 

To make your life more complicated a fully erased media track still produces read pulses due to the noise in DISK II floppy drives.

This is just an example example when using advanced contemporary technology with fast processors is not enough to make an effective realtime machine to "fool" a 40 year's old 1 MHz computer. 

Hi Vincent -

Sorry I can't respond quicker because of the way I work (no internet at home, fully intentionally, otherwise it would suck me into its "black hole" as I'm a very curious guy, and on top of that the spying by internet providers who build "personality profiles" they sell to third parties, which may include gangsters / scammers) does not allow me to respond quickly. I drive to the public library where I can get anonymous internet access, load the pages and download the stuff I need, and then take it home to digest it. The charge of my notebook  battery is limited, so this also limits the time the internet can "steal" from my RQLT per day.

An arrangement I can recommend for anyone, especially internet junkies. IMHO the internet is more addictive than Cocaine. Most of the populace are now internet zombies whose life time gets stolen by 'social media' and the like. And it's a trap for smart and curious people, too. Because the internet "knows" everything. You can discover and learn and discover more and learn more ... until you have wasted your whole life without doing anything productive, but you will think you have learned a lot... the real world is different. The "pod" allegory in the Y1999 movie "THE MATRIX" was meant as a warning. When being "plugged in", people can waste their whole life living in an illusion and never experiencing the real world. Internet is TV mind control on steroids. But now back to your Floppy Emu project.

Yesterday I have downloaded the ST32 datasheet and started to read half of it. I noticed that the DMA can do ring buffers, which is a great feature. A lot of problems with the Floppy Emu coding effort go away. But still, there are some caveats:

1. It is good that the "read channel" runs all the time with perfect closing of the loop at the end of the revolution of the simulated floppy disk. The status of the DMA or a timer running in lockstep with the DMA can be used to determine where on the track we are, all the time.

2. The "write channel" running all the time is also good. But note that with the current circuitry it can't run in lockstep with the revolution of the simulated floppy disk, because once the WR_REQ is deasserted, the digital PLL (in the 74393) will lose sync soon. But as it will continue to produce SPI clocks, you will not lose the last byte, nor lose the first byte once write commences. The benefit of the digital PLL is that one active edge on WRDATA is enough to get it perfectly in lockstep with the DISK II controller. Note that due to the plesiochronous nature of the system, the phase will vary due to the clock frequency difference, but it will be restored on every acive WRDATA edge detected by the 74LS123 oneshot.

The consequence of this is twofold:

- First, you need to take the position information for any data write event (WR_REQ gets asserted) from the read channel, and not from the write channel. But with the interrupt routine for WR_REQ falling (getting asserted, write starts) you also need to grab the position information where the DMA is in the write track buffer, to later find the chunk of data that was written, and to copy it to the read track buffer at the position there.

- Second, since the write channel runs all the time, even when WR_REQ gets deasserted, the write track buffer will be overwritten with all zeros even when the DISK II system is reading from the read track buffer. This is not a bug. It's a feature that is inevitabe if you want to avoid losing write data due to write channel startup and stop events and their latency. What you need to do with any written data is to copy it into the read track buffer as soon as possible. No DMA channel needed for that. The ST32 is fast enough.

What I recommend for the debugging phase is that you don't do the copy yet but use the WR_REQ change interrupt for the deassertion (write ended) case to turn off the wite channel DMA. Then read all the relevant information (read track buffer, write track buffer, position information) into a host system and analyze what you got. Then figure out algorithms to do the fine positioning of pointers to the written data (source) and into the read data buffer (where it belongs and shall be copied). The state of the DMA you grabbed when WR_REQ was asserted will help to find these locations in memory but due to the latency in the system some adjustment by smart algorithms may be necessary. Finding the write data chunk is easy (it begins with a trail of zero bytes and ends with a trail of zero bytes) but finding out where it shall be copied into the read track buffer may be more tricky ... the algorithm most likely must search backwards in the read buffer to find where the sector's gaps and data fields start. I can't tell no more as I don't know the latency of the DMA / FIFO / SPI data path. But the offset you will find should be fairly consistent. If that fails we need to add some more hardware do deal with the situation.

When LOCKSMITH produces an all zero write track buffer, you did not copy the data the DMA put into it in due time, so it was overwritten. But during the debugging phase you sure could use a WR_REQ desassertion interrupt to kill the DMA which will preserve the buffer contents for analysis.

Note that keeping the write channel DMA running all the time is not mandatory. You could use a delayed turn-off after WR_REQ is deasserted even in the final system. But then you run into the problem with starting the DMA up quickly again at the next WR_REQ assertion. What ws the value of the bytes you have lost due to that startup latency ? (See the reason why I'd like to have it running all the time).

What I would do if I was the developer of that floppy emu software would be to figure out the proper way to write single sectors first. Not formatting yet. You start with a formatted image. The topic of how the floppy emu should handle the formatting of a track (and LOCKSMITH etc.) comes later. It may entail a completely different approach in handling the track buffers.

So far my comment on the software development.

Did not inspect your new schematic yet, but the first thing I saw is that the WRDATA signal to the change detector should come from the output of the 74LS14 Schmitt Trigger. Polarity does not matter, so one Schmitt Trigger inverter shall do.

There is more about the hardware, I think the ST32 is not 5V tolerant under all conditions, as I suspected in some posts above. Here is what I found in the datasheet:

Table 11 on page 57 tells the truth about their "5V tolerance". As I suspected, it does not exist when the power supply VDD is turned off. The FT pins are specified for VDD + 4.0V, so VDD must be 1V minimum for 5V tolerance. What's worse is the VSS-0.3V spec for all pins, with a max. injected current of -5mA. This means if a pin goes negative and more than 5 mA is pulled out while doing so, the IC exceeds absolute maximum ratings and bad things can happen (permanent damage / blowing up / smoke). They claim that positive injection is not possible if the max voltage on the pin is not exceeded (this is supposed to be the VDD+4V limit). Would be interesting to test what happens if that voltage limit is exceeded (remember, the 20pin floppy disk cable has +12V and -12V on it, and bad things can happen if these 24V can find a sneak path to zap things).

Overall the picture is not bad, though. Some protection cicuits and current limiting resistors at appropriate places can take care of all the possible mishaps. The worst of which probably is inserting the floppy disk cable turned 180 degrees, but plugging it in offset by one or more pins also needs to be addressed. This sounds silly but it happens more often than you would think. Mountains of dead DISK II floppy disk drives and piles of zapped IWMs give testimony of these crimes against innocent hardware. Sure, the connectors on original Apple hardware were mostly keyed but alas, human ham fisted hands can excert enough force to make wrong connections possible even with keyed conenctors. Another cuplrit are the Taiwanese clone DISK II controller cards which rarely had keyed connectors. There also are lots of third party flat band cable assemblies with a type of press-on connector that can be plugged into the pin headers with an offset. The more foolproof type of these connectors have a plastic body which is wide enough to interfere with pins of the header, theoretically preventing offset insertion, but with enough applied brute force the end pins of the pin header will just be bent out of the way and the connector will mate on all remaining pins in an offset way. None of that is user friendly / foolproof. So for any "kit", proper choice of connectors is mandatory. But this does not help if the floppy emu cable is plugged into a Taiwanese DISK II card clone which allows plugging in the cable in a wrong way.

- Uncle Bernie

VIBR wrote:

 I have teenagers under my roof ... 

I think we have the same approach on the software part, and yes the STM32 is a marvel of engineering.  

I thought you were a teenager who is doing his first steps in electronics... The STM is just one of the thousand ARM implementations polluting the IC market now, nothing more. 

The idea of the XOR is to get 1 on pin 9 of the '74 when WRDATA changes and 0 if no change occured from previous COUT clock rising edge.

VIBR wrote:

Ok thanks for your pleasant comment... 

regarding the change if WRDATA this I got, what I do not got is why do we track change and not the data itself ?

No, you did not get the XOR meaning, at least be honest. Now for the next question  -- refer to figure 9.6 in Jim Sather's book Understanding the Apple II and read (again?) message #39 in this topic.  When WRDATA signal changes logical state 1 is written on the diskette, lack of  WRDATA change means 0 is written.