Yet another Microdrive emulator...

[xelalex]

OqtaDrive 0.5.0 has been released. Changes:

- support for directly loading QDOS Zip archives
- support for renaming & quick formatting of cartridges, available in web UI, command line, and client control (rename only)
- manual page on control cartridges; this gets added when a control cartridge is formatted
- cartridge type now also shown in drive list in client control
- more detailed drive list, improved design, indicate control cartridges, status change optimizations
- improved design for search result list
- indicate progress of repo re-index & software upgrades, prevent concurrent invocations
- drop down menu for choosing upgrade source
- wait dialog for ZXDB search
- misc. fixes & doc updates

[Morpheus]

Hi,
I built a MK1 Oqtadrive a while back and I was using Windows 10 at the time and was able to use it fine. I have since switched to linux and now I have picked up a new microdrive cable thought I would use it again.
I can ssh to the Raspberry Pi OK but I cannot connect using the Oqtactl program on my laptop I get this...

"./oqtactl ls -a raspberrypi:8888
Get "http://raspberrypi:8888/list": dial tcp: lookup raspberrypi on 127.0.0.53:53: server misbehaving"
I have no idea where it get's the IP address from but it's wrong.
I am a total noob when it comes to Linux so any help would be great. I don't want to open the case if I can avoid it as it's in a nice Microdrive case.

[PeterJ]

@Morpheus,

Substitute raspberrypi for the actual IP address

[Morpheus]

Thanks for the reply. I did what you said and I'm getting a "connection refused" response now. Any suggestions?

[xelalex]

I'm getting a "connection refused" response now. Any suggestions?

Connection refused usually means that nothing is listening on the specified port, 8888 in this case. Can you check whether the OqtaDrive daemon is properly running on the Pi?

[Morpheus]

Connection refused usually means that nothing is listening on the specified port, 8888 in this case. Can you check whether the OqtaDrive daemon is properly running on the Pi?

Hi do I do this or can I do this without opening the Microdrive case again?

[Morpheus]

I’ll go back and read Tom’s setup instructions and go from there.

[xelalex]

Hi do I do this or can I do this without opening the Microdrive case again?

No need to open the case, just ssh into the Pi. If you've done a standard installation (which I highly recommend), you can do this once connected to the Pi via ssh, to see whether the daemon is running:

Code: Select all

systemctl status oqtadrive

To see the logs of the daemon:

Code: Select all

journalctl -u oqtadrive

If you've installed differently, you could just run "/home/pi/oqtactl ls" on the Pi. If that works and you get the drive list, the daemon is running, which would mean you're having some sort of networking issue.

[Morpheus]

So I've run the tests advised and I'm pleased to say Oqtadrive is running and active. Is there a where I can get the Pi to tell me which port it's using or the permissions the Pi is using...

I have ordered another couple of Nano's as I have another Microdrive case, pcb and a Pi ZeroW 2 so I can build another and I have some Pico's ready as well.
It's just frustrating... I might pop my Windows drive back in the laptop to see if I have any joy there, I know Linux has a lot of permissions so maybe that is the problem but I want to stick with Linux.

[xelalex]

So I've run the tests advised and I'm pleased to say Oqtadrive is running and active. Is there a where I can get the Pi to tell me which port it's using or the permissions the Pi is using...

Default port for OqtaDrive daemon is 8888. If you haven't changed that during installation, and you could successfully run "/home/pi/oqtactl ls" (without using the -a option) on the Pi, then that's what's being used. If that is so, there seems to be a problem in your network. Could you try the following from your Linux box:

Code: Select all

curl -vvv http://{IP address of Pi}:8888/status

You may have to install curl using the package manager of your Linux distro. Post the output of this command here for further analysis.

[Morpheus]

YAY!!!

Sussed it... used netstat to find the IP address. I was using the address that I had seen when looging into the Pi but it was different to the correct address.
Sorted...

[xelalex]

I was using the address that I had seen when looging into the Pi but it was different to the correct address.

The IP address ssh shows on login is usually the address of the machine from which you connected, i.e. your Linux box.

[Morpheus]

Glad I got it working with everyone’s help, but for some reason it doesn’t like the mdr images, keeps saying they are corrupted and failing a checksum. Even though they work and were created in Fuse and Spectaculator.

[xelalex]

Glad I got it working with everyone’s help, but for some reason it doesn’t like the mdr images, keeps saying they are corrupted and failing a checksum. Even though they work and were created in Fuse and Spectaculator.

How do you load the images, via command line? If so, use the -r option for repair. Emulators are notorious for producing not quite compliant images. When loading from the web UI, repair is activated automatically.

[Morpheus]

I am using the command line and the -r option worked with the mdr images I created, I haven’t got the UI working yet.

[xelalex]

OqtaDrive 0.5.2 has been released. It's mostly a maintenance release, but there's also one new feature: support for Qemulator mdump (V1 & V2) formatted MDV files, as well as MDI files.

[8BitSC]

I ordered a small batch of Tom Dalby's OqtaDrive v1.2b PCBs from PCBWay a couple of weeks ago and received the last of the passives and connectors required to put them together just yesterday.

I assembled one today and I have to admit, it's turning out to be a really enjoyable and flexible device.

