MicroPicoDrive Popopo's version

[tofro]

Hi Popopo,

I was just reading in the original Service Manual, the MIcrodrive data transfer protocols, I thought the explantion was a little difficult to understand. So as par of my Service Manual update, I was going to try and simplify the explanation and maybe introduce a flow chart.

The chain of microdrives basically makes up a large shift register. MDSELDH is what you clock into the first drive, MDSELCKN clocks in what's MDSELDH's state. Depending on where you shift the "1", the drive's motor starts. So, if you want to select drive four, set MDSELDH to "1", and toggle MDSELCKN once (this shifts the "1" to drive one), then set MDSELDH to "0", then toggle three more times (this shifts the "1" to drive four and a zero each to the first three drives. Note if you leave MDSELDH "1" for multiple clock toggles, you can run more than one drive at the same time. If you want to stop all 8 drives, set MDSELDH to "0" and toggle the clock eight times to make sure that zero reaches all drives.

[stephen_usher]

So, potentially an update to the Pico Microdrive emulation has to do is count the toggles and use that to select the image in memory that it's accessing.

I wonder if the simplest method of selecting which image the SD card loads into would be to maybe have two edge connectors, one for each BBQL microdrive location with a switch to tell the Pico which one is occupied. A main PCB with the Pico and a second daughter board with just an edge connector. The switch could be purely on the main board for simplicity. If someone only wanted to replace one internal drive then they just wouldn't have the daughter board.

[bwinkel67]

The chain of microdrives basically makes up a large shift register. MDSELDH is what you clock into the first drive, MDSELCKN clocks in what's MDSELDH's state. Depending on where you shift the "1", the drive's motor starts. So, if you want to select drive four, set MDSELDH to "1", and toggle MDSELCKN once (this shifts the "1" to drive one), then set MDSELDH to "0", then toggle three more times (this shifts the "1" to drive four and a zero each to the first three drives. Note if you leave MDSELDH "1" for multiple clock toggles, you can run more than one drive at the same time. If you want to stop all 8 drives, set MDSELDH to "0" and toggle the clock eight times to make sure that zero reaches all drives.

I didn't realize you could have multiple microdrive motors going at once. But you can only read one at a time.

P.S. likely we won't be playing the Imperial March tough: https://www.youtube.com/watch?v=yHJOz_y9rZE

[Popopo]

So, potentially an update to the Pico Microdrive emulation has to do is count the toggles and use that to select the image in memory that it's accessing.

I wonder if the simplest method of selecting which image the SD card loads into would be to maybe have two edge connectors, one for each BBQL microdrive location with a switch to tell the Pico which one is occupied. A main PCB with the Pico and a second daughter board with just an edge connector. The switch could be purely on the main board for simplicity. If someone only wanted to replace one internal drive then they just wouldn't have the daughter board.

Pretty simple. Yes.
You could define a VAR in the CONFIG file to define which units you want to emulate. That implies some care about conflicts with other units.
In the code as simple as read the CONFIG file VAR and catch the FLAG from ZX8302 with the ticks to do not pass the FLAG to the next REAL drive.
That way you are using mapping by software more than 1 unit.

Something like this protocode:

Code: Select all

ZXCLKCounter = zx8301Clocks();
MDVinit = readCONFIG(initialUnit);
MDVFinal = readConfig(finalUnit);

If (ZXCLKCounter >= MDVinit && ZXCLKCounter <= MDVFinal && CommsIN == High) then RESPOND()
Else if { zx8301Clocks > MDVFinal & CommsIN == Low) then {COmmsOUT = High}
Else { DoNothing()}

In the cofing File you could set the VAR or couple as for example:
VirtualDrive=1,2 ; it catch all signals and responds always that the access signals (MDCLKSEL & MDSEL) are for MDV1 and MDV2 units.
VirtualDrive=1,8 ; it catch all signals and responds always that the access signals (MDCLKSEL & MDSEL) are for MDV1 till MDV8 units.
VirtualDrive=2,3 ; it catch all signals and responds always that the access signals (MDCLKSEL & MDSEL) are for MDV2 and MDV3 units.

That implies the user MUST be careful to DO NOT ocupied MDV2 or MDV3 with other units, or they will clash or hidden.

About the need of another board connected also in MDV2 place, that is not necessary at all. It is a bus where you are telling to the MDP to answer all the time that the selected unit is one of the group defined in the CONFIG file.

So no more hardware would be necessary at all. Be aware... due to lack of memory of Pico2040, all the units will have the same image. That is something like QEmulator does (comparison for better understanding).

Could be possible to have different images? could be but it requires to measure timings to read from mSD and the logic analyzer for that matter. Or just test it. I have not a logic analyzer.

