Floppy emulator

[tnt23]

@FrenchShark

- No, I let output signals float. There is a 3-state buffer between my MCU and the bus, and when the emulator is not accessed, it switches its outputs to Z. I simply didn't care much as it worked for Amiga and PC. I guess both have own pull-ups to accomodate any floppy (with or without line termination).
On the Atari ST, however, the emulator failed as there seemed to be no internal pull-ups. I have added a few in a new revision of PCB because of that ST case.

- My ATmega256 runs at 16MHz. For DD MFM flow, every bit takes 2us, or 32 one-clock 62.5ns instructions. Here is how the output looked in early designs: http://milliways.chance.ru/~tnt23/amiga/mfm.jpg
Now it is much the same, only the "1" are wider.

- I don't do write precomp, mainly for the fact I am not aware of it Can you tell a few words on it?
There is an IDE/Compact flash port in the emulator, which is completely software driven. If I ever manage to use it to attach an external FDD for 'ADF Bakery', I will probably have to deal with write precompensation.

- As far as I understand, HD Amiga floppies deliver the same bitrate of 500 kbytes/sec, only INDEX pulse comes every 0.4 seconds instead of 0.2. If so, chances are good for that specific HD implementation to do on my current hardware.
PC HD can hardly be done on it with 1000 kbit/second flow.

BTW, Amiga Floppy Project (http://www.techtravels.org/amiga/amigablog/) also is based on Parallax chip.

[tnt23]

arnljot wrote:
@tnt23

Have you considered supporting the IPF format of www.softpres.org?

That would make it a "complete" floppy emulator for the amiga

IPF is not an open format. (Or rather, has not been one when I checked their site lately.) Certainly they provide compiled libraries, but not for the AVR.

[tnt23]

Darrin wrote:
This is the first I've heard about this project (I must have had my head burried in the sand) and it sounds great.  You can mark me down as a potential customer.  I certainly wouldn't mind 2 units for my A2000, 2 for my A3000 (which has some really iffy drives that keep "forgetting" they have floppies inserted) and one in a formfactor that allows it to fit into a 5.25" drive bay for use as DF1 with an A1200 tower.

Great work.   :-)

The PCB is more or less exactly the size of a real FDD. The mounting holes, unfortunately, do not match. The whole thing will fit into 5.25" bay, only the LCD and the buttons will be hard to use The LCD is 48mm tall, probably it can be desoldered from the PCB and hacked into 5.25" bay plastic panel along with buttons. (if that plastic panel is wide enough)

[tnt23]

arnljot wrote:

tnt23 wrote:
IPF is not an open format. (Or rather, has not been one when I checked their site lately.) Certainly they provide compiled libraries, but not for the AVR.

Argh, I'm not so keen on softpress. But I am keen on IPF.
Can we ask them nicely? Ask them to start behaving more like good internet amigians, and less like... I'll be carefull so that I don't get smacked over the head with the posting guidelines.

I think I've tried to ask for the IPF internals. Anyway, let's ask them again, no big deal.

But I would like to see the floppy emulator in a 3.5" form factor, and with ADF and IPF read and write capabilities.

In fact, it is alreay size of a 3.5", except for the mounting holes

