Using the HxC Floppy Emulator

[sixxie]

I just tried my HxC with my dragon 64 and it worked flawlessly!

The HxC floppy emulator is indeed a nice piece of hardware.

As most software is on tape format, is there a way to convert it to disk so that it can be used with the floppy emulator?

I always found Duplidisk 2 pretty good. Won't convert everything, but quite a lot. It does often involve trying a few different operating modes, though: check the manual.

Basically, it will try to work around a game's autorun feature and load in the data, then save it to disk with a little preamble that disables DOS, relocates the game where it's meant to be in memory, and then starts it.

(BTW, already uploaded to this site here).

[robcfg]

Hi Sixxie,

Thanks for the tips!

I'll try it when I come back from my holidays.

[prime]

As most software is on tape format, is there a way to convert it to disk so that it can be used with the floppy emulator?

I keep thinking about trying to develop a cart that could have something modern SD/MMC/IDE/CF etc as a storage medium and use that to read cas files instead of loading from tape.

However because of the way the tape system works with rom calls to various locations that don't vector through a common point, this would effectivly mean that you would have to modify the rom. This would not be a problem on a machine with 64K, as you could copy the rom into RAM and then modify it, however on a 32K machine it would be more problematic, as it would entail disabling the onboard device selection and running from an external patched copy of the rom.

This if done correctly could be used to load 99% of the tape based loaders that use rom routines to load, though it would of course fail with anything that tried to use the tape port directly, however I think such things where rare on the Dragon/CoCo.

Cheers.

Phill.

[robcfg]

In the end, the Dragon receives the audio data at a given point.

I think the best thing to do would be to use a small microcontroller that renders the tap file to audio signal and outputs that to the tape connector of the Dragon.

The main problem of such add-on is the user interface for selecting tape images. Sometimes the HxC is a bit weird, they have now a disk image with a file selector for CPC and Atari ST, but that approach couldn't be done for a tape emulator.

@sixxie: Does Duplidisc2 work under XRoar? I get always Tape Input Error....

[prime]

In the end, the Dragon receives the audio data at a given point.

I think the best thing to do would be to use a small microcontroller that renders the tap file to audio signal and outputs that to the tape connector of the Dragon.

Well if you are going to do it that way, saving the audio to a Cd would work just as well

My thought was if the tape routines could be patched to work by talking to a microcontroler through an IO port then it would be much faster than tape and also more reliable, as it wouldn't depend on the analog circuits.

Cheers,

Phill.

[sixxie]

Probably a bit tricky, but how about detecting the address of the appropriate ROM routines, then asserting (pull low) DSD (EXTMEM on the circuit diagrams) to disable device select, and instead map it to some part of your own ROM? You'd presumably need some regular cart ROM anyway to provide the facilities to pick which files you want.

Immediate drawbacks I can see are complexity of the decoding, and those addresses would still be intercepted in 64K mode.

I suppose you could run a tape lead back to the cartridge and use the motor control line to enable interception...

Oh, or actually the cart is going to know when it gets to the end of a CAS file anyway, so it could disable interception then.

Ideas mostly at random...

[sixxie]

@sixxie: Does Duplidisc2 work under XRoar? I get always Tape Input Error....

I've just successfully converted Syzygy, Robin Hood, Time Bandit, Lunar Rover Patrol and Demolition Derby to disk with it, so yes I think it works. There will be (probably still many) programs it fails on though; I failed to convert Frogger - interesting, as it's so old.

The harder method would be to snapshot games after loading and add your own DOS defeat and relocate routine... Probably nothing it wouldn't work on, as you'll always have at least 512 bytes free for your routine (one text loading screen's worth!).

Are there any in particular giving you trouble?

[prime]

Probably a bit tricky, but how about detecting the address of the appropriate ROM routines, then asserting (pull low) DSD (EXTMEM on the circuit diagrams) to disable device select, and instead map it to some part of your own ROM? You'd presumably need some regular cart ROM anyway to provide the facilities to pick which files you want.

It's prolly just easier to disable it for the whole of the $8000-$BFFF area would make mapping it to a rom easier then, but would also mean you'd prolly need different roms for D32/D64, though they are not actually that different. It does help that I have a disassebily of the basic rom which can be assembled as either of the 64 roms, or the 32 rom.

Immediate drawbacks I can see are complexity of the decoding, and those addresses would still be intercepted in 64K mode.

Easy, you just decode writes to the SAM register bits that switch between modes and have them enable/disable the decoding, as you'd not be putting data onto the data bus this should not affect the SAM in any way.

Cheers.

Phill.