Apple II DISK Emulator using STM32

165 posts / 0 new
Last post
Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
More comments / advice / guidance:

Hi Vincent -

 

the connection of the WRDATA to the LS74 seen in your post #97 is correct (the rule is, never work with signals coming from a longer cable without conditioning them with a Schmitt Trigger --- this will save you a lot of trouble).

 

The answer your question of post #98, the DISK II floppy drives are stripped down to the bare bones and they saved a 'toggle flipflop' there by providing the magnetic flux changes directly from the DISK II controller.

 

This means that for every "1" bit cell, the WRDATA must toggle (normal industry standard floppy disk drives expect an impulse instead).  The circuit with the first D-FF U7A and the XOR reverses this toggle process and produces a "1" for every change of WRDATA. The 2nd D-FF U7B captures this bit cell value and stores it until the next C_OUT clock. The SPI will sample the bit cell value one half C_OUT clock period later (on the negative edge of COUT, where the D-FF U7B does not change).

 

If you capture this data stream with the SPI you should see a "1" bit for every bit cell that was written as "1" to the DISK II card's shift register. You should be able to identify the SYNC bytes which are 1111111100 1111111100 ... so these are 10 bits wide and not 8 bits as a normal byte. The read process will swallow the extra "0" bits but you must keep them and later send them through the read channel, so the synchronisation process works.

 

When WR_REQ is deasserted, the U7B is kept in a clear state and this produces a stream of "0" bytes .... be aware that these will overwrite anything that was written after one emulated revolution of the floppy disk, as you have a circular DMA process.

 

This is intentional. Let me explain why:

 

The proposed method of implementing the write channel has the advantage that the ST32 software needs only to move small quantities of data (i.e. one sector) at a time and with its 84 MHz clock and 100+ MIPS it should be able to do that purely in software with no DMA peripherals, and easily stay ahead the 1 MHz clock 6502 pumping that data with something like 0.2 ot 0.5 MIPS, and 8-bit MIPS at that.

 

Another, more important, advantage is that the master "read track buffer" stays intact and is only manipulated by the ST32 software. The relative "angle" of the track in that buffer stays the same, when measured to other tracks. The "sectors" never move. An important feature of real floppy disks, and exploited by many copy protections ("synchonized / aligned tracks").

 

If you can't figure out how to do that in software, there is another option, which involves adding hardware. You could add a 74LS157, which has four 2:1 multiplexers inside, only two of which would be used. WR_REQ would go to the "Select Input" and the multiplexers would be wired such that when WR_REQ is deasserted (read mode) the SPI clock and data for the write channel would come from the read channel. When WR_REQ is asserted (write mode) the SPI clock and data for the write channel would come from the 74LS393 and the change detector. The net effect is that once this machinery is in place, the revolving read track buffer would be copied automatically into the revolving write track buffer. And any real write coming from WR_REQ would magically end up at the right place in that write track buffer. No fine adjustment / clever software algorithm to determine the right place needed.

 

But as nice as this appears, like with many "easy looking" plans, there is a devil's hoof (more than one):

 

First, any sector written will persist in the write track buffer for only for one revolution, and then jump back to the previous state. You would need to correct that by flipping the read and write track buffers just at the right time, such that the "new" track becomes the read track buffer, where the just written sector (or track) data persists. This "flipping at the right time" may be tricky. You need to know what was written, and when, and where, and do the flip just at the right time to capture the correct, current state of the track that just has been modified. If anything goes wrong with the timing of that, you get garbage, a mix between the old and the new state, or some of the track gone missing.

 

Second, due to the latency / delay in the SPI / DMA data pipelines, the relative angular position of the involved track buffers will slowly move from the original situation. You need to have some code which detects and corrects for that angular error. This can be tricky ... what are you looking for ? A sequence of bytes ? That may be shifted bitwise ? Or may have been overwritten ? Can you extract the exact position shift from the DMA machinery ? How would you correct for the error down to the individual bit cell ? Questions, Questions ...

 

... which I never have solved. In my floppy disk emulator of ~ 30 years ago there was a hardware track buffer (a SRAM) with a circular address counter, and single bytes would come out in read mode and single bytes would go in, when WRITE GATE was asserted, to the same byte position. It also made a virtual index pulse when the address counter rolled over. The Western Digital floppy disk controller (I think it was a WD2793, but not sure, has been a long time, it supported FM and MFM modulation) used that index pulse so start / stop track formatting so all was nicely aligned. When the head was moved, the track buffer was flushed to main memory ... stepper motor step delay and the head settling time delay was enough to stash away the old track and to load the new track. From a PC running under DOS, of course. Enough RAM to hold a complete disk image. Disk images were stored on the hard drive. It worked fine, even with the slow PCs of the time being. Today I would use the "Ratweasel" hardware and software which relies on the higher data rate and ECP parallel port of a more modern PC or notebook. Alas, even those are obsolete and hard to find in good condition today.

 

The ST32 based floppy emu leverages the immense power of a modern microcontroller and certainly is fast enough to handle everything. But it relies on complex inner machinery like the DMA channels, the FIFOs, the SPI peripherals and all of this data path has latency / pipeline delays which may be tricky to account and compensate for in software, to avoid corruption of the disk image. But speedwise, it could also emulate the whole Apple II and provide live video, if it had enough RAM (the basic Apple II had 48 kBytes of RAM, but to run all software you would need 128 kBytes plus some for the emulator itself). But we don't want to go there ... we want just a floppy emu. I'm quite sure you can do it, but you need to tackle the fine details and complications from the peripherals you have in the ST32. The more powerful they get, the more surprises they have lurking in them.

 

- Uncle Bernie

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Hello Uncle Bernie, Thanks

Hello Uncle Bernie, 

Thanks again for all the above very detailed explainsation. 

I continue my journey and I am doing some progresses

The good news :

I have sent (using ADTPRO) a dsk (Boulder Dash II) to a real floppy, check the content of the floppy via Locksmith to have a valid source of truth.

Then I move forward with doing a copy from the source of truth track 0 to the emulator and comparing using the logic analyzer the content of WRDATA and the content of the DMA_Circular buffer.

1/ The comparaison is good with very few glitches,

This is the output of the stm32 WRData buffer: 

 

2/ I wrote a small python script to play with bitwise operation on the SPI received buffer (WRData) the good news is that I have the typical signature D5AA96 & D5AAAD,...

Using the 2 Circular DMA the copy between the 2 can be bit tricky and 5 cases can happen:

rx_s= index of the start WR_REQ in the WRDATA buffer

rx_e=index of the end WR_REQ in the WRDATA buffer

 

 

It would be super easy to copy RX -> TX and the end of WR_REQ Interrupt, but... this is not so simple !!!

Using LockSmith there are 5 write attempts and beween each attempt there is a read

I suppose that there are 5 attempt because the content read after the write phase is not matching the source...

Now If we zoom the 1 write attempt considering a track is 13*512=6656 Bytes *8 =53248 Bits, I am expecting to have a max of approx 53248 falling clock edge and of course .... it is not the case : 

I receive 116264 clock edge, meaning : 14533 Bytes.

In a nutshell, the circular buffer is doing 2.5 full round before the WR_REQ gets deasseted. So, I need to manage Half & full buffer interrupt to copy partial part of the buffer to make it work (taking as well the above case).

Well, I am progressing but clearly I am not done with the wirting process.

 

to be continued.

V

 

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
VIBR wrote:typical signature
VIBR wrote:

typical signature D5AA96 & D5AAAD...Well, I am progressing but clearly I am not done with the wirting process.

 

Are you ready with the reading emulation? These signatures can be different, why don't you try to detect sector gaps instead?

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
I have done some test with

I have done some test with reading and it works (with unprotected woz & dsk), I need to do some timing adjustment & fine tuning to support spiral track &...

I was checking for signature to make sure I received valid data, but I will manage incoming data as bytestream in the circular buffer.

 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
A possibly superflous comment ...

... because you seem to have progressed further than I thought with the write process. But I made a short writeup of my thoughts about the write process which I don't want to throw in the digital trashcan. Here it is:

 

The method to copy individual sectors from the write buffer to the read buffer needs no complications. It can be done on a byte level, without bit shifts, because the possible maximum error of a 7 bit shift due to data path latency is far less than the 1% (max 3%) of rotational speed error of a typical floppy disk.

 

SHORT SUMMARY HOW SECTOR WRITES WORK (different from full track format !):

 

IIRC, during sector write, the RWTS will "look" for the right sector header which has the form:

 

$D5 $AA $96 .... the "prolog", followed by eight disk nybble byte which are FM encoded byte pairs:

 

1 D7 1 D5 1 D3 1 D1

1 D6 1 D4 1 D2 1 D0

 

the first byte of the pair, shifted one bit to the left with a "1" shifted in ANDed with the 2nd byte gives you the final byte value, here is an example of 6502 assembly code (from memory, so take it with a grain of salt):

 

 

LDA BYTE1

SEC

ROL A

AND BYTE2

 

 

The eight disk nybble bytes after the $D5 $AA $96 prolog hence yield four de-nybbelized bytes which are:

 

Volume

Track

Sector

Checksum

 

This is followed by an epilog:

$DE $AA $EB

 

