Floppy Emulator?

[TheNameOfTheGame]

I am interested in this project, but what are your plans for a floppy emulator?

I would like something I could replace my internal floppy with and just use an sd card with scp images. And maybe a real drive B could be hooked up externally to dump disks.

I don't care for buttons or lcd screens like HxC did, it would be nice to just have a native ST app that could read the contents of the SD and let the user select the disk image to activate.

Are you planning on something like this or are you going in a different direction?

[AtariZoll]

...
I don't care for buttons or lcd screens like HxC did, it would be nice to just have a native ST app that could read the contents of the SD and let the user select the disk image to activate...

That would be not enough. How will change 'floppy' in middle of some game ? I think that simple solution is what CosmosEx will have - cycle preselected floppies with 1 button. Maybe better instead it to have some 5 buttons, and directly select floppy # - will not raise price much.

In any case, more interesting would be native support for flux level images.

[TheNameOfTheGame]

...
I don't care for buttons or lcd screens like HxC did, it would be nice to just have a native ST app that could read the contents of the SD and let the user select the disk image to activate...

That would be not enough. How will change 'floppy' in middle of some game ? I think that simple solution is what CosmosEx will have - cycle preselected floppies with 1 button. Maybe better instead it to have some 5 buttons, and directly select floppy # - will not raise price much.

In any case, more interesting would be native support for flux level images.

Yes, preselected would work also with a cycle button. If you 100 games on a card it could be a real pain to cycle to the right one so preselecting a "disk set" could help. Is this done with a native app?

And I definitely expect flux level support with Jim's floppy emulator...or were you speaking towards CosmosEx having flux level support? I would like to see it there too

[JimDrew]

Yes, my plan is to have a floppy drive emulator, like HxC but always flux level - not supporting other formats.

Either of the two serial ports could also be a simple push button to cycle through a pre-selected disk images. There would need to be some type of communication between the SCP and the Atari ST - likely using one of the serial ports for this.

[TheNameOfTheGame]

Yes, my plan is to have a floppy drive emulator, like HxC but always flux level - not supporting other formats.

Either of the two serial ports could also be a simple push button to cycle through a pre-selected disk. There would need to be some type of communication between the SCP and the Atari ST - likely using one of the serial ports for this.

My ST only has 1 serial port and I use it for a modem.

[AtariZoll]

Yes, my plan is to have a floppy drive emulator, like HxC but always flux level - not supporting other formats.
Either of the two serial ports could also be a simple push button to cycle through a pre-selected disk. There would need to be some type of communication between the SCP and the Atari ST - likely using one of the serial ports for this.

Serial port is disabled in many cases in games. And lot of other things. Games will kill any resident SW, so SW for giving disk change signal. IMHO, only way is to do selection directly on emulator, manually.

[JimDrew]

I was referring to the two serial ports on the SCP board. The SCP board would be inside the ST, right? So, you could use a simple bit-banged 'fake' serial port using any peripheral line available from the ST with an app that could read the SD media card contents and setup disk images to use with an external button press. You don't actually need to use the ST's serial port. You can create a serial port from any single line that you can toggle. I don't know much about the ST, but with the Amiga we could do this with any of the CIAs, using one of the parallel port bit lines, the LED enable, etc. Even a simple 8 bit micro can control the SCP, so you could have a bunch of buttons to control the SCP.

Can you turn off/on the computer or drive LED via by poking at a register? If so, that would be an easy way to make fake serial port.

[Hippy Dave]

Maybe the emulator could respond to a phony file name (not on the floppy image, and not displayed in directory) by showing a phony floppy that is a directory of disk images.

[AtariZoll]

OK. I see it . But need bidirectional serial port. Floppy select lines are only outputs. Probably printer port would be best. All it is on PSG chip.
Communication could be done via fake floppy transfers too - read/write fake sectors. Then no need for additional lines, perhaps 'only' lot of complications in emulator self

[Jeff_HxC2001]

Communication could be done via fake floppy transfers too - read/write fake sectors. Then no need for additional lines, perhaps 'only' lot of complications in emulator self