In the code it requires to know which parameter has the responsibility of answering the COMMSIN signal, I didn't dig that much in the code. I was refactoring to let it more legible and understable for other programmers and applying a MVC architecture. So there are a lot of part already improved in that sense with the new capabilities but another part (ASM, Cores Comms & DMA managing) that I dind't touched yet.

Who read my code will find it pretty easy to understand and structured. Also enough decoupled the View from the Controller and Model talking about a part of the code.
Probably a light reading of the part that I didn't touch would tell where is that signal. But till September (middle) I won't have the time to check it out or dig deeper.

[XorA]

I didn't realize you could have multiple microdrive motors going at once. But you can only read one at a time.

Zkul and West do this as part of their copy protection, I have no idea what actually happens on a real machine, but it was a PITA for sqlay3.

[Popopo]

In addition to what commented before...
This has not too much interest unless you would like to load an image whose APP (program/soft) was created to run from... let's say MDV3. But you have not external unit, even your QL has only a MDP in MDV1 pos. That case it would make sense (IMO).

But it loose its meaning when you have the Agustin Beltran MDTools that allows you to change the unit from which a soft was created to be able to run from the unit you want to define.
In case the timing allows to define two MDVs images in one MDP, that could be more interesting in saving some money or space in your QL. Keeping in mind the complexity to make easier to manipulate by the users with the cartridge and its 3 bottoms.

For that purpose, one day that I finish the Bluetooth cartridge (one day... or someone else decide to do it) , it would much simply since it may be done with your phone or the computer with just selecting the images. Breaking out with the nowadays limitations of the cartridge. I was on it, but I had to stopped due personal reasons. I hope to bring it back again because it is a nice puzzle and not hard to implement (to the MDP doesn't care if the cartridge is a real one or a Bluetooth module that transfer files).

Edit:
What could not be a problem is in the case you want to set different MDV images at once in the Config file for the 8 MDVs that can manage the QL. But... since they are going to be loaded when accessed from the QL (dir mdv1_ , load mdv4_boot, whatever...) it will have the effect like if the user ejects the cartridges from the other places at once. So you cannot do operations like: copy mdv1_mybas.BAS mdv2_mybas.BAS

Due you cannot load 2 MDV images at once in the little pico2040 inner RAM and multitasking timing (or maybe yes but barely I can imagine it).

Edit2:
The file/module that seems to me that has the responsability of managing the signals is: MicroDriveControl.c that I didn't manipulate yet in order to keep full compatibility with the original project (and lack of time to be honest )

[Popopo]

I didn't realize you could have multiple microdrive motors going at once. But you can only read one at a time.

Zkul and West do this as part of their copy protection, I have no idea what actually happens on a real machine, but it was a PITA for sqlay3.

Hum... very very interesting.

[tofro]

I didn't realize you could have multiple microdrive motors going at once. But you can only read one at a time.

Of course not. But you can save the wait for the drive to spin up when copying from one to another.

EDIT: And that's of course not going to work, because as soon as a drive spins, it will also send a serial data stream on the DATA1 and DATA2 lines - The drives would garble each other's data.

[stephen_usher]

What I was envisaging was the single board in the mdv1_ position and the daughter board in mdv2_ position, if someone chose to replace mdv2_. Each board would have an edge connector facing the Microdrive slot with some way for the pico to determine which of the edge connectors the SD card board had been slotted into, so as to determine which if the two mdv images to copy the data into in memory.

Reading how mdv drives are addressed above, you would need a wire plugged into the mdv2_ connector to send the signal out to any external Microdrive units.

Assuming that the user only wants to replace the internal drives one for one then the issue of "mapping" drives doesn't arise.

Oh, and for this to work, you'd definitely need a Pico2 for the doubled memory size. However, the advantage is that the Pico2 is rated as 5V tolerant and so you could do away with the level shifters, simplifying the board further.

[Popopo]

What I was envisaging was the single board in the mdv1_ position and the daughter board in mdv2_ position, if someone chose to replace mdv2_. Each board would have an edge connector facing the Microdrive slot with some way for the pico to determine which of the edge connectors the SD card board had been slotted into, so as to determine which if the two mdv images to copy the data into in memory.

I'm afraid, a second cartridge using the same Pico2040, requires also the Screen and bottoms, not only the mSD slot. They requires more pins free than available.

Reading how mdv drives are addressed above, you would need a wire plugged into the mdv2_ connector to send the signal out to any external Microdrive units.

You would not need it as I exposed before, at that matter (if you want to emulate 2 units but with same MDV image with pico2040).

Assuming that the user only wants to replace the internal drives one for one then the issue of "mapping" drives doesn't arise.

I think that I start to understand you.

Oh, and for this to work, you'd definitely need a Pico2 for the doubled memory size. However, the advantage is that the Pico2 is rated as 5V tolerant and so you could do away with the level shifters, simplifying the board further.

That sounds interesting.
So Pico2 are TTL friendly? I would need to study it.