The ability to change cartridges on the fly without having to pull out an SD card is delightful; either by uploading from my Mac, from the on-board Repo or wirelessly from the ZXDB.

Being able to download an altered image is cool but what I think it really needs, is the ability to directly update the open MDR image, back into the Repo.

Having to download an image to my Mac, rename and then re-upload the image back to the Repo can be time-consuming. (unless I'm missing an obvious trick).

If I eject an altered image or try to replace it with another, the web-interface tells me changes will be lost and the only way I can see around this, is cancel the image-swap and download, saving the image to my Mac before re-trying to eject and change the cartridge.

The file menu could do with a "Commit" button to write changes back to the currently open image after making a single, cyling backup somewhere in the Repo.

Using my phone, iPad and Mac to load images to the OqtaDrive means I have downloaded images on all three devices. it would be nice to have them stored centrally, back to the Repo.

I found a collection of Game MDRs online and the speed at which most load, seems almost as quick as a DIVMMC device once the BASIC "run" file is located on the virtual tape.

I also like the image optimisation feature. It makes some of my own cartridge images load noticably quicker.

I'm interested to see how the OqtaDrive firmware and user-interface will progress.

[jpnz]

I found a collection of Game MDRs online and the speed at which most load, seems almost as quick as a DIVMMC device once the BASIC "run" file is located on the virtual tape.

You can speed up the seek times by having more than one copy on the cart and this technique applies to other files as well

The system variable 0x5cef (COPIES) supports this, e.g to save two copies of run

Code: Select all

POKE 23791,2: SAVE *"m";1;"run" LINE 0

Saying that, having the two copies of run interspersed on the cartridge would be even better...

One caveat of using COPIES is that erasing a file does exactly that - it's only the copy that turns up first

[xelalex]

I assembled one today and I have to admit, it's turning out to be a really enjoyable and flexible device.

Glad you like it

Being able to download an altered image is cool but what I think it really needs, is the ability to directly update the open MDR image, back into the Repo.

Having to download an image to my Mac, rename and then re-upload the image back to the Repo can be time-consuming. (unless I'm missing an obvious trick).

I think what you what you want is this feature. In essence, any image file that's located within the repo anywhere underneath client/if1 or client/ql will be written back automatically.

The file menu could do with a "Commit" button to write changes back to the currently open image after making a single, cyling backup somewhere in the Repo.

BTW, internal backups of all currently open cartridges are always done by the daemon upon any modifications. So you don't loose changes should you shut down OqtaDrive, even if you don't explicitly save the cartridge before that.

[8BitSC]

I think what you what you want is this feature. In essence, any image file that's located within the repo anywhere underneath client/if1 or client/ql will be written back automatically.

Ah-hah. I was dropping my Speccy folders into the root of the repo folder.

Given that the drive can be used on both Spectrum and QL, it makes sense to have all the Spectrum files in the if1 folder as they wouldn't be much use to a QL anyway.

I follow your logic.

Thank you.

[8BitSC]

@xelalex Alongside the Repo's seach results, would it be possible to add a delete/trash button for MDR images which we'd like to remove?

I mentioned in an earlier post that I'd found a pack of game MDRs and they look like they've been mass-processed using a tool similar to Tom Dalby's Z80onMDR, creating one game per MDR image.

While cool, there's something in the region of 11,000+ files and I'm finding odd ones which don't work properly on either 48K or 128K Spectrums.

Having a button to delete (or move to a hidden Trash folder outside of the Repo subfolders, maybe), so the removed files no longer appear in a search would make it easier to reduce duplication and clutter, allowing us to tidy up images which possibly never worked, or we simply no longer need access to.

I know we could use webdav to remove them (and I've installed Midnight Commander onto the Pi for local file-management via SSH) but having a button alongside the files which are listed among the seach results would mean the removal of files could be done as and when we decide we no longer need a particular image to be listed in the Repo search results.

If not a delete or trash button, maybe a button to Hide/Exclude a file from future searches, which simply moves the unrequired image to a folder outside of the Repo folder?

[xelalex]

Alongside the Repo's seach results, would it be possible to add a delete/trash button for MDR images which we'd like to remove?
...
Having a button to delete (or move to a hidden Trash folder outside of the Repo subfolders, maybe), so the removed files no longer appear in a search would make it easier to reduce duplication and clutter, allowing us to tidy up images which possibly never worked, or we simply no longer need access to.
...
If not a delete or trash button, maybe a button to Hide/Exclude a file from future searches, which simply moves the unrequired image to a folder outside of the Repo folder?

Interesting thought. I agree that this would be useful, in particular for large collections. I would prefer moving undesired images to a special folder that doesn't get indexed, so the search can then no longer find them. Deletion or moving to somewhere else would then be done using any of the other methods, i.e WebDAV or ssh'ing into the box, since I wouldn't want to implement something like a file manager as a sub-function of a search list.

Let me look into this. I'll upload a development build when I got something implemented.

[8BitSC]

Thanks for considering this change.

I agree moving the unwanted files outside of the folder structure which is being indexed, instead of deleting them is a good idea.

[xelalex]

A first implementation is working. I want to review this tomorrow, then upload a development build. I added the move option to the load dialog, since I really don't like lists where each item has the same buttons...

[8BitSC]

I approve. Thank you.