MicroPicoDrive Popopo's version

[Derek_Stewart]

Also as Derek has posted in the past, he's dyslexic so sometimes his responses are brief and may seem curt, but are not intended to be.

Cheers,
Norm.

Thanks, I do not think I am Dyslexic, which I think is a little strong.

I am a little too abrupt and direct at times.

[NormanDunbar]

Derek,

I can only profusely apologise! I was certain that you had posted in the past that you were dyslexic.

Again, I'm so sorry for this error.


Cheers,
Norm.

[Derek_Stewart]

Derek,

I can only profusely apologise! I was certain that you had posted in the past that you were dyslexic.

Again, I'm so sorry for this error.


Cheers,
Norm.

I would not use that word as I can not spell it. I doubt I have word blindness, as I have done a lot of higher education.

So... back.on topic, can software be distributed on the MicroPicoDrive Cartridge to other MicroPicoDrive owners?

[stephen_usher]

Good morning Popopo,

I have to agree that YouTube videos don't act as good user manuals. You can't print it out and refer back and forwards to specific places as you can with text and sometimes you want to be able to do so without access to a computer. This is where a text file or PDF excels.

Having done a (small number) of YouTube videos, I'm guessing that the work involved is far larger than writing the boring documentation anyway.

[Popopo]

Good morning Popopo,

I have to agree that YouTube videos don't act as good user manuals. You can't print it out and refer back and forwards to specific places as you can with text and sometimes you want to be able to do so without access to a computer. This is where a text file or PDF excels.

Having done a (small number) of YouTube videos, I'm guessing that the work involved is far larger than writing the boring documentation anyway.

That's right.
But there are already doc that anyone could print from the original repo.
I was thinking about PDF but due to the variety of users, I focused primarily on videos cause they break up with languages and interpretations barriers.

Edit:What I am going to write in a PDF will be the manual to use the Bluetooth cartridge and the APP that will go with it (for PC/MAC/Phone)

[stephen_usher]

I've been looking as your boards for use with my bare board QL and it posed a question...

Could this be reduced to a single board with a single Pico acting as two (or more) Microdrives?

You'd need at least one more GPIO pin for the select line from the second MDV socket and enough memory inside the Pico to hold a second image. The firmware would need to be tweaked to be able to select which "drive" the image on the SD card would be loaded into as well.

The reason for the question is that it would simplify and cheapen a twin internal drive replacement board, with only one Pico, set of level shifters etc. and one voltage regulator required. Potentially it would be just another header connection on the board.

[Popopo]

Hi!

Very good questions, let's think about it together and expose son implications.

Could this be reduced to a single board with a single Pico acting as two (or more) Microdrives?

Yes. It may be done. But the big problem is the inner memory. Not enough space for many MDVs images. Actually it would be modified to works like vMap does but by software and set it by the CONFIG file.
The main problem is my lack of acknolowdge about how Pico works internally. Managing DMAs, the Cores and timings. It was something I wanted to study but lack of time I didn't. Moreover when Agustin B. was available he was the genius in that matter. My part was to transform the MDP in something more accessible for everyone and improve it with new features.

You'd need at least one more GPIO pin for the select line from the second MDV socket and enough memory inside the Pico to hold a second image. The firmware would need to be tweaked to be able to select which "drive" the image on the SD card would be loaded into as well.

About the GPIO I don't think you need more. But... if you need it, you have it (two free if I remember right). One set it for sound emulation (but not implemented yet) so you could use it, or the activity led that in my design I keep it for compatibility reasons but actually is redundant since you have the same led activity in the QL (onboard/case LEDs). And another one that you can check in my schema.

The reason for the question is that it would simplify and cheapen a twin internal drive replacement board, with only one Pico, set of level shifters etc. and one voltage regulator required. Potentially it would be just another header connection on the board.

It would simplify the emulation of many MDVs, but ... I would recommend to do it with Pico2 not with Pico1.

Now... let's explain my personal opinion.
Why didn't I implement it?
Firstly because lack of inner memory. That is the main reason.
Secondly there were some bugs in the Pico2 when released that make me doubt about if it is worthy or not to use it in this project.
In any case, the Pico to act like MDVn by the CONFIG file. It implies that some people who wants to place an original MDV in for example MDV2 could find some problems. That would be resolves by CONFIG file yes... but only partially. Daisy Chain... you place the MDP in first place... so it can emulate from MDVn to MDVm. In other places it could not catch the activity/MDSELDN (COMMS IN) signal to previous positions.