after that there begins a GAP. The RWTS takes a while to de-nybbelize the information and to compare if the volume, track, sector, checksum is OK, and to prepare for write. It then turns on WR_REQ and writes five SYNC bytes (1111111100 1111111100 1111111100 1111111100 1111111100) before it writes the data field prolog $D5 $AA $AD, the 342 disk bytes for the 256 sector data bytes (6/2 encoded), the checksum, and the epilog, as above,$DE $AA $EB.

It then puts a final byte into the DISK II shift register (IIRC, all 11111111) and deasserts WR_REQ. Normally, these last "1" bits don't all make it to the floppy disk, some get cut off by the end of write. And there is an ugly write splice there, some random garbage, but only on the real floppy disk.

 

HOW TO IDENTIFY WRITTEN DATA SEQUENCE

 

With my proposed (separate) write track buffer, the end-of-write is the first zero bit after a sector has been written and captured. Easy to detect. By searching backwards from the approximate begin of the write for the first zero byte you can detect the start-of-write.

 

What is left to do is to find out where in the read track buffer this sequence of bytes needs to be copied to. If you capture the position of the forever revolving timer upon WR_REQ assertion you can calculate the place in the read track buffer accurately enough to know where the data byte sequence from the write track buffer must be copied in. The forever rotating timer must be exactly in lockstep with the revolving read DMA ring buffer to make this possible. The slightest error will accumulate and wreak havoc. I don't have the time to dig that deep into the ST32 datasheet to tell you how to accomplish that. Maybe you need to restart the timer when the DMA ring buffer wraps around. Or maybe you can look into the state of the DMA channel to find out - but beware, if a FIFO is involved, there will be DMA bursts and this will warp the time axis.

 

As you have correctly stated in your last posts, the write block detection and copy process must take into account possible "wrap around" situations in both buffers. But I think this is quite trivial to handle if you work with software only and don't try to use DMA hardware to make the move. It boils down to increment and decrement pointers and check for the boundary cases (index 0 and index of last byte of ring buffer) before doing that.

 

NO DECODING NEEDED (except for analysis during debugging)

 

Note that for the detection of the begin and end of the disk nybble data field in the write buffer you do not need to decode anything, just treat it as a sequence of bytes. And when you got your positioning into the read track buffer right, based on said timer, you just can copy it bytewise ... but don't copy any of the leading or trailing zero bytes in the final revision. You may copy ONE leading or trailing zero byte each during the debugging phase so you can easily see where it was copied to.

 

BEWARE OF ZERO BYTES

 

But for general purpose, all zero bytes do not exist in regular bit cell streams of Apple II disk images, EXCEPT maybe for some copy protections where instable bits must be emulated. I can't say much about this - ask the Applesauce guys - but I dimly seem to to remember I once saw a code piece in some Apple II emulator (I don't rememember which) where the DISK II controller emulation module looked for a sequence of "0" bit cells and then inserted a random "1" after three or more of these "0" bit cells.

 

This obviously was meant for the emulation of "instable" floppy disk bits used in some copy protections. I'm not sure if the use of random bits is the best approach to deal with it ... because I know I could construct a copy protection and a copy protection check which would produce unstable floppy disk bits but could not be foiled by said technique.  It again boils down to 'plesiochronous' systems. You can construct a sequence of bit cells where a 'clock slip' is provoked at some known locations. The exact point in time will depend on rotational speed of the floppy disk, and the jitter of the analog channel. So it can't be guaranteed exactly where the 'event' will happen. But what you know is that a "1" bit may be 'seen' earlier or later, and if 'seen' later, a "0" bit may be inserted. But except for this 'event', the bit cell sequence will be predictable and can be checked to meet expectations. Swindlers who try to trick this copy protection with a random bit cell state will not succeed. So here we have a (hypothetical) example, or "thought experiment", which proves that random bit cells in floppy disk emulators may not cut it.

 

The only question is if there ever were Apple II copy protections, back in the 1980s and 1990s which had that level of sophistication. We need to keep in mind that if a simple method to trick the check into accepting the emulation as an original floppy disk (which long has been eaten by mold and/or is decomposing) works for 90% of the titles, we are good. All the few exceptions could be handled by applying cracks. The "4AM cracks" are probably the best because they try to preserve the original software as much as possible. This does not apply to most of the lesser quality  1980's cracks which were done by teenage computer nerds who had to leave their "greetings" all over the place or removed title screens completely. From a standpoint of software preservation / emulation for eternity, such examples which have been mutilated by these teenage software pirates are worthless. Unless no originals could be found and properly imaged by specialized hardware (Applesauce).

 

So far my thoughts for today.

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Hello Uncle Bernie,I have

Hello Uncle Bernie,

Houston we got a problem...

 

I have almost finished the piece of software to copy real time the DMA_RX to DMA_TX buffer using partial circular buffer interrupt.

I use Locksmith to copy a single track from an original DISK II to the emulator.

As mentionned in an earlier post, the process of copy using locksmith try 5 times to copy a full track. It is more than a full track because avg 14K bytes are sent to the emulator / write attempt.

After each write attempt I dump the content of the TX buffer to the SDCard  after doing all the memcpy at the right place. I also have the trace of the log analyzer. 

 

Using Locksmith, I can see the content of track 0 with the NIB Editor. We can very easily see the Address field signature of D5.AA.96 and the prologue of D5AAED

I wrote some python script to analyze to understand the potential GAP

 

I started by searching for the sequence of bits "0xD5AA96" in the dump of the TX buffer

It gives (same results on the logic analyzer). The logic Analyzer is connected to the NEW_WRDATA and the SPI_CLOCK.

 

search bit pattern:0xD5AA96 DMA_TX

   indx:0 offset:1664 (bits)  length:1664 bits bytes:208.0

   indx:1 offset:4748 (bits)  length:3084 bits bytes:385.5

   indx:2 offset:13987 (bits)  length:9239 bits bytes:1154.875

   indx:3 offset:17069 (bits)  length:3082 bits bytes:385.25

   indx:4 offset:23229 (bits)  length:6160 bits bytes:770.0

   indx:5 offset:41746 (bits)  length:18517 bits bytes:2314.625

   indx:6 offset:51842 (bits)  length:10096 bits bytes:1262.0

 

search bit pattern:0xD5AA96 Logic Analyzer

   indx:0 offset:70170 (bits)  length:70170 bits bytes:8771.25

   indx:1 offset:73240 (bits)  length:3070 bits bytes:383.75

   indx:2 offset:76324 (bits)  length:3084 bits bytes:385.5

   indx:3 offset:85563 (bits)  length:9239 bits bytes:1154.875

   indx:4 offset:88645 (bits)  length:3082 bits bytes:385.25

   indx:5 offset:94805 (bits)  length:6160 bits bytes:770.0

   indx:6 offset:113322 (bits)  length:18517 bits bytes:2314.625

 

the offset is the number of bits from the beginning. It is normal to have offset difference between Logic Analzer and DMA due to the circular buffer that can start in the middle of the buffer. 

I keep track of the RX & TX position to do the different memcpy that is logged in the UART terminal 

 

cpy i:00 half:1 Bloc_size:6656 src(s:4380,e:6655) => dst(s:4365,e:6640) l:2275 tx_rx_gap:-15 total_byte:14536

   subop j:00 type:A src(s:4380,e:6655) => dst(s:4365,e:6640) l:2275 

cpy i:01 half:0 Bloc_size:6656 src(s:0000,e:3327) => dst(s:6641,e:3312) l:3328 tx_rx_gap:-15 total_byte:14536

   subop j:00 type:B src(s:0000,e:0015) => dst(s:6641,e:6656) l:0015 

   subop j:01 type:B src(s:0015,e:3327) => dst(s:0000,e:3312) l:3312 

cpy i:02 half:1 Bloc_size:6656 src(s:3328,e:6655) => dst(s:3313,e:6640) l:3328 tx_rx_gap:-15 total_byte:14536

  subop j:00 type:A src(s:3328,e:6655) => dst(s:3313,e:6640) l:3327 

cpy i:03 half:0 Bloc_size:6656 src(s:0000,e:3327) => dst(s:6641,e:3312) l:3328 tx_rx_gap:-15 total_byte:14536

   subop j:00 type:B src(s:0000,e:0015) => dst(s:6641,e:6656) l:0015 

   subop j:01 type:B src(s:0015,e:3327) => dst(s:0000,e:3312) l:3312 

cpy i:04 half:0 Bloc_size:6656 src(s:3327,e:5604) => dst(s:3312,e:5589) l:2277 tx_rx_gap:-15 total_byte:14536

   subop j:00 type:A src(s:3327,e:5604) => dst(s:3312,e:5589) l:2277

 

I did the same for the prologue signature :0xDEAAEB

search bit pattern:0xDEAAEB DMA_TX

   indx:0 offset:1493 (bits)  length:1493 bits bytes:186.625

   indx:1 offset:1751 (bits)  length:258 bits bytes:32.25

   indx:2 offset:4561 (bits)  length:2810 bits bytes:351.25

   indx:3 offset:4835 (bits)  length:274 bits bytes:34.25

   indx:4 offset:7645 (bits)  length:2810 bits bytes:351.25

   indx:5 offset:7915 (bits)  length:270 bits bytes:33.75

   indx:6 offset:10995 (bits)  length:3080 bits bytes:385.0

   indx:7 offset:16886 (bits)  length:5891 bits bytes:736.375

   indx:8 offset:19968 (bits)  length:3082 bits bytes:385.25

   indx:9 offset:20230 (bits)  length:262 bits bytes:32.75

   indx:10 offset:23044 (bits)  length:2814 bits bytes:351.75

   indx:11 offset:23316 (bits)  length:272 bits bytes:34.0

   indx:12 offset:26128 (bits)  length:2812 bits bytes:351.5

   indx:13 offset:26398 (bits)  length:270 bits bytes:33.75

   indx:14 offset:29482 (bits)  length:3084 bits bytes:385.5

   indx:15 offset:32574 (bits)  length:3092 bits bytes:386.5

   indx:16 offset:35654 (bits)  length:3080 bits bytes:385.0

   indx:17 offset:38748 (bits)  length:3094 bits bytes:386.75

   indx:18 offset:44645 (bits)  length:5897 bits bytes:737.125

   indx:19 offset:48848 (bits)  length:4203 bits bytes:525.375

 