What are the buttons and LCD screen used for?
For an amiga user I think there should be the following funtionality:
Button 1: Instert empty disk on card (Empty non formated disk is sensed by the amiga
Button 2: Switch between *.adf or *.ipf
Button 3: Cycle between images (, *1.adf|ipf, *2.adf|ipf, etc etc)
I see that button 2 can cycle between more formats for other platforms, and that more buttons can be made to make use of the lcd and add a simple gui. But I think that for day to day usage it should adhere to KISS as much as possible?

The LCD and buttons are mostly for convenient browsing through flash card contents, like this:
http://milliways.chance.ru/~tnt23/pics/misc/IMG_0246.JPG

Different buttons mapping and alternative GUI is possible, although somewhat time consuming to build.

[tnt23]

Darrin wrote:

tnt23 wrote:The LCD and buttons are mostly for convenient browsing through flash card contents, like this:
http://milliways.chance.ru/~tnt23/pics/misc/IMG_0246.JPG

Different buttons mapping and alternative GUI is possible, although somewhat time consuming to build.

That picture looks great.  How is the LCD attached to the card?  I'm wondering if the screen itself can be mounted in various places while the drive itself is stashed inside the Amiga's casing and then linked via a long cable.

LCD is soldered to the board. It also has a backlight module,  both form a fragile sandwich not quite suitable for detached usage. Maybe a separate daughterboard for them, and for buttons and card(s) could be an option.

For an A1200, a small hole could be drilled up from the underside and the screen mounted either directly above the power/drive lights or on the "grill" behind the lights.  On big box amigas, in could be mounted onto a flat plastic cover over the drive bay (and similar for towered Amigas).

I myself feel very sorry for drilling and cutting my Amigas cases
As for the drive bay, seems like it is a bit narrower than the LCD itself (42mm against 48mm).

Attaching the buttons via wire to connectors on the mobo would help too, or at least having additional headers by the buttons to run optional extended buttons would help.  

It is possible to not solder buttons on the PCB, using their  pin holes to solder remote buttons wires. Or even leave soldered buttons in place and solder wires to them from the bottom side of the board. Connectors could be more convenient.

[tnt23]

FrenchShark wrote:
The rule on the computer side is to have a 1K pullup resistor for the inputs. I guess that on the drive side the inputs must have a 4.7K pullup resistor. With your microcontroller, you must drive your signal low or hi-Z, never high. This is for the case you share the bus with another drive.

Probably a buffer with open drain outputs should be used. In my A1200 setup, the emulator and internal DF0: drive seemed to work flawlessly. As far as I understand, only the drive whose SELECT line is active has the right to pull shared bus lines low.

I have seen that scope trace already. I was surprised by the duty cycle. Was it an issue in your design ?

Since it is a high to low transition that counts, it worked even with these timings. Now the duty cycle is strictly 50%.

Apparently, write precomp is used for the innermost cyclinders because of the higher bit density. I still need to document myself on the subject. :-P. The best sources seems to be the patents websites and the floppy drive datasheets.

I will dig the topic. If the precompensation effectively stretches or squeezes timings, it could be handled by just relaxing these when generating/reading bit cell flow.

This a SX-48 (a super PIC) not a Propeller.
The Propeller is eight 32-bit RISC CPUs in a chip with 32KB of RAM and 32 I/Os. It is a perfect fit for this kind of application.

How fast it can be clocked? I was thinking of switching to some low budget ARM chip from Atmel, with at least 50MHz clock rate.

[tnt23]

@arnljot

A separate board for LCD and buttons certainly can be designed. Mounting holes will definitely be moved to right places in the future, this will require components and routing rearrangements to be made.

I don't think AmiKit or Vesalia will be interested in manufacturing the emulator, at least not in small quantities.

[tnt23]

timofonic wrote:
What about joining with the HxC floppy emulator? This floppy emulator is designed for supporting more kind of drives and formats, maybe both can collabore in some way too.

In fact, my emulator supports PC/DD 720K floppy format, too. Tested it on PC under Linux, and on the Atari 1040ST. I think we've talked with the author of HxC emulator before, don't know if the two projects can be merged together. I'd be happy to share whatever knowledge of floppy matter I have gained so far.

I find the TR-DOS support quite interesting. What interface do you use? Do you use a Pentagon or Scorpion? D+ interfaces are compatible with TR-DOS and Beta Disk?

The BDI interface has been the most popular among Russian ZX Spectrum hobbyists. My own DIY Spectrum and BDI boards are well dead since early 90s. I am waiting for a fellow Scorpion owner to test the emulator on real hardware, I have only tested it under Linux with TR-DOS track format.

[tnt23]

Fitting the current version of PCB instead of original disk drive could be slightly unusable on big Amigas. Currently it has its controls - LCD and buttons - soldered on the same PCB:
http://milliways.chance.ru/~tnt23/pics/misc/megadrive256_logo.jpg

[tnt23]

@timofonic

You may wish to check http://zx.pk.ru - a definitely one of biggest ZX resources on Russian net. I think it is quite possible to dig through it (in Russian) and to buy unpopulated PCBs or even fully assembled machines to your liking.

Besides, there's a couple of modern ZX Spectrum replica projects, based on Altera DE1 board or standalone. Check this one: http://zx.pk.ru/showthread.php?t=6679

[tnt23]

alexh wrote:

tnt23 wrote:
Fitting the current version of PCB instead of original disk drive could be slightly unusable on big Amigas. Currently it has its controls - LCD and buttons - soldered on the same PCB

I am not a particular fan of the LCD & Multiple buttons idea. Yes it makes it platform independent, but it adds significantly to the overall cost and as you say it makes it difficult to replace "any"[/i] 3.5" floppy drive.

After all you have a powerful computer and a TV, why do you need an LCD?

Frankly speaking, I don't think $10 would add that much to the whole thing. My perception is that for most vintage computing geeks out there it doesn't matter. I have just bought a 16 years old KickStart 2.05 ROM for my A600 for $20,  isn't that kinda weird? :lol:
On the other hand, having some sort of indication of what disk image is in the drive, and what activity is taking place (and I am very keen to know what track is being accessed you see) seems quite nice and friendly. At least with green backlight.

Yes the TV and computer are there, but only Amiga can directly control most of floppy bus signals in the way it makes possible to arrange some hackish exchange protocol between the host and the emulator. Just like it is done with drive ID thing. When a special controller like WD1793 is used to talk to a floppy, there is little to no chance at all to bypass it. Would an Atari ST be able to work through this scheme I wonder.

The boot image is part binary file, and part interaction with the controller.

This can be tricky, althought it would be a nice challenge of its own to hack that interaction. It would have to be completely transparent for the system, use only those floppy bus lines that are there, and (last but not least) must allow write access, too. And definitely would require a new incarnation for another platform.
I am not sure I would undertake this load of development, really :-)

