Tetroid Disk Interface - FORMAT issue

Nagging hardware related question? Post here!
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Tetroid Disk Interface - FORMAT issue

Post by RWAP »

When using microdrive cartridges, I often use the quick ram disk routine to dump the entire contents of a cartridge to ram disk:

FORMAT ram1_mdv1

However, I noticed that after I used this with the Tetroid Disk Interface and the vMap / vDriveQL, whilst the command appeared to work correctly, the files in the ram disk were corrupt.

I have checked swapping the Tetroid Disk Interface for a Trump Card, which works correctly doing the same thing.

Charlie has done some testing and confirmed the problem with both a microdrive cartridge and microdrive image, and also with/without the vMap.

WCOPY mdv1_ TO ram1_ works fine.

Both commands work fine on the Gold Card clone.

It therefore appears to be a bug linked to the actual FORMAT ram1_mdv1 command.

Does anyone have any ideas?


User avatar
Bloodnok
vDriveQL
Posts: 61
Joined: Mon Jul 28, 2014 9:46 am
Location: New Zealand
Contact:

Re: Tetroid Disk Interface - FORMAT issue

Post by Bloodnok »

Did some more work on this and have found the following:

1. Installing the ramprt ram disk driver from a Qpac2 package works as expected on the Tetroid interface so hardware is probably fine.
2. Reverted to an old firmware version for the interface which had TC1.31 and TK 2.23. This was the version with the QUBide driver which took forever to setup the flash. The FORMAT RAMx_MDVx_ command worked fine.
3. Patched the current firmware with the last TC version I could find on Dilwyn's site that was just prior to TC2.17c. This was TC1.36 and TK2.26. It works fine. I haven't tested everything but common functions all work as they should.

Without the source I'll have to stop here. I'll stick to my older version of the TC rom as I'm doing a bit of work with Microdrives these days but would be great to have the more recent improvements available too.

Anyone with the source who can take this further?

Charlie


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Tetroid Disk Interface - FORMAT issue

Post by Silvester »

Sorry if I'm being a bit dim (I've read the above several times), but can you pin down exactly where the problem is?

Is the problem with TC 2.17c firmware (much different from earlier <=1.36).


David
User avatar
Bloodnok
vDriveQL
Posts: 61
Joined: Mon Jul 28, 2014 9:46 am
Location: New Zealand
Contact:

Re: Tetroid Disk Interface - FORMAT issue

Post by Bloodnok »

The problem shows up when using the FORMAT ram1_mdv1 command to copy an entire Microdrive cartridge to ram drive.
The Microdrive content appears to transfer OK but the files are corrupt in the ram drive (reading them back fails).
The command works OK in versions of the Trump card firmware prior to 2.17C.
I'm not conversant with the history of the various TC versions but the last version I found that worked prior to 2.17C was 1.36.

Charles


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Tetroid Disk Interface - FORMAT issue

Post by Silvester »

OK, that makes sense.

I have created source files from TC 1.31+ and TC2.17c so it'll be interesting to see what has changed to the RAM driver to upset FORMAT ram1_mdv1. That it at least goes through the motions is promising.

Unfortunately my TC machine has long since had its microdrives removed and TC adapted to housed QL. Although I have switchable TC 1.36/2.18c but no viable means to attach mdv to test.

I'll try and extract relevant RAM driver code source from both for info.


David
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Tetroid Disk Interface - FORMAT issue

Post by Dave »

Does it also happen if you format ram1_flp1_ or if you format ram2_ram1_?

Can you find the location of ram1_ in memory and look at how the data compares to the original media? Is it a bitwise error, a block error, etc?


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid Disk Interface - FORMAT issue

Post by tofro »

Dave,

there's no such thing as support for "format ram1_flp1_" or the like - For a DD disk, you'd need 720k capacity on the ramdisk, which is practically imposseble. This command works with microdrives only.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Tetroid Disk Interface - FORMAT issue

Post by Dave »

tofro wrote:there's no such thing as support for "format ram1_flp1_" or the like - For a DD disk, you'd need 720k capacity on the ramdisk, which is practically impossible. This command works with microdrives only.
Is that the only limitation? Running out of memory?


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid Disk Interface - FORMAT issue

Post by tofro »

Nah. The main limitation is it's not implemented for anything but microdrives ;)

Such a function would maybe also not bring a lot of benefit for disks - Microdrives can profit a lot from scatter/gather-reading all sectors in one go and then re-organizing into files on a ramdisk. This can copy all of the drive's contents in one single tape loop.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Tetroid Disk Interface - FORMAT issue

Post by Dave »

I apologize in advance for trending close to off-topic.

On an emulator I get little benefit, but on the BBQL I often copy floppies to ram disks because there's a significant speed-up, and if I am playing with large datasets that I manipulate directly, like a database, I find it much quicker and quieter to do it to a RAM copy of the disk image. I don't do it using the format command, but copy flp1_ to ram1_.

The couple of games I wrote weren't that memory intensive, but I still preloaded the image into the ramdisk - super handy. I'm looking forward to getting my Q68 so I'll have a lot more room to stretch my legs - both memory and graphics!

Luckily, it is quite easy to check the ram1_ and flp1_ images against each other. I'm just trying to apply that to this situation to see in what way the data was corrupted.


Post Reply