exxos's Atari, Amiga & retro forum

Same here

stephen_usher wrote: 08 Dec 2023 12:18

rubber_jonnie wrote: 08 Dec 2023 12:01 Looks interesting, it'd be good to see it running.

Same here. I won't have time tonight and anyway I need an SD card, which I've ordered from Amazon with delivery tomorrow. I won't have much time tomorrow either as I'm in work most of the day upgrading one of our virtual windows servers (2012R2 -> 2019 -> 2022).

Good luck with the upgrade!!!

Thanks! I think I'll need it. At least as it's a virtual machine I can revert the snapshot.

stephen_usher wrote: 08 Dec 2023 13:45 Thanks! I think I'll need it. At least as it's a virtual machine I can revert the snapshot.

Yes, that's always a bonus :)

Managed to find time to plug the QIMSI into the QL without a microSD card before going out this evening. It seems to work as in the ROM shows up at boot time and it tries to read the SD card slot and gives an error.

By the time I get home from work tomorrow I should have a microSD card delivered (al the microSD cards I have had have died) and I can then play.

stephen_usher wrote: 08 Dec 2023 18:10 Managed to find time to plug the QIMSI into the QL without a microSD card before going out this evening. It seems to work as in the ROM shows up at boot time and it tries to read the SD card slot and gives an error.

By the time I get home from work tomorrow I should have a microSD card delivered (al the microSD cards I have had have died) and I can then play.

Yaay.

:yay:

Well, the SD cards arrived today so I set about getting the QIMSI unit working.

I almost immediately hit a problem. Whatever SD card I used and however I copied the hard drive image onto the SD card I couldn't seem to see the drive. It would just half access the floppy drive. I went around in circles. I posted on the QL Forum (and managed to upset the card builder who thought it was a criticism for some reason).

It turns out that if you boot from a non-Microdrive device the interface has to trick the OS into thinking it's a Microdrive by renaming the device, and then after it's loaded the boot program reset the devices in the system variables. Now, I had my system booting from floppy, so the floppy interface ROM was screwing things up. e.g.



This is only alluded to in the in a brief note at the end of the WIN_USE command's description and that it "may" happen. So,unless you were looking to use the WIN_USE command to rename the device you'd probably never read it, which is why I missed it. The fix is to run the WIN_USE command after boot without a name to re-register it in the system. Slightly annoying and makes writing foolproof boot programs on floppy impossible but not a deal breaker.

The other issue is that you can't format disk images from the QL. Instead you have to create them on an emulator before copying them onto the SD card. This isn't mentioned anywhere in the manual. I tried to clear out one disk image I'd made by copying the one the builder e-mailed to me but it froze the system. The response to this part of the post on the QL Forum was that "as formatting isn't mentioned in the manual you should expect it to work", which is actually the opposite of what a normal user would expect. You would expect everything to work in the same way as other media unless told different. Unfortunately this seems to be a standard developer blind spot where they can't think from the users' point of view.

Anyway, this again isn't a deal breaker, but it would have been nice if the machine gave an error message rather than hanging.

Another documentation failure is the description of the WIN_CHECK command, which checks to make sure that the drive image is contiguous on the SD card. The manual states something about the return value being OK if the image is fine, but it's a command and not a function so it doesn't have a return value. With my experience with properly contiguous files is that it just prints nothing. Maybe if there's a problem it prints a message? I don't know because the documentation doesn't say.

So, is it any good? Definitely. If these issues were either explained up front in the manual or there was a well laid out troubleshooting guide then none of this would have been a major issue. Practically everything has an easy workaround and let's face it the original hardware had enough issues which required workarounds too.

Anyway, here's the machine booting from the virtual hard drive...



I've not tested the mouse port as I don't have a Pointer Environment system set up to use it with and I'd need to find a USB-PS/2 mouse.

Phew! Got the first version of the Computer One OPD floppy interface PCB done and it's now under review at PCBWay.


I wonder if it'll work.

Anyway, here's the schematic.

You've been busy!

The QIMSI seems like it's been a bit of a struggle, hope the card builder understood in the end. After the faffing with my FreHD and finding out things like U2 has to be a non HC chip, and that Q1 needs to be removed and 2 pins bridged, I totally understand when these things are not really covered in the basic info and you need to go digging an pray you find the right info.

Good work on the OPD floppy interface, I may be interested in one once you have it up and running, be interested to see how it all pans out :)

I'm just hoping that the clock circuit actually works for a start. Without that it's just going to be a ROM cartridge with a lot of extra logic.

With this board I'm just verifying the reverse engineering.

I'm thinking that with the Mk.II I'll put the WD1772, clock and FDC logic onto another board, which will make the board which plugs into the OPD ROMpack smaller and put less strain on the connector. It will also allow a future second board which will be a RPi Pico based WD1772 simulation with images held on SD card or similar, so there will be no need to have a Gotek or real drives. I will also put all the address decode logic into a GAL, to reduce the chip count.

Oh, and the QIMSI issues are really about the documentation. I've had someone say on the QL Forums that it shouldn't be up to the hardware developer to write documentation, they have better things to do. *sigh* Silly people. Only the designer really knows the foibles and work arounds for the device.