By keeping multi-disk games in folders on the flash card, you could select between disks by simply pressing the eject button for less than 2 seconds to cycle through.

Another thing is that currently it takes emulator 16 seconds to load the selected disk image into its RAM. So there won't be any fast cycling through those images.

By getting rid of the LCD and extra buttons (and support code) the floppy emulator can be reduced in complexity and mass produced for a low price. (And/Or for a high profit ;-))

Well, the support code is already in there, so it won't cut costs as the MCU won't be any cheaper :-) As for any mass production, I doubt there will be any really mass one.

[tnt23]

Jeff_HxC wrote:
Hi Tim, yours device looks great ! :-)
One question: why didn't you use SDRam in this version like in the first version ?

Hello Jeff, glad to see ya :-) Thanks! My congratulations on your completion of a standalone emulator. It looks pretty fast, do you use specially prepared MFM files to speed things up?

In my old design, an 8Mx8 DRAM chip was used. In fact, the emulator requires 2.5M, so the 4Mx8 or a couple of 4Mx4 DRAMs would also do. Alas, they all are now obsolete. And this 8Mx8 chip would need 3.3 volts so the whole thing ran from 3.3 volts, too, and only at 8MHz.
Dynamic RAM is compact in terms of MCU pins, but rather slow, and has to be constantly refreshed. This all makes accessing it rather slow. Static RAM would probably fit better, but would need more pins, and/or additional latches for its huge address bus.
SDRAM (synchronous DRAM) has to be talked to at speeds that are far beyond the possibilities of simple 8-bit MCU.
So I thought using old 72-pin SIMM modules would be the cheapest way.

[tnt23]

@easy_john

Thanks for review :-)

@alenppc

Both interfaces are almost similar, except for RDY and DISKCHANGE signals. RDY (internal bus pin 34) is used in Amiga mostly to detect drive type on startup, whereas for PC it is an indication of disk presence in the drive. PC also seems to pay no attention to DISKCHANGE, or it depends on the FDC. Currently host type (PC/Amiga) is selectable through the Settings menu.
There are also minor diffrences in using SELx and MTR lines.

As for memory modules, almost any 4M or 8M SIMM should work. There should be no difference if it is EDO or FPM. I have a bunch of 72pin modules, all of them seem to work.

[tnt23]

@PeterSig

To the best of my knowledge, last updates on Megadrive have been reported early in 2008. Probably it is worth mentioning in your table

[tnt23]

PeterSieg wrote:
@tnt23: ok. Are you also planning to release eagle files and firmware on your web side? Looking forward to that..!!

Um, I am definitely not planning to release any Eagle files as the PCB has been designed with P-Cad :-) Probably Gerbers will be made available along with the firmware (at least in binary form), but I cannot tell when exactly this will happen.

[tnt23]

Not really. I've only added a bootloader, to upgrade firmware via SD card, and support for .BKD floppy images for BK Soviet home computers.