New project - Pico based SIO device...

[woj]

So, the last two "Iron" files worked fine on NTSC too, it was really entertaining to see the whole program load in one long high baud (did not check how high) block, awesome!

 

The next thing on my todo list was seeing if I can make the Turbo D file work that @w1k posted in the Altirra thread @phaeron. I got somewhere with it, as in I think I managed to wire the Pico up to the correct joystick pin and the loader did show some signs of life when the CAS files was played back (which also means that motor detection was OK), but it did not load, it did not even seem to try (= did not recognize any header or anything). But then, hence the tag above, despite using the same settings as w1k did, I was not able to make it load in Altirra either (I run it with Wine on Ubuntu on a non-cutting edge laptop). So tracking down what is going astray and where is very difficult.

Edited July 7 by woj

[w1k]

1 hour ago, woj said:

So, the last two "Iron" files worked fine on NTSC too, it was really entertaining to see the whole program load in one long high baud (did not check how high) block, awesome!

 

The next thing on my todo list was seeing if I can make the Turbo D file work that @w1k posted in the Altirra thread @phaeron. I got somewhere with it, as in I think I managed to wire the Pico up to the correct joystick pin and the loader did show some signs of life when the CAS files was played back (which also means that motor detection was OK), but it did not load, it did not even seem to try (= did not recognize any header or anything). But then, hence the tag above, despite using the same settings as w1k did, I was not able to make it load in Altirra either (I run it with Wine on Ubuntu on a non-cutting edge laptop). So tracking down what is going astray and where is very difficult.

maybe @baktra can help:)

[woj]

It seems I have a puzzle to solve, anything with the Turbo 2000 KSO format works without a glitch, the Czech T2000 format reads until somewhere in the middle of the first longer block, Turbo Blizzard showed signs of life, but otherwise does not work. Adding the non working Turbo D, there is some bug or timing impressions somewhere. I experimented a lot with the timing parameters, nothing helped, and I work with files tested in Altirra to work.

[ascrnet]

Hi @woj

 

When you have some time, I forgot the games with staged loading.  attached example. 😉

Karateka.cas

 

Regards

Edited July 7 by ascrnet
name user

[woj]

