Apple II DISK Emulator using STM32

For DOS you could try Bag of Tricks. Or with ProDOS use Blockwarden.

In post #1, 'VIBR' wrote:

" I am almost done with the prototype, but I need to debug a bit what the Apple II is getting from the stm32. "

Uncle Bernie comments:

The 'acid test' for any Apple II floppy emu are the WOZ files (more specific, the WOZ 2+ types). This is because WOZ files demand faithful reproduction of relatively complicated copy protection formats, which of course will, at times, violate DISK II GCR and formatting rules to create the desired effect. In which proper timing of all the RDDATA pulses is critical.

The task is complicated by the fact that some games do not tell you if 'higher stage' copy protection checks have failed. Instead, they subtly change the gameplay parameters such that the player can't win. For instance, in "Prince of Persia", a copy protection fail will turn the content of a vial the avatar must drink to win into poison. Typically, these staged copy protections will do a simpler check while loading and will fail the load when something is grossly off or the copy protection is missing completely (naiive copy without proper tools).  But the higher stages will check the copy protection for more subtle details and won't tell you anymore if the check fails.

This said, a thorough test of your emulator will be extremely time consuming and tax your game playing skills...

So the solution I suggest is to work without your hardware first. Instead, build a faithful, cycle accurate "C" model of your emulation code which you then plug into one of the open source Apple II emulators which support 'WOZ' files. Your "C" model will "look" at the control signals of the 74LS259 addressa ble latch of the DISK II emulation code of the emulator and it will have its own access to the WOZ file. Implement a compare of the RDDATA streams of your "C' model and of the emulator. All you need to do then is to find WOZ files on the web and load them into that emulator. Any difference in the RDDATA streams (after being synchronized with the Q3 clock) means your emulation of the floppy disk read process is not yet perfect. The emulation of the floppy disk write process is easier because there are less timing ambiguities involved (vs. the read process). You can do a digital PLL locking to the changes of the WRDATA stream to get the individual bit cells.

For which games to try, look at the various threads concerning the development of MMU substitutes.

I use similar techniques for all my reverse engineering and MMU, IOU and IWM substitutes development work. For instance, at the moment I have "C" models - which are almost "RTL" - running in lockstep with a real IWM interfaced to the printer port of a notebook computer.  Some 10 million simulated clock cycles later (which have about 20 minutes runtime) the software tells me about mismatches, timing discrepancies, and produces charts telling me which transitions were taken in all the state machines involved (actually, there are automatic checks to report transitions never taken, which means the input vectors are not exercising all functionalities).

I'm not tempted to go to a hardware implementation before I have full confidence that the models match the real IWM. And with your work you are in the same situation. Unless you have 100% match of a software model of your floppy disk emulator with what others have implemented in Apple II emulators it is just a waste of time to go to experiments with real hardware. You will not get anywhere in any useful amount of time. But if you go the path I have shown to you, you can leverage many, many man-years of work from very skilled and experienced developers who implemented the WOZ file based floppy disk emulation in these open source Apple II emulators. All this is NOT trivial and any small mistake and oversight you might have in your ST32 code may cause a lot of trouble (and loss of your time) down the road. But if you can prove that your model matches the proven work of the "experts" in Apple II copy protection emulation, they you can achieve a truly stellar product with your floppy emulator.

- Uncle Bernie

VIBR wrote:

I suspect the double buffering is doing something wrong when head move is happening:  - I prepare in advance the next file sector to be sent, - When head move signal is received I finished the next sector sending and I prepare the new track / disk sector.

 I assume the Disk controller is expecting straight away the next disk / sector. 

The disk controller does not care abot tracks and sectors, these all (except for boot sector) are detected under software control. When head moves to another track the software waits (if no protection involved) decent amount of time that shoud include the head movement time to the new track and mechanical stabilization time at this new track and then starts to pay attention to the data stream that comes from the floppy drive. During the head movement the data received from the drive is garbage/noise. Head movement is much slower than one sector time especially of head carret should travel between tracks 0 and 35. Look for your problem elsewhere.

You should place a whole track (with necessary preprocessing) in the DMA circular buffer. You do not have to care about sectors. 