search bit pattern:0xDEAAEB Logic Analyzer

   indx:0 offset:67176 (bits)  length:67176 bits bytes:8397.0

   indx:1 offset:73069 (bits)  length:5893 bits bytes:736.625

   indx:2 offset:73327 (bits)  length:258 bits bytes:32.25

   indx:3 offset:76137 (bits)  length:2810 bits bytes:351.25

   indx:4 offset:76411 (bits)  length:274 bits bytes:34.25

   indx:5 offset:79221 (bits)  length:2810 bits bytes:351.25

   indx:6 offset:79491 (bits)  length:270 bits bytes:33.75

   indx:7 offset:82571 (bits)  length:3080 bits bytes:385.0

   indx:8 offset:88462 (bits)  length:5891 bits bytes:736.375

   indx:9 offset:91544 (bits)  length:3082 bits bytes:385.25

   indx:10 offset:91806 (bits)  length:262 bits bytes:32.75

   indx:11 offset:94620 (bits)  length:2814 bits bytes:351.75

   indx:12 offset:94892 (bits)  length:272 bits bytes:34.0

   indx:13 offset:97704 (bits)  length:2812 bits bytes:351.5

   indx:14 offset:97974 (bits)  length:270 bits bytes:33.75

   indx:15 offset:101058 (bits)  length:3084 bits bytes:385.5

   indx:16 offset:104150 (bits)  length:3092 bits bytes:386.5

   indx:17 offset:107230 (bits)  length:3080 bits bytes:385.0

   indx:18 offset:110324 (bits)  length:3094 bits bytes:386.75

   indx:19 offset:116221 (bits)  length:5897 bits bytes:737.125

 

After that I extracted the 112 bits  chunk of the address signature :

search bit pattern:0xD5AA96

   indx:0 offset:1664 (bits)  length:1664 bits bytes:208.0

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101010 11010101 01010111 01010101 : d5 aa 96 ff fe aa d5 57 55

72: 11111101 11111101 10111101 01010101 11010110                                     : fd fd bd 55 d6            

]

   indx:1 offset:4748 (bits)  length:3084 bits bytes:385.5

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101010 10101011 01010111 01010111 : d5 aa 96 ff fe aa ab 57 57

72: 11111101 11111111 10111101 01010101 11010110                                     : fd ff bd 55 d6            

]

   indx:2 offset:13987 (bits)  length:9239 bits bytes:1154.875

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11101111 11111101 01010101 01010101 01010111 01011101 : d5 aa 96 ef fd 55 55 57 5d

72: 11111101 11110101 10101010 10101011 10101100                                     : fd f5 aa ab ac            

]

   indx:3 offset:17069 (bits)  length:3082 bits bytes:385.25

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11110101 01010101 01010101 01010111 01011111 : d5 aa 96 ff f5 55 55 57 5f

72: 11111101 11110111 10111101 01011011 10101100                                     : fd f7 bd 5b ac            

]

   indx:4 offset:23229 (bits)  length:6160 bits bytes:770.0

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101010 10101010 10011101 01010111 : d5 aa 96 ff fe aa aa 9d 57

72: 11110111 11111111 10111101 01010101 11010110                                     : f7 ff bd 55 d6

 

I never have the prologue on the last 3 Bytes: DE.AA.EB

 

Based on all the above investigation, I come to the conclusion that what is generated from the circuitery seems to be partially right / wrong and to be honest I do not know where to start...

I tried to find some pattern of errors but nothing repeatable.

 

Could you please have a look on the electronic schema &/ point me into the right direction, i am a bit lost without idea.

Is it worth to increase the frequency of TIM4 (currently 2Mhz) to 4Mhz ? and have COUT to Q3 (8)

 

Hereafter the zoom on the Logic Analyzer including the raw signal from /WRDATA on the typical D5AA96 signature.

 

 

 

Edit 1: Well I think I found something...

Investigating the circuitery the Q on LS_123_5 was always staying LOW, and this is normal because the PIN 9 was not linked to GND as per the truth table if I am not wrong. 

Now I get a signal but I do not know it is better. more to come.

 

EUREKA BAM !!!!! IT IS FREAKING WORKING !!!

For the first time Locksmith approved the writing !!!

I need to do some investigation sharing the bearsking among the nations before the bear is dead.

 

The  00 at the top left of the screen indicates no error detected during copy

And I only have one write attemps now

Correct version of the schema

 

and for the fun the board 

 

 

The dump of the track and the signature is really really better !!!  

   indx:9 offset:33820 (bits)  length:3146 bits bytes:393.25

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101111 10101011 10101011 10101110 : d5 aa 96 ff fe af ab ab ae

72: 11111011 11111011 11011110 10101010 11101011                                     : fb fb de aa eb            

]

   indx:10 offset:36964 (bits)  length:3144 bits bytes:393.0

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101111 10101011 10101011 10101111 : d5 aa 96 ff fe af ab ab af

72: 11111011 11111010 11011110 10101010 11101011                                     : fb fa de aa eb            

]

   indx:11 offset:40098 (bits)  length:3134 bits bytes:391.75

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101111 10101011 10101110 10101010 : d5 aa 96 ff fe af ab ae aa

72: 11111110 11111111 11011110 10101010 11101011                                     : fe ff de aa eb            

]

   indx:12 offset:43234 (bits)  length:3136 bits bytes:392.0

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101111 10101011 10101110 10101011 : d5 aa 96 ff fe af ab ae ab

72: 11111110 11111110 11011110 10101010 11101011                                     : fe fe de aa eb            

]

   indx:13 offset:46362 (bits)  length:3128 bits bytes:391.0

<Bits, fmt='bin, hex', length=112 bits> [

  0: 11010101 10101010 10010110 11111111 11111110 10101111 10101011 10101111 10101010 : d5 aa 96 ff fe af ab af aa

72: 11111111 11111111 11011110 10101010 11101011                                     : ff ff de aa eb            

]

 

 

Vincent

 

 

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
For debugging purposes I

For debugging purposes I suggest you to attach your "emulator" in parallel to the real floppy drive/diskette and log only the writinig of one track to see what you receive in your buffer compared to the real track written on the physical diskette. Leave the reading channel connected to the real floppy drive. Just "sniff" the WRDATA.

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Good progress was made ... 

In post #107, "VIBR" wrote:

 

"Is it worth to increase the frequency of TIM4 (currently 2Mhz) to 4Mhz ? and have COUT to Q3 (8)"

 

"EUREKA BAM !!!!! IT IS FREAKING WORKING !!!For the first time Locksmith approved the writing !!!I need to do some investigation sharing the bearsking among the nations before the bear is dead."

 

Uncle Bernie comments:

 

Congrats for reaching this important milestone (Locksmith approves the written track). But believe me, more work is ahead of you ... the devil is always lurking in the details. But you made good progress for the time invested.

 

As to the question of increasing clock speed for the TIM4, you should do that. You may go as high as possible. You could feed it 4 MHz, 8 MHz, 16 Mhz, 32 MHz, ... and then use Q3, Q4, Q5, Q6. (I did not check the datasheet if the 74LS393 could run at 32 Mhz, but there is always a 74S393 or 74AS393 option. Avoid CMOS like HC and HCT as long as you are using the plugboard. A properly designed PCB could take CMOS).

 

The benefit you get from higher clock speeds is smaller phase jumps on the SPI clock, so it's easier to analyze. You also will get fewer metastability events. Same reason why Apple increased the sampling speed when they designed the IWM. Except that they were dealing with RDDATA, and not with WRDATA. Going higher than 8 Mhz may not be necessary.

 

- Uncle Bernie 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thanks Uncle Bernie, I have a

Thanks Uncle Bernie, 

I have a lot of code clean up to do, 

I have also ordered from JLCPCB some SBB 830 https://github.com/vibr77/SBB830  to make the circuit more resilient to instability of the plug board (even If I have some high quality pg board BB 830)

Checking the data sheet of the LS393, it can go up to 35 Mhz.

However, looking at the datasheat, currently I count til 4 and I use Qc (2Mhz), I can go easily to count to 8 Qd (4Mhz) but above, I will need another 74LS like the 74LS08.

I would rather to go to 4mhz and use Qd 

 

Do you have somewhere a schema to protect the circuit against inverting the Apple 20 pin connector consequence (+12V -> +5V) ?

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
VIBR wrote:However, looking
VIBR wrote:

However, looking at the datasheat, currently I count til 4 and I use Qc (2Mhz), I can go easily to count to 8 Qd (4Mhz) but above, I will need another 74LS like the 74LS08.

I would rather to go to 4mhz and use Qd 

