The Sinclair QL Forum

The problem with 128K maximum, is that some of the later software is bigger than that already!

Hello Gert, and well done for your research and good work so far

Have you seen the HxC floppy drive emulator ?
The Atari ST, Amstrad CPC & Amiga can use Host control tool software to select on screen the wanted file.
If you use mdv8_ to access a file list, a program loaded from say mdv1_ could then communicate via mdv8_ with the micro-controller allowing the user to select the wanted microdrive image or program.
Yes, to remain compatible with standard QL OS & microdrives you would be restricted to programs / images that are no more than 255 sectors. But there is nothing stopping you from adding a bit of extra code, so that bigger programs could be loaded in 255 sector chunks, then "changing the (virtual) cartridge" via the mdv8_ channel, and loading the next chunk of code

Keep at it. I am looking forward to further reports and hopefully further successes

Mark

Did some serious ARM assembler coding tonight

Translated the cumbersome get_bit routine to ARM assembler and it now works on the LPC11U24 (the 'light' mbed), reading and writing and now even with multiple microdrive images.

Mounted my test MDV1.MDV image on mdv3, ABACUS on mdv4, ARCHIVE on mdv5, EASEL on mdv6 and QUILL on mdv7

load mdv4_boot

edited line 8 to point to mdv4

save mdv4_boot

run

ABACUS starts

typed in some stuff in some cells

saved the sheet to mdv3_sheet1

restarted the QL and ABACUS and read back the sheet...

It is not as fast as a floppy (not yet at least) but it works!

Are mdv1_ and mdv2_ addresses/data also ported out the expansion port?

If so, that could create an ideal situation where mdv1 hardware could be retained while copying everything across, and when the need to read real microdrives was eliminated, the mdv1 hardware could be removed too, and emulated.

Unfortunately not... mdv1 and mdv2 are internal unless the COMMS_IN and COMMS_OUT are internally bridged twice. When the internal devices are selected the outputs of their ULA's are active and trying to overrride them might/will result in 'short circuit'.. (That is why I have put two resistors in series with the DATA1 and DATA2 lines because during testing that happened quite a lot)

Gert

Are you saying no, or are you saying, yes, IF you plug a bridge into the mdv sockets on the motherboard?

Dave,

You can remove any of the internal drives by plugging its cable and bridging its MD_Select line. This does not affect the external ones (except the drive numbers they listen to go down by one). So you could, as you said, replace mdv2_ to mdv8_ with the emulated one, and leave mdv1_ as is.

Regards,
Tobias

Dave wrote:Are you saying no, or are you saying, yes, IF you plug a bridge into the mdv sockets on the motherboard?

Indeed: if you unplug the internal microdrives and bridge the COMMS_IN/OUT of both of them, all device numbers are available externally.

A small video displaying the MD emulator: QL starts, loads and runs the boot program for Quill from mdv7 and reads in a text document from mdv3

http://youtu.be/_8jUSX15Wbk

I have added a reset function for the sector counter so it always starts at zero as soon as the emulated device is selected. It seems a bit faster that way. I have also tried both counting sectors up and down but it does not make much difference in speed.
Loading of a document in Quill is slow as always
Saving a Basic program is done in the background and you can continue working, in Quill it waits until the file is really stored (and verified) requiring several loops of the emulated tape...

Thinking of simple ways to assign an image to a device.. Maybe I could whip up a generated directory for mdv8_ with all the names of the found MDV image files.
By running a SuperBasic configuration program I could write a config file back to mdv8 which can be interpreted by the emulator and reset the devicenames and images as soon as the device is deselected again.

Also need to think up a way to find out what device number we are so mdv8 is always the last in row. Counting the COMMS_CLK pulses and check when the COMMS_OUT signal activates should give a clue how far we are up the chain.

Playing with Eagle resulted in this design:
This board is to be put directly onto the MD connector and the microsd card will sit vertically at the righthand side underneath the edge of the QL.
There are some things to add like JTAG or such, but firmware updates should be doable by uSDcard later on.

Gert