If you split it your emulator is doomed to be buggy and faulty. Try to find another solution. If you want to stick with the same STM I would have chosen 4 times less DMA/SPI clock, e.g. buffer, and on positive edge of its output you could form a roughly 1uS pulses by external circuitry (monovibrator, RC + rectifier + TTL buffer, etc.). Also read about WOZ format and try to implement it in the first place.

In post #7, 'VIBR' wrote:

" While sending it is preparing the next sector to be sent. It means that while head move, the program will continue to finish the current sector and the next one before moving to the next track and this is where I might have an issue. "

Uncle Bernie comments:

This approach won't work. Many Apple II copy protections move the head while continuing to read. One example is "spiral tracks". Your floppy emu must be able to handle this properly. To do this it must know if it is a 'spiral track' or a 'fat track' protection. AFAIK, only a WOZ file has all the relevant information inside. But I never looked at DSK file contents ... DSK is obsolete since WOZ came out.

In no case you should need a 20 kByte circular buffer. You don't need 4us spaced pulses with RAM wasting "empty" space in between, because the DISK II controller only looks at falling transitions of RDDATA which mean a "1" bit in the DSK or WOZ files. You could use a few gates on SPI's data and clock to make these falling transitions and then extend them in duration / pulse width as required. Look at the DISK II controller card schematic, it's the inverted (NAND gated) 2 MHz Q3 clock which clocks two D-FFs which synchonize the RDDATA and another NAND detects the falling transitions. As long as you get the timing right you could just turn each "1" of the SPI into a "101"  where the "0" is the negative pulse which is wider than a Q3 clock period, so the DFF can "see" the "0".

In this scheme you don't need to expand the few (< 6000) disk bytes per track into larger buffer contents. You could use them directly and so you could keep three adjacent tracks in the ST32 RAM, to support all the different "moving head while reading" copy protections. You need to keep these buffers updated BEFORE the stepper motor phases change...

There is one issue left ... instable bits. WOZ files support that. What this means is that for each revolution of the simulated floppy disk, you need to toggle specific bits in the buffer to produce the desired effect. But this is trivial to do.

I never said it would be easy. But I think you can do it. Using the STM32 seems to be a smart choice. Apple II copy protection emulation is much simpler than for any other floppy disk system, because there is no real PLL in the DISK II. We can be grateful to Woz to have simplified the concept to the bare bones. If he had used a real PLL (like the Western Digital floppy disk controllers of the 1980s do) there would be a whole Universe of very tricky, very difficult to emulate copy protection such as frequency density modulation, PLL pull-off, etc., all techniques which to me look eerily similar to electronic warfare techniques like "range gate pull off" or "velocity gate pull off" in typical late 1950s and early 1960s ECM systems which were meant to protect military airplanes against being shot down by SA-2 missiles over Vietnam or other hotspots. (We can really think that the "copyprotection wars" of the 1980s were a sort of electronic warfare following the pattern ECM, ECCM, ECCCM ... except the casualties were not people but companies whose copy protections failed to protect their software against "software pirates" ... but the truth was that these failed companies were just too cheap to buy the best protections available. I myself had developed one which was undefeatable without immense hardware investment but no takers ...)

- Uncle Bernie

P.S.: Recently, I made a thread here on Applefitter about the "tome" of Apple II copy protections:

https://www.applefritter.com/content/found-great-book-apple-ii-copyprotections-explained

It might help you with your mission ...

In post #13, 'VIBR' wrote:

" Question 1 : using WOZ do I need to encode to GCR 6x2 ?"

" Question 2 : Having in // 3 adjacent track (The selected one + the one before and the one after), assuming that the GCR buffer is 408 Bytes, I need 3 x 408* 16 which gives 19584. "

Uncle Bernie comments:

You actually do not need to encode or decode anything. Just treat the whole track data from the WOZ file as a sequences of bits, one bit per bit cell (of 4 us) and move that bit stream out by SPI at a rate of 4us per bit. You need to do something to "wrap around" the DMA to the beginning of the track buffer once a complete revolution of the simulated floppy disk has happened. There must be no gap / pause in the bit stream. I don't know how the ST32 does DMA and SPI but I did use the ST62 family many decades ago. Which had no DMA, but a SPI peripheral which would put the SDO and SCK on two pins. I think with just one TTL package you could do some logic which makes a brief, say 1.2us to 2us wide (not critical as long as > 1us) '1' pulse on RDDATA for each '1' being shifted out by the SPI peripheral. You could use one 74xx121, 74xx122 or 74x123 oneshot to do that. All you really need to do is to turn each '1' seen in the SDO to a short negative going pulse on RDDATA, and because a string of 1's i.e. '111' needs to make three pulses, you need the SPI clock information on a pin to do that. But internally of the ST32 you just would need one byte of RAM per disk 'nybble'. Which contains GCR but you better ignore this fact to avoid confusion and extra work ;-)

In other words, do not try to decipher anything in the bit stream. Just load it into your track buffers and pump it out by SPI, and it will work.

If you don't follow that advice and try to work on a GCR level then it will get needlessly complicated.

This also preempts your question Q2. While the RWTS code running on the Apple II needs more extra RAM space than 256 bytes per sector, to be able to put the GCR together and translate it back to unencoded bytes, all this is completely irrelevant for a floppy emu 'track level' functionality. Because if you do it right, you NEVER try to understand GCR and NEVER try to encode/decode the bit streams you are dealing with. Because this is  formatting  which is better dealt with on a RWTS level, meaning in the Apple II itself. It won't work with most copyprotection methods anyways because these do not follow Apple's formatting rules (otherwise DOS 3.3 could copy such  'copyprotected' disk).

What a floppy emu must do is to just stupidly provide the bit cell streams for each track even when the 'head' is being moved. Since even the ST32 is too slow to load a track buffer upon detection of a head move, you need to work preemptively and for each active track currently being read, preload the track buffers for the adjacent tracks - the WOZ file will tell you about the nature of these tracks (normal, spiral, fat) and whether they are normal, half or quarter track spaced. I'm not too much of an Apple II copyprotection expert as I was in some 'other' camp when the 1980s "copyprotection wars" were raging, but I'd think that any head movement over a larger distance (to a really different track with different contents) could be accomplished AFTER learning that the stepping motor phases have changed. Because this inevitably means that the floppy controller will lose sync and needs to reacquire sync once the head has settled on that new track. But for small head movements to the next quarter or half track you need to have the 'foresight' as this could produce a continous RDDATA stream despite of the head being moved (spiral track and fat track protections do that).

As for writing to the floppy emu, once the write gate signal comes, you need to grab the bit stream coming from the DISK II controller and put it into the track buffer at that point in time. You can ignore the splices (no extra code) as long as you react to the write gate being turned off quickly (use interrupt).

One issue you will inevitably see when you implement write mode is 'clock slip' meaning it won't work. This can only be cured of you phase lock your SPI clock to the WRDATA stream of the DISK II controller.  I don't know if the ST32 supports this internally, but it certainly supports an external SPI clock being fed to its SPI peripheral. And all you need to do this 'PLL' is a counter which gets reset for each WRDATA transition and runs at a substantially  faster clock than 2Mhz.

I don't have the number of bytes needed for such a  track buffer in my head, but it's somewhere in the WOZ file specifications. I remember that had to increase it over their initial value because some copy protections use a slightly higher flux density than the 4us. Back in the 1980's copyprotection wars this was a show stopper for most 'copy' tools until somebody figured out how to make the RPMs of the floppy drive programmable by the copy tool. In one case I remember on the Atari, they were able to squeeze 21 sectors on a track which normally held 18 sectors. The mastering machines did that by means of their programmable clock, but the 'pirates' defeated this by slowing down their spindle speeds for such tracks. And the copyprotection wars went on and on ...