Wrong. You can count to 256 by cascading the other half of the 393 that you are already using. Qd must be wored to COUNT of the other half.

 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Uncle Bernie's comments on posts #110 and #111.

In post #110, "VIBR" wrote:

 

"Do you have somewhere a schema to protect the circuit against inverting the Apple 20 pin connector consequence (+12V -> +5V) ?"

 

Not yet. But I need to work out such a scheme anyways for my own purposes. I will send you a schematic when ready, but don't hold your breath. I'm working on many projects at the moment, not all are electronics, and have very little bandwidth left over.

 

In post #111, "retro_devices" wrote:

 

"You can count to 256 by cascading the other half of the 393 that you are already using. Qd must be wored to COUNT of the other half."

 

Correct. The QD output of counter 1 must be wired to the clock input of counter 2 to cascade the counters. This is why I recommended the 74LS393 ... I have foreseen the case that we may want more counter stages. But when you use cascaded counters, do not forget to also wire the CLR inputs together. Otherwise, only half of the counter would get cleared, which would cause that digital PLL not to work as expected. (Just for the nit-pickers and the curious, it's not a true PLL yet as it lacks a VCO and a loop filter, but it does the same work, except for having more phase jitter due to the fixed clock frequency. But it's good enough for the application. A lot of the so-called "data separators" in the early 1970's and 1980's floppy disk controllers used just a simple 4-bit counter in the same way, to make a sampling clock in the middle of a bit cell. So it's an old and proven method.)

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thanks Uncle Bernie, Take

Thanks Uncle Bernie, 

Take your time, I will hold my breath, and I have still a lot to do. 

I time to compare data from the disk II and the emulator and the writing of track 0 is bit perfect. I have an issue with the track after, but this is something on my software.

Vincent 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Continuing my journey,The

Continuing my journey,

The copying is seems to be pretty ok, 

Quick question:

 

A woz track is 13*512= 6656

I setup my DMA Buffer Read & write to this size. 

When I copy a track using Locksmith the start of the track can be in a middle of a previous sector. 

Thus How is the controller managing this ? 

There will be a partial remaining sector why a non close data segment missing the DE AA EB 

 

Do I need to do something special like cleaning the written track with unclosed data segment ?

Can I keep it like this considering that the controller wil just ignore it ?

 

What is the best approach ?

In the below exemple, the written sectors for track 1 are on track after the write process :

Having the sector 2 zoomed :

The sector 2 in the middle has no closing signature because the writing process started with sector 3 in the middle of sector 2

 

Vincent 

 

 

 

 

 

 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
If I have to clean up the

If I have to clean up the partial sector, it starts to be very complex due to the miss alignemnt of the bit sequence... 

One way to do it would work only on the non written part before the first sector and search with progressive bit shifting, 

any advice would be much appreciated...

Vincent 

 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Track writes vs. Sector writes and can we ignore bit shifts ...

In post #14, 'VIBR' wrote:

 

" When I copy a track using Locksmith the start of the track can be in a middle of a previous sector.  "

 

Uncle Bernie comments:

 

I don't know Locksmith, never used it, but I think that UNLESS you tell it (somehow) to align the tracks, it will start writing the track at a random location. This was the common procedure with  most track based copy programs. Aligning the tracks is possible but involves extra head movements to "look" at a reference track to which all the other tracks will get aligned. Of course, the software must compensate for the head movement times.

 

This increases the time expenditure to make a copy by 2 ... 3 fold so the default option was to do no track alignment. Only for copy protected disks which used track alignment aka "synchronized tracks" etc. (it has many names) there was a switch to turn that extra function on.

 

I think (but not 100% sure) that the best approach would be to detect if a whole track is being written or if only single sectors are being written (as usual for DOS 3.3). For single sectors, copy them to the right place in the "read track buffer". For whole tracks, discard the "read track buffer" and use the newly written track as the new read track buffer. I suggested to make this different approaches before in this thread. And I also suggested to make the single sector writes work first. All copy programs like Locksmith always reformat / write whole tracks and this is a complication. Honestly, I don't think a floppy emu must be able to receive newly made disk images produced with such a copy program. These programs (Locksmith and the like) were meant to duplicate copyprotected disks and although they were popular back in the 1980s, (for obvious reasons ;-) they never were perfect and whatever images of copyprotected floppy disks you might be able to make, the result will be inferior to WOZ images made with a flux engine and the quite sophisticated tool chain involved. A copy made with Locksmith or any other software only solution relying on the original DISK II hardware always must be doubted - is it really a faithful, perfect reproduction  of the original copy protection scheme ?

 

The ability of a floppy emu to take sector writes from DOS however is a must.

 

Oh, and don't worry about bit shifts. The captured disk nybbles in the write track buffer indeed can start at any bit position. There is no need to correct anything or shift them back, as long as the integrity of the whole bit cell stream is intact. You analysis tools, however, must be able to handle the situation. The best way is to pipe the bit cell stream into a Woz Machine emulation and watch for the re-assembled / re-aligned disk nybbles falling out of it. This will also remove all the superflous "0" bits in the SYNC bytes. Which on the emulator image of course must stay as is !

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thanks Uncle Bernie, I will

Thanks Uncle Bernie, 

I will do some deeper analysis and I have the feeling that locksmith is performing the right way with the rigth alignement, what would be the issue is the length of the circular buffer...

If the circulatr buffer is too long then there will be always a remaining part. 

And depending on the size of the circular buffer, the remaining part will contain or not the Addrs signature and or the Data signature header. 

 

Quick question:

- Is remaining partial sector  preventing the software from loading or is it ignored by the system ? 

- A disk is running a 300 rpm, considering write every 3.91 / 3.92 us gives 51150 Bits => 6390,  does all woz track use the 6656 ? or do we have free data at the end ? One way would be to reduce the DMA Buffer size to avoid overlap ? Using Donkey Kong II as reference disk the track 0 is for ex 6452, track 1 is 6452, track 2 is 6451 ...

 

there is no way to do realtime processing of the DMA Buffer it will be very expensive in term of CPU. 

The more I think about it, what I would do is post processing after the end of the writing,

- if write buffer size is > 50.000 (bare minimum track length 4Us 200ms per rotation at 300 rpm)

   - keep the start of the recording in the TX buffer, 

   - work only on the 416 Bytes (402 Bytes + sync gap) (size can be adjusted)

      - find a D5.AA.96 without a D5.AA.AD closed by DE.AA.EB => find a D5.AA.96 with a D5.AA.EB closed by a D5.AA.96

      - Doing that (the search) on Bytes array with potential bit misalignement can be CPU time consuming....

      - My approach would be to detect the D5.AA.96 bytes sequences will potential bytes shifting every 2 bits and GCR6x2 combination among the 96 potential bytes

         - ex: it means searching for the reserved D5.AA

                        D5.AA,

                        Bit shift 2 : 56.A9 (Left shift 2 bit with 1 in LSB as there can be only 2 consecutive 0), 56.AB, 56.AA

                        Bit shift 4 : ...

        - the other way is working on a 3 bytes buffer incrementing and doing a bit shift of 2 with char reload til the end of the buffer

 

In any case it will be time consuming, is there any efficient C function searching for a bit pattern in Byte buffer ?

 

EDIT1: Answer 10 in this thread needs my attention I think:fatest_way to_scan

EDIT2: I need to check for partial sector not at size >50.000 but everytime the circular buffer is reaching the end & restart

 

Vincent

                        

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
The more thinking and

The more detection of patterns you implement in your firmware the worse and more partial this device will be. Locksmith is great and was written by real masters of Apple2 and assembly language. And was used back then (by me and my friends) more than DOS 3.3. itself, considering many software was not realeased on (standard) DOS at all. Its Fast Backup is still faster in copying a diskette than the contemporary buggy applesauce with its overclocked ARM for example. 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
I do not see any other option

I do not see any other option that cleaning the overlapped remaining sector. 

I wrote a function that is searching for bit pattern within a Bytes buffer. 

It can search for the 3 signature : D5.AA.96, DE.AA.EB, D5.AA.AD

I use an array of 8 bit shift results on signature

it search for any of the 8x2 Bytes and check for the heading and trailing bit shift as well.

In case of positive match it return a pointer to index in the buffer.

The source code,

Package icontest.c.zip

Will check the perf on the STM32, but on a small buffer it should not be an issue.

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
If you follow that path your

If you follow that path your "emulator" is doomed. Try to emulate a diskette. It has no logic to discard anything, except once it overlaps due to circular tracks . Just store everything on a given track within some 200 mS FIFO and be able to play it. Overlap/overwrite (this is an effective discard) when wirting past 200 mS. Keep precise with sufficient resultion "angular position" pointer, e.g. time, or counter whatever you call it common for all tracks because the emualted diskette is one physical disc. Do not interpret any data. Leave that to controller+Apple2 software. If you wish make your own file/image format that is more convenient to you. If your chosen STM controller has no sufficient RAM, try to add or use better MCU with more RAM.

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Don't doom your emulator !

In post #120, 'retro_devices' wrote in response to 'VIBR's post #119:

 

" If you follow that path your "emulator" is doomed. "

 

Uncle Bernie agrees with  'retro_devices'. Don't try to get too smart and don't try to scan for headers etc. to do "housekeeping work". You may look for them in your test setup (I suppose you can look at the track buffers of the ST32 using a PC or notebook) to analyze things, as I mentioned in this thread, but don't use that in your floppy emulator firmware itself. These header sequences exist in standard formats made by DOS 3.3  but may be modified or completely absent in copy protected disks. So relying on them to do any track buffer housekeeping is shooting yourself in the foot (and dooming your project).

 

What I meant with my recommendations is to not reach for the moon too early. Solve the simple case first - DOS 3.3. writes to a pre-formatted disk image. This means you only need to process small chunks of data written to the write track buffer and then to copy these chunks of data, without any decoding, bit shifting, interpretation, to the right section of the read track buffer while the copying process zeros out the bytes in the write track buffer it  took out for copying into the read buffer. This leaves zeros in the write track buffer for all work done.

 

This should be almost trivial to code EXCEPT how to find out where in the read track buffer (location) that data chunk needs to go. And this is strictly a function of your DMA channel latency and what is in the FIFO between the DMA and the SPI. You need to figure out how to determine that location from any state you may be able to capture from the read DMA channel by a WR_REQ initiated interrupt routine. Without looking at the contents of the read buffer. Without trying to "understand" the format.

 

If this is not possible you need a side channel, in hardware, to measure that latency. Which greatly complicates the hardware. Just to measure DMA latency. What a mess ! (Seems 21st Century super-MCUs have their perils because they are not very predictable ... maybe. Can't say as  I don't work with ST32, but I see the possibility of unpredictability, if they got too smart).

 

Full track writes as done by Locksmith are a different process and need different handling of the track buffers. AFAIK, Locksmith will write a complete track at once, and then go to read mode to verify it. If it finds something odd or wrong, it will retry. I think there is no way to catch up with that write data rate using a ST32 software copy loop, so you somehow need to flip the buffers. One approach you could try is to turn the write buffer into the read buffer once Locksmith deasserts WR_REQ. So Locksmith will "see" what it has written, with almost no delay, and might be happy.

 

None of this should require decoding and understanding Apple II GCR formatting. It should be possible to treat everything just as a stream of bytes. But it seems that you always need two track buffers, one for reading, one for writing, because synchronizing two SPI DMA channels such that they work on one track buffer, although this at first glance seems to be the right way to do it, opens a whole can of worms, read: lots and lots of possible complications.

 

So better keep it simple. If the ST32 is too advanced for the project, you can always go back to the 100% hardware based track buffer and a small 8-bit PIC processor for the housekeeping of the track changes, etc.

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thanks you both for your

Thanks you both for your comment, 

I have not tested yet the simple case of DOS3.3 writing a single sector.

 

The full track write with locksmith is not an issue, the issue is the circular buffer length (6656 13*512) and the length written by locksmith (6450 approx).

 

The 200 Bytes is creating the mess, and I can not predict the size of the written track, 

the only solution is see is discarding the content of the 200 bytes remaining with 0 when writing to SD Card. 

 

Vincent

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
To better illustrate the

To better illustrate the problem 

DMA Buffer is 6656 Bytes length (aligned with woz)

when WR_REQ gets asserted : the DMA RX buffer starts at index 2610 0x0a32 and stop 2294 0x08F6, the total bytes recorded is 6440

the RX (write) buffer is copy by chunk to TX (Read) buffer at the half and end of a circular loop.

This means that the zone on the TX Buffer from 0x08F6 to 0x0A32 contains previous track information

and in this zone, I have a partial sector, see below in yellow partial sector header signature (D5.AA.96)

I do not want to create a "health robinson machine" (Gaz factory in French) or my emulator to be doomed,

so I see the following options:

- 1/ Reduce the  track size in the track written to woz file,

- 2/ Clearing the data in the non written zone (0x08F6 to 0x0A32)

- 3/ Having a DMA that is 52400 b (6550 *8)  instead of 6656, => it means that woz track > 6550 will not work

 

What do you think ? Is there a better way ?

Vincent 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Well the right approach seems

Well the right approach seems to have a DMA buffer of 6464 bytes (404 Bytes per sector and 51712 Bits)

But because there is always a but...

write is faster than read (3.91 us approx write, read 4us), it means that the DMA TX / RX gap will increase during the process, it can only be used at the beginning and the ref has to be last index start write + len of write.

need to do some more testing

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
Think of a track as time. You

Think of a track as time. You have 200mS revolution time (approx, varying with rotation deviations from drive to drive). Divide it if you wish in 1, 2 or 4  microsecond parts, that either have flux change or not. 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
A comment on which track buffer sizes to use for which situation

In post #122, 'VIBR' wrote:

 

" The full track write with locksmith is not an issue, the issue is the circular buffer length (6656 13*512) and the length written by locksmith (6450 approx).

The 200 Bytes is creating the mess, and I can not predict the size of the written track, the only solution is see is discarding the content of the 200 bytes remaining with 0 when writing to SD Card."

 

Uncle Bernie comments:

 

Here you have the culprit for your troubles: excess length of your track buffer. Don't do that unless necessary for an image of a copyprotected disk that has a copyprotection which calls for a higher bit cell density ---> more bytes of track buffer needed.

 

To help understanding track buffer size:

 

it depends on whether you work with

(a) 'clean', synthetic disk images or with

(b) 'dirty' ones that came from an original disk, or with

(c) images from certain copy protected disks.

 

Let me explain these three cases:

 

GENERAL THEORY

 

The NTSC Apple II has a 14.3181818 MHz master clock and the typical CPU cycle has 14 such clocks (a few cycles are 'longer' but this does not matter for the floppy disk system and can be ignored for floppy emulators). So one CPU cycle has 0.9778 us (microseconds).

One ideal bit cell (as coming out of the master clock derived Q3 clock controlled DISK II card) has 4 CPU cycles, so its duration is 3.911 us, or, seen as a bit cell clock frequency, 255.7 kHz. (it would be great if you could match this frequency as close as possible for your read channel).

The rotational speed of the ideal DISK II is 300 RPM, or 5 revolutions per second, 200 ms (milliseconds) per revolution.

Into these 200 ms, 6392 disk bytes ("disk nybble") of 8 bit cells of 3.911us do fit.

 

CASE A):

 

