Yet another Microdrive emulator...
Re: Yet another Microdrive emulator...
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
- 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
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
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.
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.
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
@Morpheus,
Substitute raspberrypi for the actual IP address
Substitute raspberrypi for the actual IP address
- Morpheus
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
Thanks for the reply. I did what you said and I'm getting a "connection refused" response now. Any suggestions?
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
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
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
Hi do I do this or can I do this without opening the Microdrive case again?
R Tape loading error, 0:1
- Morpheus
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
I’ll go back and read Tom’s setup instructions and go from there.
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
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
Code: Select all
journalctl -u oqtadrive
- Morpheus
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
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.
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.
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
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
- Morpheus
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
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...
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...
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
The IP address ssh shows on login is usually the address of the machine from which you connected, i.e. your Linux box.
- Morpheus
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
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.
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
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
- Microbot
- Posts: 125
- Joined: Thu Nov 16, 2017 4:18 pm
- Location: Hurworth-On-Tees, UK
- Contact:
Re: Yet another Microdrive emulator...
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.
R Tape loading error, 0:1
Re: Yet another Microdrive emulator...
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.
Re: Yet another Microdrive emulator...
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.
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
- Manic Miner
- Posts: 332
- Joined: Tue Nov 14, 2017 4:07 pm
- Location: Hamilt[r]on - City Of The Future - NZ
Re: Yet another Microdrive emulator...
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
One caveat of using COPIES is that erasing a file does exactly that - it's only the copy that turns up first
Re: Yet another Microdrive emulator...
Glad you like it
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.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).
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.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.
Re: Yet another Microdrive emulator...
Ah-hah. I was dropping my Speccy folders into the root of the repo folder.xelalex wrote: ↑Sun Oct 01, 2023 10:17 am 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.
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.
Re: Yet another Microdrive emulator...
@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?
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?
Re: Yet another Microdrive emulator...
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.8BitSC wrote: ↑Sat Oct 14, 2023 10:20 pm 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?
Let me look into this. I'll upload a development build when I got something implemented.
Re: Yet another Microdrive emulator...
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.
I agree moving the unwanted files outside of the folder structure which is being indexed, instead of deleting them is a good idea.
Re: Yet another Microdrive emulator...
Re: Yet another Microdrive emulator...
I approve. Thank you.