If you want to support such a protection faithfully on your floppy emu, you also must be able to change the SPI clock speed in fine increments, such that the larger track buffer fits into the same revolution time period. Note that this is a weak attempt ... I can't say if it's good enough for all such protections out there. But it's a start. Mastering machines such as the FORMASTER had programmable clocks which could change along the tracks. Which was used for copy protections involving 'density frequency modulation' techniques. Which can be used to several effects. If done gently, the software could check that different sections of the track would take different times to read but all the sectors themselves (and the format) would appear to be normal. Think of a 'rubber band' being the track, with black rings written on it for the bits. You could stretch the rubber band but the information as such would stay the same. Only the bit rate seen by the FDC would go down. And this can be measured in terms of CPU cycles. If done rudely, the 'density frequency modulation' technique could produce 'instable' sectors inevitably having a CRC error, too (WDC controllers, not Apple DISK II) but the 'instable' bit pattern would not be entierly random and could be analyzed the check the authenticity of the floppy disk. I don't know if this technique has ever been used in the Apple II, but I think it's possible to use that technique to insert or delete one (or more) bits in the bit stream in a defined region of the track. The actual position of the effect within the track read would vary depending on the RPMs and some jitter effects, but if designed properly, the bit stream before and after the effect (the 'instable' bits) could contain stable information which could be utilized for the copy protection check. Back in the 1980's copyprotection wars, we defeated this scheme by providing several incarnations of the sector in question on a track, so the copy protection check would be fooled into thinking it's genuine.

I could go on and on, but all I wanted to do is to give you some ideas on what can be done in a floppy emu using SPI and what can't be done. If you wanted a floppy emu which could do   everything   then you need to add a 'flux engine' which allows to produce arbitary read pulse distances with a very fine resolution. These things are expensive to do, even today. The cheapest solution is my 'Ratweasel' but it needs the fully processing power of a PC or notebook with a parallel printer port in ECP mode, and using DMA. The track buffer size for this exceeds the RAM of the ST32.

So my advice here is that you should not try to 'reach for the moon' and be able to do  everything   in terms of copy protections, you do not need a flux engine, just be good enough for most cases of WOZ files now in existence. I think that they still lack the support for these more elaborate schemes and whatever you will find in terms of WOZ files out there on the internet is all you need to be able to support with your ST32 SPI based floppy emu.

I'm really hoping your project will succeed because I need a 'cheap' floppy emu for my Replica 2e project. For my development work I use the BMOW Floppy Emu which I think is a great product for the price (I'm not affiliated to them, mind you, and paid the full price for the mine) but I think it's too expensive for the Replica 2e ... my price target for the whole kit including PCB is below the price of the BMOW Floppy Emu alone. And I think it should have a floppy emu on the motherboard because otherwise builders would need to find functional 5.25" 40 track floppy drives and real floppy disks and this now costs even  more  than the whole BMOW Floppy Emu does. No pun against it intended ... it's a great product, and I'm fully satisfied with it so far ... but I need a cheaper solution. Just as a price socket, the "Ratweasel" could be built for less than $10 in parts. But this means you would need a notebook computer with the required parallel printer port and ECP mode done with a compatible "Super I/O" chip inside, as I don't have the time to write drivers for every possible such notebook, and furthermore, once you have a powerful notebook like that, with all the WOZ files loaded on ts hard disk, why not also load an Apple II emulator to play these games ... no Replica 2e needed anymore !

So your new floppy emu is the only hope I have now. I wish you have success ! This is why I write so long posts in your thread. I want that you do it right and want you to succeed !

- Uncle Bernie

VIBR wrote:

Thanks UB, I will try to follow your approach and to do the right thing. 

I better understand the approach of the WOZ Bitcell, I need to check the size of a track in the exemple of woz file provided, 

If I use a circular buffer I can easily split the buffer in 2 and manage to have 3 byte buffers for the 3 adjacent track and it shoudl work. I need to do very simple math.&nb

Answers:

1.to  question 1: The head is positioned on a quarter track and will move half a track up/down.

2. to question 2: Yes, all changes should be captured. So adjust the STM not for edge but for level triggered interrupts;

3. to question 3: There are no interrupts of any kind issued by DISK II controller. During init it moves the head "past" position 0 in the track number decreasing direction and the drive's head carriage hits mechanical stop producing typical for Apple2 sound at that position many times because there is no other way to be sure the drive's head reached track 0 (no feedback sensor for that in the drive). 

Just an idea -- it would be useful if you implement a sniffing/debugging mode for the STM to passively listen and display the current track of another working DISK II drive connected to the controller.

In post #19, 'VIBR' wrote:

" Before I start to write the head move algorithm, does it exist somewhere and one I can use ?"

Uncle Bernie advises:

Your best bet is to: "use the Force and read the Source" of any capable Apple II emulator. To support floppy disk emulation from DSK and WOZ files they all need to emulate the 74LS259 addressable latch which keeps the four stepper motor phases. And then they decode these phases to determine movement of the head and to which track. You do not need to re-invent anything here. Just copy their code. But make sure it supports half and quarter tracks.

The "Tome" book also explains how these stepper motor phases work in the context of copy protections. But why reinvent the wheel ?

- Uncle Bernie 

VIBR wrote:

Ok now moving to load WOZ tracks to memory 

UB said : "You need to do something to "wrap around" the DMA to the beginning of the track buffer once a complete revolution of the simulated floppy disk has happened"

 

Can you please elaborate a bit more on Wrap around please ? 

 

Vincent

Your firmware should start outputting data from the beginning of the woz track buffer if possible ideally without any noticeable delay. 

There must be a bit counter of the current track. When a track change occurs then the outputting of the next track should start from the bit counter+1. Or, in the worst case from a bit counter+T/bittime, where T is a fixed time that your firmware needs to switch tracks. Try to keep T as short as possible. 

VIBR wrote:

Ok using 2 2DArray for direction and listing Magnet position I manage Head moves from 0 to 139 => meaning I can manage quarter track with >> 2 bit shifting.

 

 