So for case a) you need a track buffer size of 6392 disk bytes. Not more, not less.

 

Note that this case a) was meant for 'clean', synthetic disk images where everything is ideal, and crystal controlled, and the "floppy drive" runs exactly at 300 RPM. Which is never the case in the real world, with real floppy disk drives. For this reason, all programs which format a track (and this includes DOS 3.3 when formatting a disk, or Locksmith writing whole tracks) include automatic adaption to the actual number of bytes available per revolution. They start with long gaps between the sectors (or in case of Locksmith, one long splice gap), write the track, verify the track if its end has overwritten the beginning, and if so, then try again while reducing gap size in small decrements until the track fits and readback verifies it's correct. This means if your floppy emu offers only 6392 bytes of track buffer, any DOS or other tool will do the work to make their output fit into that buffer size. If you increase or decrease the track buffer size by a few percent (to mimic the expected variations and differences in RPMs of different DISK II floppy disk drives), it still will work. IIRC, the adjustment tolerance target for RPM was +/- 1% and the whole disk system was designed to be able to handle +/- 3% before its inner workings fall apart and fail to work.

 

CASE B):

 

These RPM tolerances explain case b): when a disk image is made from a real floppy disk, which had inevitable RPM deviations from the ideal, and assuming a fixed bit cell clock frequency, the proper emulation of that track will lead to slightly different track buffer sizes. What really matters is the exact number of bytes in the track, treated as a ring buffer, after N bytes where it must "roll over" seamlessly, with no time delay. With standard DMA channels this would be impossible unless a FIFO is present, because the software would need to watch for the DMA being finished and then - as quickly as possible - restart the DMA at the beginning of the track buffer, before the FIFO runs dry and the output data stream has a gap. Such a gap would kill the whole concept. The ST32 claims that its DMA supports circular buffers, so this should never happen.

This case b) must be handled by allowing programmable track buffer sizes. The WOZ files contain information on how many disk bytes are in each track. A floppy disk emulator must stick to this number.

 

CASE C):

 

