WiP Raspberry Pico Microdrive Hardware Emulator

[TomD]

Hello Tom, your device looks very interesting! Is it possible to tranfer .tap-files to the SD-Card or do you at least intend to extend your drive to this option?

I've created some code to transfer tape files to MDR but it isn't something you can use to get games to work, at least not without re-writing the basic loader if it even has one. Z80 snapshots are a much better source for games which it fully supports. The TAP transfer literally transfers the tape blocks to the MDR cartridge.

TAP files are often hacked versions of the originals as the TAP wrapper cannot handle speedloaders, as such they are really no better than snapshots and are often even created from them. Multiload will also never work without changing the code so even if you could load the main block it would still look to the tape for the levels. Best option is some of the 128k hacks for these if you have a 128k machine. TZX is of course an exact copy of the original, but these are unfortunately not supported.

I will add the TAP transfer to a later version, once I've bug fixed the real h/w support.

TomD

[zx-heinz]

Hello Tom,
I like the TAPs. I have added a Vdrive3 to my ZX Spectrum and use TAPs together with this. Of course, if the tap file consists of several parts, I have to split them before.
Where could I find some informations about the mdr - structure? Based on this I could write my own translator from tap to mdr. Usually I use the Math-program MAPLE for that.

And if there are still some bugs with the real h/w support, solving this has priority.

[TomD]

Hello Tom,
I like the TAPs. I have added a Vdrive3 to my ZX Spectrum and use TAPs together with this. Of course, if the tap file consists of several parts, I have to split them before.
Where could I find some informations about the mdr - structure? Based on this I could write my own translator from tap to mdr. Usually I use the Math-program MAPLE for that.

And if there are still some bugs with the real h/w support, solving this has priority.

I've uploaded Z80toMDR to my website if you want to try it out https://tomdalby.com/other/files/TAPtoMDR.zip . Let me know your thoughts and any improvements etc...

Also if you want the MDR spec you can find it here https://worldofspectrum.org/faq/reference/formats.htm

TomD

[zx-heinz]

Also if you want the MDR spec you can find it here https://worldofspectrum.org/faq/reference/formats.htm

Thank you, this helps a lot. Now I can try to create my own MDR created from TAPs and ready for the Oqtadrive.

[zx-heinz]

Thank you, this helps a lot. Now I can try to create my own MDR made from TAPs and ready for the Oqtadrive.

[zx-heinz]

..., once I've bug fixed the real h/w support.

Could you fix the bug meanwhile?

[TomD]

Could you fix the bug meanwhile?

Fixed, however it wasn't a code bug it was due to the hardware with the level shifter unfortunately interfering with the data lines coming from the real Microdrive. The bob-12009 I've used doesn't have the Output Enabled pin to put it in high impedance mode and even though it worked fine with a vDrive the data signal from real h/w isn't as strong and it fails.

Luckily the fix is relatively simple and simply needs you to replace the level shifter with three 1N4148 small signal diodes as shown below:



I've adapted the code to work with the diodes in place of the level shifter and all tests have passed. To use this fixed version download v1.0beta2 from the GitHub site https://github.com/TomDDG/ZXPicoMD

TomD

[zx-heinz]

Thank you for the explanation. Is writing/saving despite of the diodes possible? No pullup (10k) needed? The diodes reduce the voltage only to about 4V. Does this cause no problems? No pullup (10k) needed?

If the pico-lines GPIO0/GIO1 would be high in the resting state, then the load on the data lines would be just 10kOhm, and the real h/w-Ddrive could handle this. How do you think about this?

[TomD]

Thank you for the explanation. Is writing/saving despite of the diodes possible? No pullup (10k) needed? The diodes reduce the voltage only to about 4V. Does this cause no problems? No pullup (10k) needed?

If the pico-lines GPIO0/GIO1 would be high in the resting state, then the load on the data lines would be just 10kOhm, and the real h/w-Ddrive could handle this. How do you think about this?

The diode does not effect the real Microdrive as it only sits between the Pico and the data lines, so the real h/w has a straight through connection. One of the reasons I didn't go with the diodes initially was I was worried the voltage drop would be too high, from the 3.3v of the Pico, for the IF1 to register. It seems I was wrong and it is working fine in the testing I've completed, loaded a few games fine.

For data input i.e. data transfer from the IF1 I use the pull-ups on the Pico, the diode protects the Pico from the 5v output of the IF1 and the Pico pin goes low when the IF1 does. I've tested format, erase, save etc... and all seem ok.

TomD

[zx-heinz]

Congratulation! You did a great job! I hope to get this device soon.

[zx-heinz]

Introducing the ZX PicoMD (I may come up with a better name!)

Did you already choose a better and shorter name for this device to make refering easier?

[TomD]

Did you already choose a better and shorter name for this device to make refering easier?