All those positions would have the same MDV image. Could be store different images in the other kind of memory? yes. Would it be enough fast to answer in time the system... I don't know.

About power saving... IMO the total power consumption is too low to considering a factor. Cost of some components? the same. If we were a company to produce 100K units, that is another matter. But for a very very little group of users that we are, it means less than few € in materials? really not worthy.

But your idea is nice, to offer the option by CONFIG file to emulate (even if it is with the same MDV image) from MDVn to MDVm, is possible and not hard to implement.
Also could be possible to create a table in the CONFIG file to assign a MDV image to each MDV emulated position. But it takes flexibility on manipulation that not everyone wants.

Instead, sound emulation (but with quality) is more interesting, and the most... Bluetooth MDVs image transfer (something very easy to do too that I didn't do yet, shame on me).

If you see the code, you could modify it easily with your actual skills to implement your idea. But think... it could take out features like copying files from one MDV/MDP to another one and increase the complexity of managing (by the users) the device and also the capability of loading virtual MDV images and real MDV cartridges into your QL.

What do you think? maybe I am missing something relevant.

[stephen_usher]

I'm very sketchy about how the microdrives are addressed to be honest. As long as the Pico firmware can determine which one is being access if could easily theoretically just use that as the active image in memory. Only one Microdrive can be accessed at any one time so the I/O side of the system doesn't need to be changed to support multiple drives.

As for loading MDVs, I thought that memory could be the issue given how little the Pico has. The other issue is having a way for the plug in module to select which virtual microdrive unit to send the image to.

The Pico2 is now up to the 4th(?) revision of the die with a lot of the silicon bugs fixed.

[Popopo]

I'm very sketchy about how the microdrives are addressed to be honest. As long as the Pico firmware can determine which one is being access if could easily theoretically just use that as the active image in memory. Only one Microdrive can be accessed at any one time so the I/O side of the system doesn't need to be changed to support multiple drives.

As for loading MDVs, I thought that memory could be the issue given how little the Pico has. The other issue is having a way for the plug in module to select which virtual microdrive unit to send the image to.

The Pico2 is now up to the 4th(?) revision of the die with a lot of the silicon bugs fixed.

Let's me explain it to you,
Do you remember Ethernet networks with 2 ethernet cards in our old PCs? Tolken Ring?... similar.
Each ULA (MDV) has CommIn and CommOut, that are the 2 most important signals. Let's forget about the rest because are not worthy in about how to sel one unit or another.
The ULA give the signal by MDSELDN to the first unit (IC29), (in abstract way it could be done in many ways, repeating as many High or Low leves as we want to indicate the MDV number, like binary, or Voltage levels, using MDSELCKN, whatever, it doesn't matter now). So let see it want to select the unit MDV2, it gives the signal to IC29 that try to mach that signal with its own one, but it is not so put a 0 on Comm Out, then IC30 read its line COMMs IN (actually same than previous ULA Comms OUT) and identify the ID signal that match its own. So put a '1' in its CommsOut.
To be exact I would need to re-read the service manual again I forgot forgot too fast what I have learnt.

The '1' you can tell feed the base of the transistors that start the engine of MDV2.

This is one of the main reasons why some Microdrives (original) continue spinning even when they are not accessed. Cause due to the lot of accesses some transistors start to fail (eg TR4) what may produce it activate always the motor even when you are accessing to MDV1. It is an example, the reasons may vary with a faulty ULA 2G007 that put always the same level in CommsOut or cannot return to its previous level or put to ground always CommsIN, or a faulty ZX8302.

That is how it works. The service manual explain it in detail and much better than I do.

So, initially in this system the flag is traveling from one MDV to another one, so they doesn't need to know which position they are.
I am MDV1, My commsIN from ZX8302 is high and first SELCLK signal has changed 1 time to high... it is me. The rest has had their CommsIN in low level, so none of them is selected.
I am MDV2, my commsIN from MDV1 is High and SelCLK signals has changed 2 times to high... it is me. The rest has their CommsIN low, even MDV1.
And so on.

About the Pico2... 4th revision? I didn't know it, thank you. How I could be sure I am getting that last one and which bugs are fixed?

[Derek_Stewart]

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.