Case c) is for nasty copy protections which change the bit cell size. This can be done either by changing the clock for the write process (this is how the mastering machines handled it (IIRC, FORMASTER called this "density frequency modulation", and they were proud to have that capability, which was not available with their competitors, at least not in that form), or it can be produced by changing the RPMs of the floppy drives, if the bit cell density of a whole track had to be changed - manipulation of RPMs is not as powerful as "density frequency modulation".

 

I can give you an example from the 8-bit Atari world: the normal number of sectors on a track for the Atari 810 floppy disk drive, which was FM aka "single density", was 18 sectors of 128 bytes. So the software pirate scene was stunned when games protected by 21 sectors per track did appear (I don't remember which titles, it happened more than 40 years ago).

At first, this copy protection appeared to be invincible. Until the "Happy Computer Company" which produced the infamous (from point of view of software publishers) "Happy Enhancement" for the Atari 810 added a way to reduce the RPM from 288 to 270, and then the 21 sectors could be written. "H.W.A." mode, or "Happy Wins Again" was the slogan for that mod. Other makers of Atari floppy speeders / enhancements quickly followed suit. One of them, the "1050 TURBO", had the speed change transistor on board and came with a small cable ending in a "microhook" grabber, so solderless installation was possible.

 

But back to the Apple II: at about the same time (early 1980s, before 1985), when the "density frequency modulation" protection schemes did appear, they also started to appear on Apple II floppy disks. I don't know if "Locksmith" ever "defeated" them. But the WOZ images have a way to support emulation of such higher density tracks, by providing the option for larger track buffer sizes. Which, IIRC, was not present in earlier versions of the WOZ image specification. And from my background in such copy protection schemes based on "density frequency modulation" on other computers (I have no experience with them on the Apple, though) I have doubts that even the current version of the WOZ file spec could properly support emulation of all possible "density frequency modulation" tricks. I think it may be beneficial to adjust the bit cell frequency (of the SPI clock in the read channel) such that a track with more bytes still has 200 ms per "revolution".

 

But here is the key point: floppy disk emulators (and their image file formats, like WOZ) only need to support copy protection schemes which actually did exist on Apple II floppy disks back in the day. Anyone could "cook up" a very toxic brine of copy protection nowadays by using a powerful flux engine, such as my "Ratweasel" sure could do, if I wanted to waste my time on coding the algorithms. But it is pointless to do so - real floppy disks are long obsolete, and the "New Old Stock" floppy disks we can occasionally buy also may have deteriorated to a point where they are useless. Plasticizers and lubricants disappear over the decades and mold also loves to "eat" them - I think its the glue which bonds the magnetic dust to the disk which gets eaten by the mold. (Your floppy disks may be "alive" and "crawling" with dangerous microorganisms, eeeek !). So I consider it a purely academic exercise to cook up new copy protections for floppy disks. Could be fun, though.

 

So far my comments / notes / background info on track buffers and how they relate to real world phenomena found with real floppy disks. Hope this gets your floppy disk emu project back on track !

 

- Uncle Bernie

 

 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thank Uncle Bernie for the

Thank Uncle Bernie for the very detailed explaination, 

I am back on track ;) as I can now write a full track without having partial sector overlap and LockSmith is not complaining when I use the mode : Sync. I still have an issue when I do not use the sync mode. In that case I have a 14K write buffer coming from Locksmith (equivalent to 2.5 disk rotation) of Data. I need to investigate why I do have an issue.

 

Regarding frequency adjustment for higher density, at the begining I was using SPI in master mode (Clock is managed by the STM32 using a prescaler divider). In that configuration start from 64 Mhz I was able to match the 4 Us period with a prescaler of 256. Of course with this configuration, there is no way to adjust the FM to reach 3.91. 

So I have changed for SPI from Master to Slave and I wired a TIMER pin to the SPI Clock pin. In that case I can very easily changed the SPI clock speed with a very high granularity. so having 3.91 is not an issue

On the track length, I have done some research, the best length would be 6464 kbytes (404 per sector),

My next step is copy a full disk of an unprotected game and be able to run it... It am not too far...

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Just a quick update !I

Just a quick update !

I finally made it ! copying a disk and have the copy to work 

After fighting to solve poor sync alignment between the 2 DMA buffer it finally works. 

macnoyd's picture
Online
Last seen: 1 hour 46 min ago
Joined: Oct 15 2012 - 08:59
Posts: 849
Congrat's!

Many here (including myself) are following your progress on this.  This project has shown technical knowledge far beyond what I personally have delved into -especially with Disk ][,  but it's of high interest & importance to many.

Congrat's on your progress and I look forward to your final result & success.

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thanks Macnoyd, Retro_device

Thanks Macnoyd, 

Retro_device and Uncle Bernie were instrumental to make this happen, still a lot to be done. 

I will try to make a first prototype pcb so that people can start playing with it 

Vincent

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
I still think that the

I still think that the project might have been more successful if programmed mainly in ARM assembly language. From the past I have stm32nulceo evaluation board for testing but it is with STM32F429ZI...

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Some praise and some suggestions how to proceed:

In post #130, 'VIBR' wrote:

 

" Retro_device and Uncle Bernie were instrumental to make this happen, still a lot to be done. 

 I will try to make a first prototype pcb so that people can start playing with it "

 

Uncle Bernie comments / advises:

 

Great progress was made indeed, as evidenced by the example ween running  in post #128.

If you look at the start date of this thread (2nd June 2024) there were only 5 weeks to reach this milestone.

 

About "still a lot to be done":

 

You are now at a point where you should check a lot of WOZ images of copyprotected disks on your emulator to see if everything works. Of particular importance are the "fat track" and "spiral track" protections. If these work, you have proof that your hardware choice is sound, and that your track buffer structure can handle this. Alas, I can't tell you which software titles to choose as a test suite to cover all protections. I do have a set of original Accolade "Comics" disks which are said to contain a "fat track" protection but it was a recent acquisition and I had no time to analyse it yet. So your best course of action is to ask others lurking on Applefritter if they could compile a list of test cases for you. The WOZ files can be found by searching for "Woz-A-Day Collection".

 

As for your plan to make a prototype PCB, I would advise against doing this prematurely, before you ran these tests. If you discover a case where the hardware needs to be modified / upgraded (i.e. a larger ST32) then your effort on the PCB would be wasted, and you will have created a bunch of disappointed and angry early adopters. So please do the tests first to get confidence that the hardware platform choice is right. This would also allow me to catch up with the design of the protection circuits. We could also put much of the logic into a PLD, such as a 22V10, or redesign the TTL stuff to avoid the nasty 74LS123 oneshots. IMHO these are NOT a good solution to make building the emulator by hobbyists foolproof. Without having an oscilloscope to check the timing, there is a risk of failure lurking. For my Apple-1 kits, I had to hand select all the 74123 and the timing R's and C's in a test rig while taking measurements on an oscilloscope. Just to guarantee the timing to be right. Otherwise it could have been a disaster. I think the clocks the ST32 (possibly) could produce from its crystal timebase could be harnessed to toss the 74123 out, and to have a solution that is robust and foolproof.

 

BTW, your choice to use an internal timer of the ST32 to make a finer timing for the read channel as seen in your post #127 was sound. The important thing here is that the emulated floppy disk ALWAYS should have a 200ms track repetition period, preferably +/- 1% tolerance, regardless of how many bit cells are in the track. The is the most faithful solution to emulate a real floppy disk, but requires some math to calculate and adjust everything. For read only it's trivial to do, but when you allow writes to such a higher or lower density track, it gets more complicated. This is yet unexplored territory ... and may bear some surprises and extra work for the copy process from the write channel track buffer to the read channel track buffer (the latter of which is the "timing reference" for the emulated floppy disk).

 

Recently, while scavenging the internet for ideas, I also have found a cheaper way to do the SD card interface, see here:

 

 

No need to buy expensive "shields" with SMD based connectors to use micro SD cards. The adapters are abundant and a dime a dozen. Most people have some left because they come with many products as an accessory. Those who threw them in the trash have to buy them, though. But it's still cheaper than these "shields". The trick is to solder a 2.54mm raster pin header row to the contact pads on the backside of he adapter. All of them except the last one fit perfectly. And that last one, despite being a bit off center, still is doable:

 

 

This DIY adapter for micro SD cards is not only much cheaper, but much more flexible for the mechanical arrangement / enclosure of the floppy emu. With the flat pin header row it would stick up, perpendicular to the PCB, and with a 90 degree bent pin header it would be parallel to the PCB. Several rows of pads could be provided on the PCB to allow installation as needed to fit into any conceivable enclosure.

 

So far my comments for today.

 

- Uncle Bernie

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
 Hello Uncle Bernie,  thanks

 

Hello Uncle Bernie, 

 

thanks for your comment and advice, I will continue to experiment till we have something more robust, 

I might go away from the plug board (even if I have some very good quality Plug board), but because when you manipulate it you could have some wire that are also moving a bit. 

The good news is that I received 40 x of this solder board SBB830 , it will make my life easier with less effort spent on connexion debugging. 

 

Regarding Apple II connector and SD Card connector, I have also made these 2 very small pcb to have someting on the plug board more accurate and it works well

 

 

 

Now when I come to remove the nasty LS123 (at least on the read side), I would go for something like this :

 

- the SPI Read Data is a 4us pulse coming out from the STM32 to the LS74 clock signal and will set the Flipflop on positive Edge (D is connected to VCC),

- Pulse signal is sent to Apple II Pin 16 and to an AND Gate

- The AND Gate is fueling a counter based on a STM32 Counter and the Q of the LS74 flipflop,

- to get a 1us pulse duration before the LS74 get reset, we need a counter counting up to 8

- the LS74 gets reset (active low) using a LS14.

I can easily adjust the frequency of the TIMER to make the pulse longer or shorter.

This is not really effective in term of number of ICs, WDYT? 

EDIT 1: 

- We could replace the LS74 with a LS175 having 4 Dflipflop

- Reducing the frequency of (divded by 2) of the Write counter and using the second counter for the 'new read part'

 

Vincent 

 

 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
to avoid the AND Gate LS08,

to avoid the AND Gate LS08, we could reuse one of the free channel of the LS125, something like this

 

 

Using LS175 instead of LS74 means having only 1 reset pin for all 3 D Flipflop, which can cause trouble during writing.... in that case it need to neutralize the reset with WR_REQ being High.

 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
retro_devices wrote:I still
retro_devices wrote:

I still think that the project might have been more successful if programmed mainly in ARM assembly language. From the past I have stm32nulceo evaluation board for testing but it is with STM32F429ZI...

Well I tend to agree and using the High Abstraction Level Api from ST is not great at all, 

I am using pure C (and not C++), and once I have validated the copy protection mecanism I rewrite the firmware to use low level ARM register. 

 

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Uncle Bernie, I started

Uncle Bernie, 

I started working on having a GAL like the ATF22V10C to simply the number of IC in the current schema below,

I am not a PLD expert (to be honest it will be my first attempt, but i will try to learn fast)).