I used to sucessfully format the 36th track: track 35 [$22] using a Disk ][.

https://forum.vcfed.org/index.php?threads/any-apple-ii-5-25-drives-do-40-tracks.76382/

Just in case you didn't find a good example for stepper motor phases to track conversion yet, look at the AppleWin-1.30.12.0 source code, file 'Disk.cpp', and search for 'magnet'. This is the last version I have downloaded, but there are newer ones, too:

https://github.com/AppleWin/AppleWin/releases

It's good that you got the "Tome" book, it will help you a lot to understand Apple II copy protections, so you can support them properly. You can download all the source code in the book from their web page, it's not easy to find where and how, and I don't remember how I did it, I just remember it took me more than a few mouse clicks to find it.

A 1us pulse width is a bit too low for guaranteed proper edge detection at a 2 Mhz clock, I recommend to use 1.3us, this will also provide guard bands for tolerances of the 74123 and the R and C on it.

The "Tome" book also has a lot of code for inspection tools inside which may help you with  diagnosing problems. I did not try them out yet (still busy with developing my IWM substitute) but sooner or later I may use these tools to debug my various floppy disk controller solutions.

I don't think you need three 6 kByte track buffers because this not how the protections were done. So far I have found no combination of spiral tracks or fat tracks with higher bit cell densities combined.  So unless you have a spiral or fat track copyprotection, one track buffer should do, because any head movement between regular tracks will cause loss of sync anyways and the whole thing gets less timing critical. But still, you need to be able to load a track buffer fairly quick when the head moves. There are copy protections which are based on "synchronized tracks" aka "skew aligned tracks", there are many names for it, and these critically depend on the RDDATA stream of the final track being there once the head stopped moving and ceased vibrating. This head settling time is in the order of several milliseconds and you don't have any more time than that to load and restart the new track buffer. So it will also depend from which type of flash card you pull your data. It may be necessary to keep pointer information for each track in the WOZ file in a small buffer, just to be able to access the data on the flash card fast enough without going through all the FAT motions.

- Uncle Bernie

A decent disk II drive emulator handling woz images should have been done with a PC's LPT port. I am still tempted.

Keep in mind that 3.5" drives use "double data rate", e.g. about 0.5uS pulses/2uS period.

In post #24, 'retro_devices' wrote:

" Your firmware should start outputting data from the beginning of the woz track buffer if possible ideally without any noticeable delay."

" There must be a bit counter of the current track. When a track change occurs then the outputting of the next track should start from the bit counter+1. Or, in the worst case from a bit counter+T/bittime, where T is a fixed time that your firmware needs to switch tracks. Try to keep T as short as possible. "

Uncle Bernie comments:

This well meant advice is wrong and confusing. What you really need is a timer within the ST32 which runs ALL THE TIME and has a prescaler setting such that it counts up and 'rolls over' to zero for each full revolution of the emulated floppy disk. Choose it such that you can easily calculate a "byte index" into your track buffer from the state of that timer. After head movement, use the timer to calculate the byte index for the position in the track buffer of the new track on which to start the DMA to the SPI.

The 'wrap around' is a tricky problem to solve. Once the bit stream reaches the end of the track buffer, the DMA must be  reloaded to continue with the position in the track where the RDDATA pattern 'closes the circle' and repeats itself. This is evident from the way the floppy disk rotates. The data stream is circular in nature. Hence, a ring buffer is what is needed. But DMA normally does not support ring buffers ... I can't give any advice there what the ST32 can and can't do. With my RATWEASEL floppy disk emulator (which is a flux engine) I have solved the problem by exploiting the FIFO in the Super I/O chips found in some notebook computers. This FIFO for the ECP mode of the parallel printer port was provided to allow software polled ECP operation without DMA. But when used with DMA, there is just enough data in the FIFO when the DMA done interrupt occurs to reload and restart the DMA controller with the beginning of the track, without causing a gap in the RDDATA stream.

I have not implemented support for WOZ files there and use synthetic flux patterns based on offline compilation of Apple II disk nybble data, so I also can't comment how to do the 'wrap around' for WOZ files properly. RATWEASEL is no floppy disk emulator (yet). But it can produce RDDATA patterns for every known copy protection, for every kind of GCR, FM and MFM modulations scheme, as long as a bit cell is not much smaller than 2 us. This is the speed limit for typical ECP ports. I did not explore that limit because it's fast enough by ECP spec for anything I do with it. I'm not interested in any higher density work. Just mentioning that to point out limits. The ST32 can't do what typical notebooks from the late 1990s / early 2000's can do in terms of storing and pumping data for a real 'flux engine'. The 'Greaseweasel', for instance, relies on fast USB to pump that data from and to a reasonably fast PC or notebook. With your approach you are limitied to 8 bit cells per byte of RAM you have, but for most Apple II floppy emulation work this should be enough, IMHO. The reason why Apple II does not really need the signal fidelity offered by a flux engine is that the DISK II controller has a fixed 2 MHz clock and no PLL. And the next reason is that unlike other computer systems of the time, Apple II had many different floppy disk drives - Apple used different manufacturers, and the clone makers did the same. This limits how "bold" or "daring" Apple II copy protections could be. A little bit of timing trickery is possible ... but this can be emulated without having a real flux engine to produce the RDDATA stream. But the analysis of such original floppy disks of course does need a flux engine. Trying to understand what is going on without having the accurate timing data on the RDDATA pulses coming off the real floppy disk is just too much guesswork. This is why the 'flow' to make WOZ files from a real copy protected floppy disk is beyond the scope of this thread. (See the 'Applesauce' project to learn more on that).  We do not want to go there, we just want a good floppy emulator that is reasonably cheap to build, and anything more sophisticated must be added by higher level manipulations of track buffer contents, and not by providing (expensive) flux engine capabilities to the floppy emu itself. Always keep this in mind. Since the 'copy protections war of the 1980s' is over, we just need to address whatever we have at hand from that time. And I'm confident that your ST32 based approach can do that. If not, we use a 4AM crack. As easy as that.

- Uncle Bernie

The signals seen in your post #32 look right to me. Not sure from memory if you should route the /Q output of the 74123 to the RDDATA line. I'm always confused with that because Apple documentation is inconsistent as to the polarity of this signal. But as far as the negative edge detector is concerned, it will work either way.

Congrats for your progress seen in your post #36. BTW, there is a reason why professional hardware designers avoid these plugboards. They always have been troublemakers. For digital work, the power supply and ground rails are too poor and the long wires (being inductors in the nano-Henry range) if used to connect VCC//GND to the ICs make matters worse. For analog work, except if it very slow / low bandwidth, the parasitics of the plugboard will conspire against any good outcome. Any kind of RF work is impossible on plugboards. And fast digital logic work, too, because it's the same laws of Physics, transmission lines, impedance matching, etc.

So what I would recommend to you is that once you have figured out how to derive a useful SPI clock from the Apple II's Q3 and WRDATA signals (needed for the emulation of write to disk operations), build another prototype on a real PCB, preferably with a ground plane, or at least really solid VCC/GND traces and plenty of power supply bypass capacitors.

I've seen so many developers strugging with instable hardware built on such plugboards, wasting time with trying to hunt down elusive gremlins, even modifying their RTL code to try to fix things ... and all that being a futile exercise and all the problems would go away by themselves when the plugboard is replaced with something better suited for the work.

Applefritter member 'frozen signal' who is working on MMU / IOU substitutes based on fast CMOS CPLDs, IMHO,  is one of those victims of plugboards. They are legion. I will not tell you all the electronics industry insider jokes about these plugboards, except for this one:

Manager walks through the company lab and notes down everyone who uses a plugboard ... to be put on the next layoff list.

Just sayin' ... I remember when these evil contraptions came out more than 50 years ago and at first they looked like a great idea to save time, so people bought them. And then discovered all the ill effects. Not only the parasitics ... contacts would wear out soon and they would scrape off tin/lead coating from component leads, and this debris would then accumulate and vagabond around inside the plugboard and cause random short circuits. And so on ... and after these lessons were learned, the plugboards were tossed where they belong, into the trash can. Half a century later the Chinese made knockoffs with even worse contact spring quality get peddled to unsuspecting hobbyists. Oh and don't get me going on those colleges and universities who force their students to build a TTL based CPU on larger plugboards. It's just stupid to do that ... unless the purpose of the mission is to make the students hunt down random contact issues.   

- Uncle Bernie

Just to speed you up on the write mode, which is not yet supported in your schematic,  here is how to do it right:

As I mentioned before, you need circuit which will generate a SPI input clock that is appropriate to capture the WRDATA bit cell stream. In the DISK II controller card, this is coming from the Q3 clock, which is ~ 2MHz (actually, 14.3181818MHz divided by 7). WRDATA may toggle every 8 Q3 clocks, but it does so only in case of a "1" bit cell. You need to capture the WRDATA bit stream in the middle of the bit cell by SPI. And I suspect even the ST32 SPI does not have the capability to do that without some external help.

What you need is a oneshot (use the second one in a 74123, the first one is for the RDDATA pulse width) and set it up such that it will generate a short pulse (longer than the minimum "asynchronous clear pulse width" of the counter you will use) for either a rising or falling edge of WRDATA. Use this pulse to clear a binary counter. Clock this counter with some clock that is derived from the ST32 clock (maybe the ST32 can generate such clock on some pin) which should be 1 MHz or more. Size the counter such that it can count at that clock for at least 4 bit cells (16 us) before it rolls over. Use one of the outputs of the counter which rises in the middle of each bit cell to clock the SPI. Data input of the SPI would be WRDATA (in the simplest case).

I think a 74xx393 could do that (it has 8 bits and an asynchronous clear input).

If you use the simple case, you need to correct the data bytes written into the track buffer, because WRDATA will change for each "1" being written, so you need to detect changes (current bit vs previous bit) to arrive at the correct 'floppy image' bit pattern. I think this can be done by a shift and EOR operation with handling the byte boundaries correctly. But I can't say if that would not turn into a kludge - you would need to somehow keep track of which bytes were written and which were not. A 2nd track buffer which is initialized to all zeros could capture the written data once the WRREQ gets asserted. After WRREQ gets deasserted, you then could look for nonzero bytes in the 2nd track buffer and correct/copy them to the 1st track buffer holding the "read" data which includes the sector headers etc. which in normal operation never should be overwritten - unless the whole track is getting formatted. The proposed method could handle that without any exceptions to be coded.

Those bytes in the 2nd track buffer which stay zero would mark those regions of the track in which the write gate never was activated. So it's quite elegant.

You could dispense with the code needed to do the correction (which is turning 'changed' bits to '1') by adding a WRDATA change detector in the external logic. Whenever WDDATA changes, you need to present a '1' to the SPI input. This can be done by capturing the old WRDATA state and compare it to the current one. You could also use a oneshot which would trigger at both the rising and the falling edge of WRDATA, and run for 3 us, so at half the bit cell time, when the SPI clock happens, the ST32 would 'see' the '1' indicating that WRDATA has changed.

All this external logic could also be put into a small PAL or GAL and with the appropriate clock you would need no oneshots, and it would support both the READ and the WRITE mode. If you want to do that, but don't have the tools, I could design such a GAL for you, just send me a PM.

Note that all operations to and from the track buffer must be governed by the timer I mentioned in some post above, which rolls over once per floppy disk revolution, and is always used to calculate byte indices into the track buffers where to start / stop operations. This timer is set up once and otherwise is left alone. So during the whole emulation session, this timer runs and runs and runs and is never reset, even when tracks are changed. This is very critical to get the timing right for all the copy protections looking for synchronized tracks. A refinement may be needed for those copy protections which use changed bit cell data rates, this may entail a change of the SPI clock frequency and a different factor to calculate the byte index from the timer. But the timer as such would never be reconfigured. It is not necessary to be hyper accurate there ... as long as you are accurate to +/-1%, for which a 8 bit timer is enough, you should be good.

(If some readers now suspect that I already have designed and built a floppy disk emulator myself, they are right, how else could I know how to do it. But this was 30 years ago and not for the Apple II, which has its own rules deviating from the "industry standard" floppy disk interface. Hence, take the above with a grain of salt ... I did my best to take the Apple II idiosyncrasies into account in this post, but can't guarantee that all the above is flawless and would work as described for Apple II floppy disk emulations).

 - Uncle Bernie

VIBR wrote:

 I see the 10 Bits signature, the D5 AA 96 prologue and so on. but I can not see that with the woz why ?

Because woz file difines the time between flux transistions (pulses). You mentioned you read and uderstood woz file specification, didn't you? It must be easier to "play" woz than other formats.

The bitstream data is the series of bits recorded from the floppy drive and normalized to 4µs intervals for 5.25 disks and 2µs for 3.5 disks. The bits are packed into bytes, but the bytes will not necessarily be representative of nibble values as timing bits are also represented within the bitstream. When processing the bitstream, the order of bits within each byte is high to low, meaning the high bit goes first and the low bit is last. Since this bitstream is the flow of data directly from the floppy drive, it will need to pass through a Logic State Sequencer as found on the Disk II Interface Card, Apple 5.25 Drive Controller Card or IWM chip to create nibbles. But, due to the fact that the bitstream timing has already been normalized, you can use a very lightweight implementation of one. The Logic State Sequencer performs the function of converting the bitstream to a nibble stream as well as enforcing the proper nibble timing that many copy protection schemes will check.

If you are creating a floppy drive emulator for use with a real Apple II, then you will simply be stepping to the next bit in the bitstream at the rate specified by the Optimal Bit Timing in the INFO chunk. If the bit has a 1 value, then you send a 1µs pulse on the RDDATA line. For a 3.5 drive, the pulse width would be 0.5µs.

If the Cleaned value of the ‘INFO’ chunk is 1, then any fake bits generated by the MC3470 during the imaging process will have been removed and replaced with 0 bit values (see the Implementation Details section for proper handling of these).

As of version 2.1 of this specification, track data may also be represented as flux timings instead of bits (see FLUX Chunk section for more info). This does not change the structure of the TRKS chunk at all, but for flux data the Bit Count is actually a byte count. The contained flux data is encoded the same way as A2R files. These flux streams are properly looped so there is no time warp when wrapping from the end of the buffer back to the beginning.

A quick explanation of the flux encoding: Each byte represents a single flux transition and its value is the number of ticks since the previous flux transition. A single tick is 125 nanoseconds. Therefore the normal 4 microsecond spacing between sequential 1 bits is represented by approximately 32 ticks. This also puts 101 and 1001 bit sequences at approximately 64 and 96 ticks. You are probably thinking to yourself that when it comes to longer runs of no transitions, how is this unsigned byte going to handle representing the time? That is taken care of via the special value of 255. When you encounter a 255, you need to keep adding the values up until you reach a byte that has a non-255 value. You then add this value to all of your accumulated 255s to give you the tick count. For example 255, 255, 10 should be treated as 255 + 255 + 10 = 520 ticks.

The full specification is here https://applesaucefdc.com/woz/reference2/

This is version 2.1 of the specs, not 2.0. You have several different disk image formats that pack data in different ways. It is the emualtor to distinguish and treat them accordingly, not the Apple2.

VIBR wrote:

OK I used a V2.0 file and I can not find the equivalent signature of the NIBBLE Inside the data of the track 

Read again the first 3 senteces of this message https://www.applefritter.com/comment/108578#comment-108578