This is exactly how the ST select images with the SD HxC Floppy Emulator

http://www.youtube.com/watch?v=bHx14xLwY78

[JimDrew]

Yeah, I suppose you could do something like send a serial command to the SCP on the motor line when the select line is off or something like that. The ST app could read the diskchange/ready line for the input side.

There is no such thing as sectors with SCP. It's raw flux data. When you ask the ST for a sector, the WD1772 grabs the flux data and converts that into sectors. SCP never knows anything about the disk format, sectors, tracks, etc. It's only job is to spool out flux data using the same flux timing that is in the image. The WD1772 would never know it was not getting its data from a real floppy drive. You could use the ST's normal read/write/format commands to read/write to the disk (image) at a flux level.

[AtariZoll]

Jim, you should look schematic of some ST(E), floppy controller part. Get here: http://dev-docs.atariforge.org/
As may see, there is not much line. No diskchange/ready - that makes disk change detection troublesome, and it works not with new, usual floppy drives, btw. There is no usable signal from drive to Atari - all what have is connected to FDC chip. So, you need to use some additional line for that. As said, drive selection line(s) could be used in direction Atari > drive.
Need for additional line may be big disadvantage for average user, who just want to connect it and use.
Is it really so big problem to add some logic, what will supply/decode fake sector data ?
Another thing: all this is not needed in case of some USB floppy emulator, where you do selections on PC.

[JimDrew]

Is it really so big problem to add some logic, what will supply/decode fake sector data ?

It's not physically possible. Remember, the drive itself knows nothing about sectors. It just returns flux bitcell times by clocking high and low on the RDData line. That's it. The WD1772 in the ST clocks in the RDData line and converts those bitcells into MFM and then into normal data. You guys never get to see the raw MFM because the FDC converts it. You only see the end result.

From looking at the schematic of the 1040ST, it appears that SIDE SELECT and DRIVE SELECT lines are the only pins connected between the ST and the drive, everything else is connected between the WD1772 and the drive. SIDE SELECT is connected to U16 (YM2149). That appears to be some type of interface buffer. If that chip has a data direction register, then it would be possible to make the SIDE SELECT an input/output port and then communication could be done from an ST app.

Edit - just looked at the 520ST schematic, and it's much easier to see. PIN21 is IOA0 of the YM2149 chip, which should be able to change the I/O direction and clock in data (or clock it out). This is could be done with the drive select line turned off (deliberately as a gate) and the single line be used for communications.

I didn't realize that the WD177x chip never controls the side selection. I verified this with the CBM 1571 and 1581 disk drives that use the WD1770 or WD1772. So, the line to use for communications would definitely be the side select line.

[AtariZoll]

Using PSG port A as input in some Atari ST(E) is not supported by design. It drives some other things, so especially in case of Mega STE you may expect problems if switch it on input mode. By switching it to input mode, you will break diskchange detection in Vblank service routine for instance. I'm not saying that it is 100% (physically) not usable for that purpose - maybe with careful SW it is. But should do some tests on diverse machines before even thinking about.
Now, that "It's not physically possible" - you want to say that it is not possible that you use microcontroller in SuperCardPro for encoding/decoding floppy data line MFM signals ? I don't think that it is so hard to make code and simple multiplexing HW (if it is needed at all) for that. Surely not much harder than making serial communication code.

[alexh]

Surely when you have a particular SCP image loaded (i.e. the disk image manager) a WRITE of any kind could be used to pass the information to the floppy emulator to indicate which SCP file(s) you've selected on the flash card?

[Dio]

It seems to me the obvious IO for a disk emulator is to read and write sectors to the disk.

e.g. start the controller 'listening' with some predetermined simple strobe operation on the port A lines (say, toggle select, toggle side, toggle select) then read or write sector 127 to communicate.

To present a UI via the ST, the controller would appear to be a disk with an auto folder in it.

[JimDrew]