I have put red boxes for components that can easily put in the GAL equations. 

In a nutshells :

for LS 125 

INPUT WPROT

INPUT LS123_Q

INPUT DEVICE_ENABLE

OUTPUT: RRDATA

OUTPUT: W_PROTECT

 

for the WRITE Bloc: 

PIN 1 COUT -> CLK

INPUT : WR_DATA

OUTPUT: NEW_WR_DATA

OUTPUT: /WR_DATA

OUTPUT: SPI3_SCK

 

Reading the way a GAL works, for register mode we can have only 1 clk source, it means that we can not reuse the GAL when we have different clock sources, thus even if some pins left we can not use them for exemple to replace the 2 counter (LS393 ?) ? is this right ?

 

Vincent

 

 

 

 

 

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
You'd better make decent

You'd better make decent working prptotype and then start optimizing it by reducing the number of ICs with PLDs. The external  ICs could have been eliminated by using lower level assembly language ARM programming for the diskette I/O. 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Ok for the decent working

Ok for the decent working prototype, regarding external ICs I would be really keen to understand how. I have been testing bitbanging GPIO using asm code and it was not fully accurate in term of cpu cycle & timing

 

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
After some testing, This is

After some testing, 

This is working to suppress the LS123

Signal Comparison between LS123 output and LS74 using the schema above

We can easily then suppress the LS123 for the read part, what is more tricky is how to remove it for the write part... (without adding new ICs)

EDIT: TIMER_8MHz is actually on a 9 (10-1)/ 5 period => 6.4 MHz

 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Some comments on the recent hardware mods

What you have built in post #139 is a digital oneshot. Which is a valid and good approach. But you should never leave tristate buffer outputs float, if used as a gate. The always must be a pullup resistor (for Z->H) or a pulldown resistor (for Z->L). Sizing will depend on the load. For a pulldown use 330 Ohms or less if the load is a single LSTTL input.

 

A similar approach based on a counter can be used to substitute the other oneshot. The 74LS393 has two independent counters in it.

 

I need some time to digest your schematics, and I'm very busy right now as I have found yet another bug in the IWM, at least it looks like it. Not a bug in my substitute, mind you, but a bug in the real IC as used by Apple. These are nasty surprises because they throw the 'state machine' equivalence tests off track. I need to develop the theory how the bug came about, and this costs time. More in my IWM thread. Will post info there when I have more time.

 

As for the PLD substitute, it may be possible to put all TTLs into one PLD. A 22V10 has 10 macrocells, so it can make 10 output functions. A EP610 has 16 macrocells, and there are larger ones.

 

The benefit of TTLs is that no builder of your floppy emu needs to source a programmed PLD. The downside of TTL is that circuit changes are tricky, so people can't update  / upgrade / experiment / hack the emu without cutting PCB traces, piggybacking ICs, and adding flight wires. It's a mess, as you can see on your plugboard. PLDs can be changed by just reprogramming them, for which a programmer is needed. BUT, you already have a part in your emu which needs dedicted programming hardware, the ST32. So the "programmer" problem is already here and the best solution is that you make a kit with the pre-programmed ICs and the naked PCB. The other components can be sourced by the builder. This would keep weight of the parcel (postage) and customs fees down. Making the project "open source" as you do at the moment is a noble intent but I believe it does not help the typical builder interested in the floppy emu to get one. The PCB alone is  a big headache as it only will be "cheap" if ordered in larger numbers. Even at JLCPCB the "prototype" runs of small PCBs in small quantities are pretty expensive. If you offer a kit and order, say, 50 PCBs, one of them may cost only $2 ... $3 (just an estimate based on the Apple-1 ACI card). Note that PCB costs depend on area and number of drills. This is why a TTL based solution will drive up PCB costs. The PLD solution will allow for the smallest possible PCB and hence, may be cheaper, quicker to build, and more easily modified.

 

For the moment I'd recommend you to focus on testing the various WOZ files with the existing hardware, and not start changing the hardware yet. There may be surprises during the testing and these may lead to hardware changes, and then, the optimization efforts on the hardware may be obsoleted. You have a working platform, use it for the tests, and keep a protocol what works and what does not work. Do not attempt to fix everything after one WOZ file fails ... get all tests done so you have a complete picture and then analyze the causation(s) and find the fixes. Much more efficient as you will see common patterns / groups of problems which need to be addressed in the same way (per group). Unless everything works with no such surprises ... but I doubt you are that lucky. This is a type of project which is difficult because you don't start from a clean slate where you can write all the specifications from scratch. This is the ideal case where everybody would expect turn-key success. But instead, you have the case where you venture into uncharted or poorly charted territory, all these vintage floppy disk protections, full of surprises, and you have to adapt to these unknowns.

 

Much the same situation I have with my IWM reverse engineering project. The IWM is the most poorly documented and most poorly understood custom IC in the whole Apple II world. Full of surprises. But it's out there, as a fact (or, better, "artifact") and so I have to adapt my work such that it reproduces all the bugs of the original IWM, too. Which is nasty and costs a lot of time (now 1.5 x over time budget), but it's inevitable to get a faithful reproduction. I now think that peeling off the mask layers and reconstructing the transistor level netlist may have been the more efficient approach. But hindsight is 20:20, as thay say. You have the same "black box" issue with the WOZ files.

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Hello Uncle Bernie, good luck

Hello Uncle Bernie, good luck with IWM...

On my side, I have moved away from the plug board and have the SBB820 (solder board) up and running with the last schematics. I took me quite a while to make it.

I can now start deep testing but I have to say that testing woz files none are working... (except the unprotected one).

I tried based on the text file : " After you have System Master disks booting, you can move on to some slightly more complex disk images that are copy protected. These are all just basic tests, and not doing anything too crazy. "Bouncing Kamungas", "Commando", "Planetfall", "Rescue Raiders", "Sammy Lightfoot" and "Stargate"

to be true, i am struggling -> I am stucked, this is unknown territory

Quick question: 

- in the woz spec, size of the track is given in the track chunk, do the emu has to adjust the circular buffer size according to this ?

- In woz 2, the size of the track is in bit and can be not a mutiple of 8, how should it be handle ? 

- When moving from one track to another, what is the best approach ? with the adjacent track I can record the current index, should I simulate a delay like the genuine disk II is doing ? 

- I need to have a working reference like an online emulator where I can have trace & debug ? any suggestion ? 

 

 

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
VIBR wrote:- in the woz spec,
VIBR wrote:

- in the woz spec, size of the track is given in the track chunk, do the emu has to adjust the circular buffer size according to this ?

No, the size must be equal to the time of one revolution , e.g.  about 200 mS or some 50000 bits for 5.25" media. If the data is less (which should always be the case) fill the remaining with zeroes or 3470 noise and just "play" the whole 200mS, e.g. your circular buffer.

 

- In woz 2, the size of the track is in bit and can be not a mutiple of 8, how should it be handle ? 

Overlaps with previous qestion -- fill the rest with zeros.

- When moving from one track to another, what is the best approach ? with the adjacent track I can record the current index, should I simulate a delay like the genuine disk II is doing ? 

No. 

 

 

 

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Uncle Bernie's recommendations to post #141:

In post #141, 'VIBR' asked:

 

"- in the woz spec, size of the track is given in the track chunk, do the emu has to adjust the circular buffer size according to this ?"

 

YES. Adjust the track buffer size to the number of bytes in the track (round up to full bytes). Adjust your SPI clock such that the track buffer 'revolves' in 200ms. This is the best way to be as close to a real floppy disk drive as possible.

 

"- In woz 2, the size of the track is in bit and can be not a mutiple of 8, how should it be handle ?"

 

Fill the last byte in the track buffer with zeros, as suggested by retro_devices in post #142. Be aware however, that this may have unwanted side effects unless the WOZ file generator stopped the track at a place where inserting the zeros has no unwanted side effect. This is guaranteed if the bit cell sequence just before the stop has generated a complete floppy disk byte in the DISK II shift register, which is defined by the MSB being set. Any sequence of zero bit cells after such a complete floppy disk byte has no effect on the byte stream "seen" by the software running on the Apple II, except for a small timing delay, which I think is too small to be noticed. If the WOZ file generator did not obey that rule, then adding zeros may cause problems and you would need to copy bit cells from the beginning of the track image to the end, until the condition is fulfilled, and then add the zeros, if needed to fill the last byte. Of course, then the wrap around of the track buffer also would need adjustment. I hope that the Applesauce team did it right ... so that the track always ends with the write splice, where there is no usable data anyways (professionally mastered floppy disks typically have only one write splice per track). In this case there is no concern, and there are no complications, the zero fill will work.

 

"- When moving from one track to another, what is the best approach ? with the adjacent track I can record the current index, should I simulate a delay like the genuine disk II is doing ?"

 