I was testing it with my Popeye, which is effectively staged too, and that worked. But will of course try this one too, just not sure I have patience playing the game to go to the loading parts (if that's how it works, I do not remember I have not really played Karateka much).

 

I got somewhere with the timing issues, just setting the Pico clock to 250MHz instead of the stock 125MHz helped a lot, a 60K file gets to 50% progress statistically, but I am yet to see it load fully. With the PIO in place it should not make any difference, but clearly it does. I need to recheck the PIO timing, clock dividers and what not, there is probably some tiny detail sitting somewhere that throws things off. It is really curious that the KSO method / timing seems to be very resistant to such details, other ones are not. I got really lucky that I started with this one, it was really motivating.

[phaeron]

3 hours ago, woj said:

I was testing it with my Popeye, which is effectively staged too, and that worked. But will of course try this one too, just not sure I have patience playing the game to go to the loading parts (if that's how it works, I do not remember I have not really played Karateka much).

 

I got somewhere with the timing issues, just setting the Pico clock to 250MHz instead of the stock 125MHz helped a lot, a 60K file gets to 50% progress statistically, but I am yet to see it load fully. With the PIO in place it should not make any difference, but clearly it does. I need to recheck the PIO timing, clock dividers and what not, there is probably some tiny detail sitting somewhere that throws things off. It is really curious that the KSO method / timing seems to be very resistant to such details, other ones are not. I got really lucky that I started with this one, it was really motivating.

Both the PIO and the main PLL have fractional dividers that can contribute jitter, but that shouldn't matter at tape speeds. It did matter when I was synthesizing a color subcarrier since the frequency tolerance for that is pretty strict.

 

Might try checking if the PIO FIFO is reporting an underflow (TXSTALL), especially if you're still feeding it by PIO.

 

The other thing to check is what kind of analog waveform you're getting at the joystick port line, since it's harder to drive that at high speed due to the protection circuitry. I ran into this problem in the other direction trying to push 31.5Kbaud to the XEP-80 and worked around slow rise times with precompensation for 0->1 transitions.

[woj]

20 hours ago, phaeron said:

Both the PIO and the main PLL have fractional dividers that can contribute jitter, but that shouldn't matter at tape speeds. It did matter when I was synthesizing a color subcarrier since the frequency tolerance for that is pretty strict.

 

Might try checking if the PIO FIFO is reporting an underflow (TXSTALL), especially if you're still feeding it by PIO.

 

The other thing to check is what kind of analog waveform you're getting at the joystick port line, since it's harder to drive that at high speed due to the protection circuitry. I ran into this problem in the other direction trying to push 31.5Kbaud to the XEP-80 and worked around slow rise times with precompensation for 0->1 transitions.

 

Many of those things crossed my mind in parallel to your answer and I spent most of the day banging my head against the wall. I am still stuck with the Czech Turbo 2000 formats, and I finally seem to have some idea of the problem, but without a working solution yet. The bottom line - I think it is the XIP cache missing the Flash reads. I noticed that when I reformatted the FAT part of the Pico fresh and put only the 4 files I was testing as the only ones and at the beginning of the volume, it suddenly started working much better, so much better that I managed to load a couple of them in one Pico boot session. The other giveaway was that it usually crashes around the same point in the file. Yet another one was that clocking the Pico to 250 MHz makes it better, in fact at all workable. Using DMA with PIO or not does not seem to matter, using different ways of calculating the PWM width and using different divisors for the PIO clock neither (even though in some configurations the stripes on the screen are definitely way off from what they should be, yet it does read in when it does). i do read the file directly from Flash in segments out of necessity, there is not enough RAM to pre-fetch the whole file, I can keep some functions in RAM (but this also has minimal impact). What helped a lot was to actually downsize the read buffer in RAM and read the data in 128 byte blocks only (upsizing it to a very large one made things worse). I think this way the data is ready quicker, while the cache keeps doing its thing while I process the freshly gotten chunk. Furthermore, why the KSO files worked for me so far - they have less different kinds of blocks, essentially one PWMC, one PWML, and one PWMD for each 3K of data in the CAS file. The Czech T2000 files are riddled with small blocks of different kinds, and my program so far is constructed to start a separate block read on each such new block. The Czech T2000 files that are more consistent in structure ("1K blocks" in particular) read in much better.

 

 Now, I know there are some ways to control XIP behaviour and also prioritize core1 which is doing all this work, will need to see where that gets me, but I feel a little bit chased into a corner to be honest.

 

[phaeron]

5 hours ago, woj said:

The bottom line - I think it is the XIP cache missing the Flash reads.

I thought about the XIP cache misses since that was a problem I ran into generating video, but... we're talking about tape here. At 6000 baud, you can expect about 12,000 pulses per second. Even if you only had a buffer depth of 16 pulses, that's ~1.3ms for the XIP interface to read the data. Flash + XIP will contribute some delays but it can't be that slow. Either there's too little buffering on the PIO/DMA side, or too much buffering causing excessively large block reads without enough prefetching on the flash side, and it does sound like the latter is the issue.

 

The flash interface does support an additional streaming interface that is supposedly faster than pulling bulk data one XIP cache miss at a time, but there are some conditions to using it -- and it'll potentially block up the CPUs when they miss the cache, so I'm not sure it'd be good to resort to that yet.

[woj]

15 hours ago, phaeron said:

XIP will contribute some delays but it can't be that slow

And you were right, as usual All of the things we were discussing were contributing to the problem one way or another, however, the culprit was my flawed logic in how to handle forced buffering breaks between blocks to allow to check for the motor stop condition at suitable moments. Bottom line - I was emptying the PIO/DMA queue after every single CAS file record, be it PWMD, PWML, PWMC, DATA, FSK. Together with the in-between file reading from the flash file system this was introducing delays between these blocks, sometimes shorter, sometimes longer, but they should not have been there, period. In some conditions it also caused the motor signal off not to be registered in time nevertheless and the new block being partially played, while the loading needed a break for a heavier INIT call (I used my Popeye for this which has plenty of these). Now the KSO 2000 files were working because they do not require a PWML block after the PWMD to work, and at the beginning of the block the KSO protocol seems to be much more forgiving as far as additional silence goes. The Czech T2000 files have glued together PWMC PWML PWMD PWML for each transmitted block. I finally noticed where the problem is when one of the test loadings failed at the very very end of the file when I was already ready to jump in joy that it worked. Reality - the very very last PWML block from the file was played too late. 

 

Equipped with this diagnosis I made everything to work, all Czech T2000 test files I produced with Turgen now work, using DMA or not does not make the difference, it is also all very resistant to rounding errors in calculating the PWM pulse width by using different clock dividers, and it all works back with the Pico default clock of 125MHz. In fact, it got so well working that I got the Turbo D file (see above and Altirra thread) to work to the same point as Altirra does, and it failed in the exact same way. My serious question to @w1k - how did you make it work on Altirra? Did you post the correct file? Did you post the correct loader? Anything else in the configuration I should know about (NTSC? PAL?). I did invert the signal bit to get to the same place that Altirra does, but otherwise I am clueless as how it could have worked for you.

 

Turbo Blizzard does not yet work, but I presume it needs the data out wired to detect the go condition, I still need to do that, or it has something to do with the fact that it has different pulse order defined and I somehow do not (yet) deal with it the right way.

 

 

[ascrnet]

Hi @woj

 

I attach another example of turbo 6000 but has included the CHAOS loader all in one .cas file.

Turbo 6000 Chaos Loader.cas

 

It works in Altirra "NTSC/PAL" configuring the cassette deck to turbo 6000 and when the name appears press space key. Another point reading the TURGEN documentation made by colleague @baktra is clear the configuration for each type. 😉

 

Regards

[w1k]

11 hours ago, woj said:

And you were right, as usual All of the things we were discussing were contributing to the problem one way or another, however, the culprit was my flawed logic in how to handle forced buffering breaks between blocks to allow to check for the motor stop condition at suitable moments. Bottom line - I was emptying the PIO/DMA queue after every single CAS file record, be it PWMD, PWML, PWMC, DATA, FSK. Together with the in-between file reading from the flash file system this was introducing delays between these blocks, sometimes shorter, sometimes longer, but they should not have been there, period. In some conditions it also caused the motor signal off not to be registered in time nevertheless and the new block being partially played, while the loading needed a break for a heavier INIT call (I used my Popeye for this which has plenty of these). Now the KSO 2000 files were working because they do not require a PWML block after the PWMD to work, and at the beginning of the block the KSO protocol seems to be much more forgiving as far as additional silence goes. The Czech T2000 files have glued together PWMC PWML PWMD PWML for each transmitted block. I finally noticed where the problem is when one of the test loadings failed at the very very end of the file when I was already ready to jump in joy that it worked. Reality - the very very last PWML block from the file was played too late. 

 

Equipped with this diagnosis I made everything to work, all Czech T2000 test files I produced with Turgen now work, using DMA or not does not make the difference, it is also all very resistant to rounding errors in calculating the PWM pulse width by using different clock dividers, and it all works back with the Pico default clock of 125MHz. In fact, it got so well working that I got the Turbo D file (see above and Altirra thread) to work to the same point as Altirra does, and it failed in the exact same way. My serious question to @w1k - how did you make it work on Altirra? Did you post the correct file? Did you post the correct loader? Anything else in the configuration I should know about (NTSC? PAL?). I did invert the signal bit to get to the same place that Altirra does, but otherwise I am clueless as how it could have worked for you.

 

Turbo Blizzard does not yet work, but I presume it needs the data out wired to detect the go condition, I still need to do that, or it has something to do with the fact that it has different pulse order defined and I somehow do not (yet) deal with it the right way.

 

 

hmm, first - sorry for my english..
i dont know.. im used same loader and CAS file i uploaded to my ftp.. then used that cassette settings like on screenshot, then loads cas file, press R, n:* and try..

deathlon TurboD_4000.cas deathlon TurboD_9000.cas

Edited July 10 by w1k

[woj]

5 hours ago, w1k said:

hmm, first - sorry for my english..
i dont know.. im used same loader and CAS file i uploaded to my ftp.. then used that cassette settings like on screenshot, then loads cas file, press R, n:* and try..

Believe it or not, but this was extremely helpful, my mistake was using 'L' to try to load the programs, with 'R' it all works. Current status: Turbo Blizzard works, Turbo D works up to the maximum allowed speed. The last one allowed me to find yet another bug in treating the PWML chunks (I was off by the factor of 2 for pulse duration), the manifestation of the bug was that the Turbo D loader was not able to conclude that file transfer is over and call RUNAD. Another curiosity is that I do not need to invert the bit pulse logic for Turbo D, while Altirra requires it to make it go through, interesting...

[woj]

I spent another longish battle when the Turbo D tapes stopped working all of a sudden, with the same symptom of not seeing end of file. It turns out that at 9000 baud (a) DMA is necessary (especially when running at stock 125MHz), (b) the DMA queue size also matters and I was getting buffer under-runs. And then there was another issue with a delay to allow Atari make its decision on stopping the motor in between blocks, at the same time I now connected the SIO out line and made Blizzard mode properly check for go condition, this improved things there considerably (no more guessed delays needed). Anyhow, it seems I will never get to the disk SIO part this way 😕 

[ascrnet]

Hi @woj

 

I attach two examples of Polish systems, I did it to understand how they work. these .cas include the loader in the same file.😁

Turbo 2000 KSO.cas

Turbo Blizzard Mikroloader 2.0.cas

In turbo blizzard you must press enter and press T (which is yes) , in the other one you must press R and type D:***

Regards

[woj]

9 hours ago, ascrnet said:

In turbo blizzard you must press enter and press T (which is yes) , in the other one you must press R and type D:***

Turbo 2000 KSO is actually what I grew up with, and I am in fact Polish, and this particular one has been already thoroughly tested, seems to be the one most resistant to my stupidity and bugs too. This one also had the very compact cassette boot loader (3 blocks IIRC) and this is the stuff I cannot find. Must be really hard to get, because Turgen does not offer prepending KSO files with it.

[ascrnet]

6 hours ago, woj said:

Turbo 2000 KSO is actually what I grew up with, and I am in fact Polish, and this particular one has been already thoroughly tested, seems to be the one most resistant to my stupidity and bugs too. This one also had the very compact cassette boot loader (3 blocks IIRC) and this is the stuff I cannot find. Must be really hard to get, because Turgen does not offer prepending KSO files with it.

Perfect I didn't know your nationality, but if you check the TURBO-2000-KSO.ATR published in atarionline there are 3 short loaders.

Quote

Pliki zwi¹zane z Turbo K.S.O. i pomocne przy jego u¿ytkowaniu znajduj¹ce siê na dyskietce TURBO-2000-KSO.ATR:

L1 - LOADER1 - wersja do³¹czona do AUTOCOPY.COM - wczytuje "oporne" programy (pierwszy napotkany program z nazw¹)

L1K - LOADER1 - wersja do³¹czona do turbo na kasecie

L2 - LOADER2 - wczytuje "oporne" programy (program bez nazwy)

Would it be one of those or similar?

[woj]

4 hours ago, ascrnet said:

Would it be one of those or similar?

Yes, this is probably what I was after, it did not occur to me to either (a) read the thread carefully, or (b) look inside the ATR files. 

 

In the meantime, I wired up the remaining connections to my Atari (PROCEED & INTERRUPT), I successfully tested Turbo 6000, both your file and a huge one of mine with multiple INIT blocks and pauses. One thing that was required - this one needed to have the polarity of PWM bits reversed, in my implementation, not in Altirra. For Turbo D it was the other way round, but it is clear that I have my bits reversed w.r.t. Altirra for systems that do care about this. 

 

Next one on the list is Rambit, testing in Altirra as I write this to know what to expect. Oh, and I think I did not yet say that Turbo ROM also worked, and Turbo 2600 until the same point as in Altirra with my test file riddled with INIT blocks, I presume that one of the INIT calls is too long for the pauses that Turgen generated.

 

EDIT: Rambit also worked, and also required PWM signal inversion. 

Edited July 11 by woj

[ascrnet]

2 hours ago, woj said:

Yes, this is probably what I was after, it did not occur to me to either (a) read the thread carefully, or (b) look inside the ATR files.

upsss...😅

 

2 hours ago, woj said:

In the meantime, I wired up the remaining connections to my Atari (PROCEED & INTERRUPT), I successfully tested Turbo 6000, both your file and a huge one of mine with multiple INIT blocks and pauses. One thing that was required - this one needed to have the polarity of PWM bits reversed, in my implementation, not in Altirra. For Turbo D it was the other way round, but it is clear that I have my bits reversed w.r.t. Altirra for systems that do care about this. 

 

Next one on the list is Rambit, testing in Altirra as I write this to know what to expect. Oh, and I think I did not yet say that Turbo ROM also worked, and Turbo 2600 until the same point as in Altirra with my test file riddled with INIT blocks, I presume that one of the INIT calls is too long for the pauses that Turgen generated.

 

EDIT: Rambit also worked, and also required PWM signal inversion. 

How exciting that they all work, so everyone can learn about the charging systems that were invented in different parts of the world. 🤩

 

I also attach this Argentinian charger for you to try. 😉

Iljor 2.0.cas

[woj]

22 hours ago, ascrnet said:

I also attach this Argentinian charger for you to try. 😉

That worked too, I also now cleaned up the code a little bit, tested Speedy 2700 mode of KSO 2000, all works. Tried Karateka, it was going fine until boot error caused by the VBI flaw, I don't have the patience to try again. Oh, and fixed a bug that caused ignoring files with a . in the middle of the file name. Ready to move on to next things - proper menus to configure the turbo mode, then ATRs, somewhere on the way I'd also like to have config storing in the flash memory. And some GUI bells and whistles too. 

[baktra]

22 hours ago, ascrnet said:

 

How exciting that they all work, so everyone can learn about the charging systems that were invented in different parts of the world. 🤩

 

Only to realize that they are almost the same...  Long live PWM.

[woj]

No picture or video proof, but (a) I made nice option menu to configure various things including different turbo systems and tested all turbo files on a single Pico boot session, (b) got the first single speed implementation for 'R' and 'S' SIO commands and I can now boot load simple SD ATRs.

[ascrnet]

3 hours ago, woj said:

No picture or video proof, but (a) I made nice option menu to configure various things including different turbo systems and tested all turbo files on a single Pico boot session, (b) got the first single speed implementation for 'R' and 'S' SIO commands and I can now boot load simple SD ATRs.

How nice, and is there room left for the implementation of standard 600 baud recording?😅

[woj]

Small discussion that I need to have, not sure exactly who would have the ground truth for this, but I tag @phaeron, @kbr, @flashjazzcat, and @drac030 who should know something on the topic

 

I am at the moment coding the SIO protocol for the Pico "dry" due to temporarily blocked access to my Ataris. In the various SIO implementations (most notably I look at SDrive-Max, SIO2BSD, and MiSTer/MiST atari drive emulator) I can see different approaches to "out of ordinary" situations. In particular:

 

1. When receiving sector data (or any other additional data for any of the SIO commands), when the checksum does not match, one approach is to return 'N'ack, the other one is to go silent. Altirra HW manual says the latter should be the approach, but that's only clearly stated for processing the command SIO, it is not at all clear to me that this should be a universal approach for all host-to-device data communication. I do not have an instinct for this one.

 

2. When processing sector read command, even if there is an error at the point of retrieving the sector data after initial 'A'ck, the data should be sent back nevertheless, even after 'E'rror. So far so good. But, one implementation cuts this sector data down to 128 bytes, regardless of what the requested sector size was, the other one sends the amount that was initially requested. My instinct here is on keeping the initial sector size.

 

3. This is also not consistent across implementations - if the requested sector (read or write, does not matter) is out of range, should that be processed initially right after the command message, and 'N'acked if needed cutting any further communication, or delayed until trying to actually read / write the sector and signaled with 'C'omplete/'E'rror accordingly. My instinct is on 'N'acking early when I know already the request is out of range.

 

I know one answer to this is "try it out", but to be honest cooking up an according test case is way more work than just asking.

 

I did not yet fully get to the PERCOM read/write side of things yet, but I can see there would be similar concerns approaching me too.

[phaeron]

26 minutes ago, woj said:

Small discussion that I need to have, not sure exactly who would have the ground truth for this, but I tag @phaeron, @kbr, @flashjazzcat, and @drac030 who should know something on the topic

 

I am at the moment coding the SIO protocol for the Pico "dry" due to temporarily blocked access to my Ataris. In the various SIO implementations (most notably I look at SDrive-Max, SIO2BSD, and MiSTer/MiST atari drive emulator) I can see different approaches to "out of ordinary" situations. In particular:

 

1. When receiving sector data (or any other additional data for any of the SIO commands), when the checksum does not match, one approach is to return 'N'ack, the other one is to go silent. Altirra HW manual says the latter should be the approach, but that's only clearly stated for processing the command SIO, it is not at all clear to me that this should be a universal approach for all host-to-device data communication. I do not have an instinct for this one.

The original SIO specification in the OS manual says that the device can either NAK a corrupted data frame or ignore it, but I'm not aware of a device that does the latter -- the 810 and 1050 both NAK the data frame. Practically, it's better to NAK than to ignore, as ignoring leaves the computer hanging until it reaches the non-format disk operation timeout of $0F (960 vblanks). NAKing the data frame causes the OS to initiate the device retry immediately.

 

There is less consistency on whether a bad command frame should be NAKed. If the checksum is good but the command ID or parameters are invalid, then often devices do NAK. However, if the checksum is bad, then they generally shouldn't because this can cause multiple devices to respond and collide on the SIO DATA IN line. The SIO specification says that a bad command frame should be ignored; the 1050 drive, 1029 printer, and 1030 modem do so, but the 810 drive and 820 printer will NAK a command frame with a bad checksum if the device ID matches.

 

26 minutes ago, woj said:

2. When processing sector read command, even if there is an error at the point of retrieving the sector data after initial 'A'ck, the data should be sent back nevertheless, even after 'E'rror. So far so good. But, one implementation cuts this sector data down to 128 bytes, regardless of what the requested sector size was, the other one sends the amount that was initially requested. My instinct here is on keeping the initial sector size.

I'm not aware of various drive behaviors on this point, but my inclination would be to match the current density if it is known, for a similar reason as for not ignoring a bad data frame: the computer will be waiting for a data frame with length corresponding to the expected sector size. If the drive mismatches it, then the result will be reported as either a checksum error (long > short) or a timeout instead of the device error that should have occurred.

 

26 minutes ago, woj said:

3. This is also not consistent across implementations - if the requested sector (read or write, does not matter) is out of range, should that be processed initially right after the command message, and 'N'acked if needed cutting any further communication, or delayed until trying to actually read / write the sector and signaled with 'C'omplete/'E'rror accordingly. My instinct is on 'N'acking early when I know already the request is out of range.

 

I know one answer to this is "try it out", but to be honest cooking up an according test case is way more work than just asking.

A major factor here is whether the drive knows the current density, and thus the sector count, when it processes the command. An 810 does, because it only supports one disk geometry, and the 1050 does because it checks the density as soon as a new disk is inserted. They can therefore NAK the Read Sector command immediately if it has a bad sector number.

 

The XF551, on the other hand, doesn't do density detection until a read/write operation occurs. This means it can ACK a request to read sector 1024 in enhanced density or DSDD, only to discover that the current disk is single density and fail the request with Error instead of a NAK. This is part of the XF551's well known stubbornness in switching densities.

 

There are also cases where drives will actually succeed on what should be an invalid request. The more sensible case is when Read Sector has been overloaded as a Read Memory command, as the Happy drives do. The less fun case is because of bugs in the firmware, like 1050 rev. E seeking to track 56 on a request to read sector 0.

 

26 minutes ago, woj said:

I did not yet fully get to the PERCOM read/write side of things yet, but I can see there would be similar concerns approaching me too.

The original PERCOM specification is somewhat difficult to find:

https://www.atariarchives.org/cfn/05/07/0073.php

 

However, it isn't of much use, due to practical issues:

• There are very, very few drives that interpret or save all of the PERCOM block. Unsurprisingly, the ones that can store and send back arbitrary contents in all 12 bytes are PERCOM drives. The majority of drives only parse it to a supported density and then resynthesize the block when requested.
• It is not guaranteed that a drive will reject an unsupported format. Many drives don't fully validate the block. PERCOM drives literally just dump it into memory without validating it at all.
• It is not well defined when the drive updates the PERCOM block on its own. PERCOM drives do, because they just mirror the drive control block that the firmware uses to manage the drive. But other drives don't necessarily report a different PERCOM block even when a different density has been detected.
• There are no known drives that use or interpret the last three bytes of the PERCOM block, including the ACIA configuration byte.
• Most references, including the original spec, say that the density byte only has two values, $00 for FM and $04 for MFM. This is incomplete as there are also $02 and $06 values for double rate FM and MFM. The SpartaDOS X formatter uses these values when asked to format a 77 track 8" disk.

 

[woj]

Super, this all more or less tells me how to proceed. Thanks for the comprehensive info on PERCOM blocks, I did read the section in your manual @phaeron in the meantime. The bottom line / approach for me is that for writing / formatting I will only support well defined fixed size ATRs up to 360K in size. That means (a) I can pre-verify the read/write sector operation right away after the command frame and send 'N'ack when needed, (b) I can have predefined / hard-coded PERCOM configurations and 'A'cking PERCOM writes only for writable known geometry disks and only ones that agree on the geometry parameters, 'N'-acking everything else. Sounds like an easy to execute plan that will nevertheless provide reasonable functionality / usability. The other approach is that of SDrive when the size of a newly created ATR is undetermined until a format attempt (or so it seems it does by looking at the source), that is no-go due to complications / wide range of parameters to handle, but also due to limited size on the Flash, which is only 1MB on a stock Pico, or 15M on a Pimoroni Pico, not much in either case to allow for creation of files of size that is not known upfront.

 

And, note taken on 'N'-acking ill-formed incoming data frames and the size of the error-state data frame, with your explanations it makes perfect sense now. 

 

(One last design decision I need to make is how to handle XEX files: it seems typical to emulate an ATR with a skeleton DOS file system for the Atari software to be able to read the XEX as a file from a DOS, my first instinct was to just use the k-loader with no traces of a proper file system whatsoever, essentially a boot-only ATR with the game. My own argumentation for the second solution is some tiny fractions of loading speed added).