Not really, I've just stuck to my original thought. We have vDrive & OqtaDrive and somebody has already taken PicoDrive for a Sega MegaDrive project. I did think of pDrive but in the end I prefer ZXPicoMD so it stuck.

Do you have any thoughts?

TomD

[zx-heinz]

Do you have any thoughts?

No, not really. The name it is a bit long but it contains the essential informations. So, let us use ZXPicoMD.
By the way, Schottky diodes would save 0.4V HIGH-level from Pico to the data lines.

[TomD]

No, not really. The name it is a bit long but it contains the essential informations. So, let us use ZXPicoMD.
By the way, Schottky diodes would save 0.4V HIGH-level from Pico to the data lines.

Yes I'm going to try some Schottkys I just didn't have any to hand. It does seem to work fine with 1N4148s but will try the better diodes to see if it improves things. A lower voltage drop may help if the IF1 is more sensitive, I've tested with the two I have and both are ok but have heard some need a bit more voltage.

TomD

[TomD]

Schottky diodes work well, I checked the voltages and a BAT43 gives 3.2V whereas a 1N4148 gives 3.0V. Both work fine with the IF1 in my testing but reckon using the BATs is safer bet.

Anyway I've redesigned the PCB removing the BOB level shifter.



TomD

[zx-heinz]

Hello Tom,
the buzzer could be a bit loader. Is it possible to adjust it? Is the buzzer driven by a transistor? Is a scheme somewhere available?

[dfzx]

I started thinking about how you've got this to work. No code in your github as yet...

I've been doing a bit of high level reading on how the microdrive/IF1 works. It looks like the way to implement a microdrive emulator would be to wait for a "motor on" event, then sit presenting the data from the tape, one bit at a time, onto the GPIOs which represent the clock/data lines which are inputs into the IF1. You just keep doing that for the contents of the MDR file, in a loop, until the "motor off" event. From there, the Z80 software in the IF1 ROM will just do the rest, not knowing the data it's seeing isn't coming from real microdrive hardware.

Is that how you did it? Am I even close? As I say, high level reading, so I may be waaaay off...

[TomD]

Hello Tom,
the buzzer could be a bit loader. Is it possible to adjust it? Is the buzzer driven by a transistor? Is a scheme somewhere available?

Hi, I don't think this is possible although I will experiment with increasing the output current of the buzzer pin to see. I've got two types of buzzer and one is much louder than the other so might be worth trying a different type as well.

TomD

[TomD]

I started thinking about how you've got this to work. No code in your github as yet...

I've been doing a bit of high level reading on how the microdrive/IF1 works. It looks like the way to implement a microdrive emulator would be to wait for a "motor on" event, then sit presenting the data from the tape, one bit at a time, onto the GPIOs which represent the clock/data lines which are inputs into the IF1. You just keep doing that for the contents of the MDR file, in a loop, until the "motor off" event. From there, the Z80 software in the IF1 ROM will just do the rest, not knowing the data it's seeing isn't coming from real microdrive hardware.

Is that how you did it? Am I even close? As I say, high level reading, so I may be waaaay off...

The IF1 sends a series of CLK pulses which the Microdrive (or Pico) is monitoring. There are 8 of them and it knows which Microdrive to use by checking when COMMs is high on each pulse. Once it is triggered the Microdrive starts up. The following image shows the pulses when you type CAT 2, top line is CLK, bottom is COMMs. You can see the CLK pulses and when COMMs is high on the 2nd to last one i.e. 2nd drive.