I think you guys are confused about how this works. All reading and writing is handled by the WD1772 FDC and that "talks" to a floppy drive. Because the floppy drive is being emulated at a hardware level (which is the case for HxC and SCP), there are no "sectors". There is only flux data being used. The WD1772 controls the motor, head step, direction of step, read signal, write signal, etc. The only two things not controlled by the WD1772 are the drive selection and the side selection, those are controlled by the ST directly using IOA0-IOA2. IOA3-6 can safely be changed to an input without affecting anything unless you had a genlock (IOA6 controls that). IOA7 is unused. So, there is no way to bypass the WD1772 and talk to the drive directly. You could access a non-existent track I guess, but I am not sure how the WD1772 handles that. If it doesn't have a fit, you could step to track 100 or something and use that as a virtual directory track to read the contents of the SD card on the SCP/HxC board. This would be a quite a lot of work (if the WD1772 will even allow that), compared to using side select as a bi-directional communication line. But if other Atari's can not have port A set to an input then that would not be an option. There is no way to use "sector 127" because the drive only spools raw flux data and has absolutely no clue about sectoring, that's the job of the WD1772. The drive just outputs a series of pulses, that's it. It's a dumb device.

Edit: the WD1772 datasheet states that the max track allowed is 240, so it is definitely possible use non-standard track numbers (up to 240) as the virtual directory track(s) since we using a max of 80 for normal data. Each track/side would give you 9*512 bytes of data for the directory info. I would have to change the step input routine to set a flag when the track number reached the virtual directory track and build flux data from the SD directory info.

[AtariZoll]

Nobody here talked about bypassing WD1772. Why I said that need MFM decoding/encoding ?
Why you say 'drive' - as I know this is HW floppy drive emulator. Has this 'dumb device' come microcontroller ?
No sectors ? Emulate them Even don't see need to maintain some real floppy structure. You can have a lot of virtual sectors on 1 track ... Sorry, but I really can not add anything more here ...

[DrCoolZic]

Edit: the WD1772 datasheet states that the max track allowed is 240, so it is definitely possible use non-standard track numbers (up to 240) as the virtual directory track(s) since we using a max of 80 for normal data. Each track/side would give you 9*512 bytes of data for the directory info. I would have to change the step input routine to set a flag when the track number reached the virtual directory track and build flux data from the SD directory info.

This value is the max value for a track number in an ID field.

[Jeff_HxC2001]

Edit: the WD1772 datasheet states that the max track allowed is 240, so it is definitely possible use non-standard track numbers (up to 240) as the virtual directory track(s) since we using a max of 80 for normal data. Each track/side would give you 9*512 bytes of data for the directory info. I would have to change the step input routine to set a flag when the track number reached the virtual directory track and build flux data from the SD directory info.

This value is the max value for a track number in an ID field.

In fact the WD1772 can read & write sectors with track ID up to 255. I think that the 240 limitation is for the formating/Write track...

I use the track 255 as control track. This work well in Amiga, Atari ST, CPC,PC, Thomson... More details here:
http://hxc2001.com/download/floppy_driv ... s_mode.pdf

This allows to do fun thing like this : http://hxcmount.atomas.com/

[JimDrew]

Ah... well, there you have it. Moving the head to a non-standard track bypasses the normal operation. That's quite a bit of work to convert normal data into flux data (and vice-versa) though. Using .scp image files and loading the track data into local RAM from the SD media card is all that is necessary for SCP to emulate a floppy drive. I guess I could adopt the same format you are using for the control track. I have not tried my Slim HxC unit yet but it appears from your documentation that you use a contiguous block of sectors on the SD media card and do the normal SPI block read (or multiblock read) command for each block instead of using a FAT32 handler?

[Jeff_HxC2001]

I have not tried my Slim HxC unit yet but it appears from your documentation that you use a contiguous block of sectors on the SD media card and do the normal SPI block read (or multiblock read) command for each block instead of using a FAT32 handler?

Yes the direct access mode is a sector oriented interface. The FAT32 file system handle/access is done by the host computer.

[JimDrew]

Interesting. So you maintain your own "directory" of the files being stored on the SD card during the conversion to HFE, or is that only for the HD emulation?