Do not simulate a delay (yet). It is a big complication that can cause more trouble for debugging than it's worth. But it may be necessary for some copy protections to work, which is just a worst case conjecture of mine. If this turns out to be necessary, you need to (crudely) emulate the inertia of the floppy disk head. This means when you detect a change of the stepper motor phases, you need to continue providing the RDDATA stream from the current track for a given number of bytes, and then switch to the RDDATA stream of the final track where the head would be positioned after all the stepping ceases. For "fat track" protections this should be trivial as the track buffer contents is identical. In other words, you continue to play the same track buffer, with no changes or interruptions of any kind, essentially ignoring the head movement. But for "spiral track" protections you need to move to the next (partial) track which will be different, so you need to change track buffers there. At the right moment. And this may be the tricky part ... you should always know where you are as you have a timer always running in lockstep (with the same "RPM", 200ms) as the emulated floppy disk turns. So a simple calculation from the timer will tell you the byte index within any track buffer, where you are. The tricky part is the inertia I mentioned (after how many bytes you change to the next track buffer, this should be a constant in all cases). The big question I can't answer is whether any existing "spiral track" copy protection did give stepper motor phase commands while continuing to read (and check) data bytes until they would fall apart due to the head actually moving. You can study this process (and measure the inertia) using any real, normally formatted floppy disk. Just read a track bytewise to know the sequence and then give a step command at a known point, and record the bytes coming out. The first few bytes should be identical to the known sequence but at some point there will be a difference / garbage. This is the number of bytes which still can be read due to the inertia of the head. Be warned that some Apple II emulator code I have seen does horribly complicated calculations involving ramp up and ramp down of the magnetic fields, calculates the forces, and then with the mass of the head assembly calculates head speed etc. I can't say if this extreme (attempted) fidelity of emulating the head positioning process is really necessary. Being lazy (= efficient) I'd avoid that unless proven to be absolutely necessary. This proof would be a) lots of copyprotections not working unless the head positioning process is so "accurate" and, b), the software title has no 4AM crack available, and c) the software title is an absolute must-be-emulated. I can't say if these three criteria apply to any known software title for the Apple II. In general, I am in favor of the KISS principle (keep it simple and stupid) and it is quite possible that those who coded the sophisticated physics model of DISK II head movement went too far. (I know these types, the same sort who build atomic clocks for the livingroom, which will not deviate more than a few seconds per human lifespan).

 

"I need to have a working reference like an online emulator where I can have trace & debug ? any suggestion ?"

 

There is no online emulator I know of able to do this. What you would need is an open source Apple II emulator which you can hack so it will produce trace files for each floppy disk byte coming out of the emulated DISK II controller (as read by the 6502). The Applesauce website recommends the EPPLE II emulator to support WOZ files, but I did not look into it. You can hack it to produce the trace files and then compare to what your floppy emulator does produce.

 

Don't get discouraged. Proceed step by step, and investigate the easier / earlier copy protections first. If nothing works, there most likely is a fundamental flaw in your code which affects all these titles in the same way.

 

Good luck !

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
retro_devices wrote:VIBR
retro_devices wrote:
VIBR wrote:

- in the woz spec, size of the track is given in the track chunk, do the emu has to adjust the circular buffer size according to this ?

No, the size must be equal to the time of one revolution , e.g.  about 200 mS or some 50000 bits for 5.25" media. If the data is less (which should always be the case) fill the remaining with zeroe

Hello retro_devices:

I am working on Bouncing Kamungas image from Applesauce collection

the size of each track is the following for woz 2.0 : 

 

and for woz 1.0:

it is above the 50.000 bits 

What is the best approach ? 

- A / copying the full track eg: 51.000 for track 0 and adjust the timing to 3.920 us instead of 4 us

- B/ copying the full track and no timing adjustment ?

- C/ copying only 50.000 and cutting the remaining 1000 bits ?

I will do some testing for the 3 cases

I found as well and opensource emulator in js that is able to read this woz file sucessfully AppleIIjs

 

EDIT 1: none of A, B, C is changing anything...

 

 

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
Keep the bit period of 4uS

Keep the bit period of 4uS and make the buffer equal to the largest track bit size, e.g 51008 bits. This will make "diskette" rotation period of about 204 mS which is well within physical drive's 2% tolerance. In fact Locksmith Speed test has an option to adjust the drive speed to "Recommended" which in practice is slower than 300rpm to be able to accomodate more bits.

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
OK thanks,  When I use the

OK thanks, 

 

When I use the track size, I go from track 0 to track 3 and then it stopped

Ph=physical offset,

Newtrack = current track

DMA_SIZE=track size in the tx buffer;

d1 is the number of CPU cycle (64MHz) to load the main track in the TX buffer, 

d2 is the number of CPU cycles to load the adjacent track

 

ph:04 newTrak:01, prevTrak:00, prev_woz_trk:00-01-02 woz_trk:00-01-02 1 M1:0 P1:2 op:1-1-1 DMA_SIZE:6372 d1:72771 d2:58ph:08 newTrak:02, prevTrak:01, prev_woz_trk:00-01-02 woz_trk:03-01-02 2 M1:1 P1:0 op:1-1-0 DMA_SIZE:6372 d1:72775 d2:845498ph:12 newTrak:03, prevTrak:02, prev_woz_trk:03-01-02 woz_trk:03-04-02 0 M1:2 P1:1 op:1-1-0 DMA_SIZE:6372 d1:72813 d2:848076

 

When I use the largest track 51008 it stopped at track 1,

ph:02 newTrak:00, prevTrak:01, prev_woz_trk:00-01-02 woz_trk:00-01-02 0 M1:2 P1:1 op:1-1-1 DMA_SIZE:6375 d1:72662 d2:63ph:04 newTrak:01, prevTrak:00, prev_woz_trk:00-01-02 woz_trk:00-01-02 1 M1:0 P1:2 op:1-1-1 DMA_SIZE:6375 d1:72769 d2:62

 

It seems that track size is really important, but it is not the only issue i am facing... any advice ?

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
If you run Locksmith disk

If you run the Locksmith's disk Speed test with STM does it work like with a physical drive and diskette?

Offline
Last seen: 1 day 4 hours ago
Joined: Apr 1 2020 - 16:46
Posts: 948
Beware the RPM speed issues !

In post #145, 'retro_devices' wrote:

 

" Keep the bit period of 4uS and make the buffer equal to the largest track bit size, e.g 51008 bits. This will make "diskette" rotation period of about 204 mS which is well within physical drive's 2% tolerance. "

 

Uncle Bernie comments:

 

Seems we get into a situation where several 'cooks' spoil the soup by not agreeing about proper procedure. Which is the following:

 

- for all READ operations, the proper procedure is to adjust the SPI clock / bit cell rate such that one track takes exactly 200 ms ... as the real, ideally adjusted drive does. With more than the 'normal' amount of bytes in the track, you need a higher clock rate. This mimics exactly the situation where a copy protection used a mastering machine which could write higher bit cell densities. The floppy disk drive of the user ALWAYS would be assumed to run at 300 RPM. Unless you mimic this behavior by adjusting the bit cell clock rate, your floppy emulator will NOT emulate this situation properly.

 

- for WRITE operations involving longer than normal tracks (in terms of number of bytes on the track) you need to increase the track buffer size such that it can hold all the bytes needed. This is because unlike a floppy disk mastering machine, the Apple II can't change bit cell density - the clock of the DISK II controller is not programmable. LOCKSMITH could not write copy protection involving 'longer tracks' unless the RPMs were dialed down for the writing process. The same trick was used for the Atari copyprotections with 'long tracks' where the RPM had to be dialed down from 288 RPM to 270 RPM (-6.25 %), hard at the limit for later readback at 288 RPM.

 

The bottom line here is that there it no 'fixed' track buffer length and no 'fixed' READ mode bit cell frequency which could serve all situations. You could of course reserve space for the largest track buffer that could happen, but then program the DMA such that the 'empty' or 'unused' bytes in it are not presented to the Apple II during READ mode.

 

- Uncle Bernie

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
Thank you both, I have

Thank you both, 

I have managed to adjust the SPI clock based on the track length but with no luck in my ability to run the simple image...

I have also check the epple code, nothing special inside it... nothing done crazy, 

 

I have run locksmith and it indicates that the drive is too fast, how can it be as I am strictly following the 1us every 4us... 

I have no clue why ...

Vincent

 

Offline
Last seen: 11 hours 49 min ago
Joined: Jan 31 2024 - 06:40
Posts: 158
How fast? That is an

How fast? That is an indication of the problem with your firmware. Could you post a screenshot and tell wich range was selected.

Online
Last seen: 1 hour 20 min ago
Joined: Nov 19 2023 - 15:28
Posts: 115
My Bad, with the new board

My Bad, with the new board (solder wire), I forgot the WR_REQ to the STM32 so I received to interrupt for writing, thus Locksmith was trying to write but without luck. 

I got better result with the interrupt ;). 

By the way this is the new solder board (that took me 2 days)

 

Running Locksmith: Option 1

then Option 1 

 

And the results are :

 

Unless you tell me I wrong but it seems pretty OK ?,

Changing the frequency of the TIM3 based on the track length is not changing anything on locksmith (very strange),

I have done some testing on the Bouncing Kamoungas image, and I have the exact bit stream corresponding to track 0,1,2,3 on the logic Analyzer...

So I am still lost 

Just a quick one:

the RDDATA (output of the LS125) is pullup with a 1K resistor (like the original analogic board on the DISK II), can it has an impact on the bitstream by shifting by 1 bit the stream ? WDYT ?

I do not know if the bouncing Kamounga is protected by the E7 E7 E7 protection mecanism ?

I truly do not know where to look at.

Vincent

 

EDIT1: This is what I have when I press CTRL+RESET after the endless black screen... (very frustrating)

 

 

 

 

 

 

 

 

 

Pages

Log in or register to post comments