Chapter 3 of this book (https://spectrumcomputing.co.uk/entry/2 ... drive_Book) has a lot more detail if you fancy a read.

I will release some example code soon, currently too busy adding new features to spend time tidying it up for public release.

TomD

[TomD]

v1.1 released with TAP copy added. This new feature allows you to copy the contents of a TAP file to a blank cartridge. It works with headerless files as well as normal and also strips out the autorun from BASIC files to allow editing, which you will need to do to get the files to load properly from Microdrive Cartridge.

I've also fixed some bugs.

Grab the new version at the usual place https://github.com/TomDDG/ZXPicoMD

TomD

[zx-heinz]

v1.1 released with TAP copy added. This new feature allows you to copy the contents of a TAP file to a blank cartridge. It works with headerless files as well as normal and also strips out the autorun from BASIC files to allow editing, which you will need to do to get the files to load properly from Microdrive Cartridge.

I've also fixed some bugs.

Grab the new version at the usual place https://github.com/TomDDG/ZXPicoMD

TomD

HGello Tom, it works great,. I have tried it with the TAP-version of Ant Attack. After some minor editing it runs on my drive 7. Great!

[Paul]

Hello Tom,
I'm thinking about a Pico based IF1 replacement.
Would you help me with Pico code of Microdrive routines?
Kind regards
Paul

[TomD]

Hello Tom,
I'm thinking about a Pico based IF1 replacement.
Would you help me with Pico code of Microdrive routines?
Kind regards
Paul

Would be happy to. I'm planning on tidying up the Microdrive code (running on the 2nd core) and releasing standalone so people can mess with it. It is all about timing and luckily the Pico comes with some nice routines. Note I used the C SDK and not Micropython.

One of the most useful commands is time_us_64() which allows the code to accurately time the 6us need for each data pulse. Then it is literally sending the two data bit streams checking every 6us if the data line needs flipping. The following image shows the data line output.

[Paul]

Would be happy to. I'm planning on tidying up the Microdrive code (running on the 2nd core) and releasing standalone so people can mess with it. It is all about timing and luckily the Pico comes with some nice routines.

That is great. Thank you very much!

Note I used the C SDK and not Micropython.

So do I.

[TomD]

That is great. Thank you very much!

So do I.

Just to get you started, this piece of code is used to play back the two data tracks. Data to play back is held in buff of length len. This would either be the header or the data block (see chapter 3 of the Microdrive book). You can use the bit counter to put a pause in but I changed this to using the timer as found it worked better. Note the __no_inline_not_in_flash_func which stops the code being run out of flash memory which introduces delays, not good in time critical code.

Code: Select all

#define MASK_DATA1      0b000001 // gpio pin 0
#define MASK_DATA2      0b000010 // gpio pin 1
#define MASK_DATA       0b000011 // gpio pins for DATA1 & DATA2
#define MASK_ERASE      0b100000 // gpio pin 5
#define MASK_COMM       0b010100 // gpio pins for COMMS_IN & COMMS_CLK 

// ---------------------------------------------------------------------------
// playData - playback to data1 & 2 lines with 6us accuracy
// input:
//   buff - the actual data to send over data tracks 1 & 2
//   len - length of data in bytes to send
// return:
//   true - all ok
//   false - stop play back
// ---------------------------------------------------------------------------
bool __no_inline_not_in_flash_func(playData)(uint8_t *buff,uint16_t len) {
    uint16_t data2c=8; // bit count
    uint16_t data1c=data2c+4; // +4 as half a byte offset on track 1
    uint8_t data1mask=0b00000001,data2mask=0b00000001;
    uint8_t data2byte=*buff++,data1byte=*buff++; // load bytes, first byte into data2, 2nd into data1 which has a 4bit offset
    len-=2; // 2 bytes pre-loaded
    bool flip=true;
    uint32_t c=gpio_get_all()&MASK_DATA; // keep current level going
    uint32_t data1=c&MASK_DATA1,data2=c&MASK_DATA2;
    uint64_t lastPing=time_us_64();
    //
    do {
        //toggle the flip and check at the same time, run code if flip now true i.e. was false when comming in
        if(flip=flip?false:true) { // if flip false make true, if true make false...
            // data track 2
            if(data2c<=8&&data2c>0) { // >0 so it stops when data has run out (<=8 so we can use this as a wait loop)
                data2 = data2byte & data2mask ? data2^MASK_DATA2:data2; // if selected bit is 1 then flip data line otherwise keep the same
                data2mask = data2mask << 1; // shift bit mask left 1
            } 
            // data track 1
            if(data1c<=8&&data1c>0) {
                data1 = data1byte & data1mask ? data1^MASK_DATA1:data1;
                data1mask = data1mask << 1;
            } 
            // data track 2 - reset track counters and bit mask
            if(data2c>0) {
                data2c--;
                if(data2c==0&&len>0) { // check if out of data, otherwise reset track counters and bit mask
                    data2c=8;
                    data2mask=0b00000001;
                    data2byte=*buff++;
                    len--;
                }
            }
            // data track 1 - reset track counters and bit mask
            if(data1c>0) {
                data1c--;
                if(data1c==0&&len>0) {
                    data1c=8;
                    data1mask=0b00000001;
                    data1byte=*buff++;
                    len--;
                }
            }
        }
        // flip data tracks regardless every 12us, as long as one of the data tracks is live
        else if((data2c<=8&&data2c>0)||(data1c<=12&&data1c>0)) {
                data1^=MASK_DATA1;
                data2^=MASK_DATA2;
        }
        // wait for 6us to pass, during wait check COMMs & ERASE lines
        while(time_us_64()<lastPing+6) {
            c=gpio_get_all();
            if((c&MASK_COMM)!=MASK_COMM) { // if either COMMS or CLK from IF1 goes low then done
                return false;
            }
            else if((c&MASK_ERASE)==0) { // if ERASE goes low then shift to record
                // ***record routine here***
                return false;
            }
        }
        gpio_put_masked(MASK_DATA,data1|data2); // output data tracks
        lastPing+=6; // move wait on 6us
    } while (data2c>0||data1c>0); // keep going till either track completed
    return true;
}