Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: tnt23 on December 07, 2005, 10:15:38 AM
-
Hi,
My name is Tim. I'm a newbie in Amigas (got my first A500 only this summer).
I was so excited to see recent Minimig story that I decided to post my own project details. Although not as mindblowing as Minimig (Dennis, your work is by far the most impressive DIY Amiga story I've heard!), it is probably still fancy enough to mention.
The project's aim was to build a device that would eliminate the floppy nightmare I would've had should I decide to try and see all 600 megs of ADF on my old A500. The device would keep ADF images on some flash media, let me choose and load certain image, mount it and pretend it is real floppy drive.
I've used 8-bit RISC Atmel MCU running at 8MHz, an old 4M 30-pin SIMM for DRAM storage, LCD salvaged from an old Nokia mobile, and a couple of buttons to keep interface minimalistic.
So far the project lets me browse the SD/MMC card (cheating a lot - FAT16 only, no LFNs, no subfolders), load .ADF image, convert it to MFM tracks and run it as if it were a real DF1: drive attached to my Amiga.
While loading floppy image takes decent amount of time, about 30 seconds, converting it to MFM takes good three minutes. There are of course ways to reduce conversion time, like using more powerful MCU or preencoding floppy images, still to be investigated.
I have uploaded a few images should anybody want a look :-)
EDIT: images are available here: http://www.amiga.org/gallery/index.php?u=3561
Regards
Tim
-
Really interesting! You should get in touch with Mr. Catweazel (Jens).
-
Wow, that sounds like a great project! Using FAT is not bad thing, it means the card can be put in a PC for easy transfer of files. I assume the device connects to a standard Amiga floppy connector? And how fast is access to the disk images? And would it be possible to allow access to the files on the flash card like a hard drive as well as mounting it as a virtual floppy, for transferring files that are not in an ADF?
--
moto
-
Thats cool. I have an A500 with a broken floppy drive, and this would make a nifty replacement. Will the final version be able to replace DF0?
-
How many images can be mounted at a time?
-
Sounds cool.
What AVR are you running? I'd guess a low power Mega128 but would be really happy if you said something like a Mega32 (something that comes in PDIP)
With those new AVRs running at 20Mhz can you decrease load times with them perhaps?
-
xeron wrote:
Thats cool. I have an A500 with a broken floppy drive, and this would make a nifty replacement. Will the final version be able to replace DF0?
That's what I am heading for - to fit it into A500 (must really make my mind before ripping it) so that I would have three or four hundred floppies always with me in a size of a single MMC card.
In fact, it should already behave as DF0 or just any of DF1..DF3 if using right select signal from floppy bus (and on external floppy connector only DS1 and DS2 are available).
-
@tnt23:
How fast mcu do you estimate would be needed to convert tracks from the adfs to mfm data on the fly?
/Patrik
-
@tnt23
There is a guy who did something comparable for the C64. The device is called MMC64 - maybe you already know it.
He was also working on it in his leisure time. Then he showed it to Jens and it evolved as a product for the community :-)
Maybe you should also consider this option.
-
motorollin wrote:
Wow, that sounds like a great project! Using FAT is not bad thing, it means the card can be put in a PC for easy transfer of files. I assume the device connects to a standard Amiga floppy connector? And how fast is access to the disk images? And would it be possible to allow access to the files on the flash card like a hard drive as well as mounting it as a virtual floppy, for transferring files that are not in an ADF?
--
moto
Yes, the device connects to external floppy connector, although it is not seen well on the photos. I have a bunch of early development photos, too, showing the connections, running boot intro etc.
As to the speed, I can't tell. I only know there are no moving parts in it, so it should be slightly faster then real drive, if only Amiga can make use if it. I recall running speed test from DiskMonTools, and that gave me something like 24k per second on 64k file. I am not sure about them figures, will rerun test this night.
I don't think it is possible to access certain files on the card directly - at least I don't see how it can be done through the floppy interface. On the other hand, reading SD/MMC is not that difficult, there can be other solutions for it like using RS-232 port, and there probably are.
UPDATE. Speed test shows 24k/sec for 128k file. Puzzingly enough, the Workbench 1.2 floppy loads in 44 seconds, and the emulated one loads in 55 seconds.
-
You're a clever guy :-) Any idea when it will be finished?
--
moto
-
bloodline wrote:
How many images can be mounted at a time?
Now it only allows for one image to be used at a time. There is simply not enough memory to hold more than one. Although it would be terrific to have a set of floppies be prepared in advance, like for multi-disk games, and switch between them at once.
Also it is a read-only solution, floppies can be read from but not written to.
-
You guys are heroes. This and the MiniMig are really cool project. I'm really impressed. Lots of people around me, that are not all Amiga-aware, are quite WOW'd too.
There are so many self-involvement in those project, so many skills needed that it really amazes me.
For example, you gotta have lovely & gentle people around you, that don't mind *not understanding one bit* of what you're doing every night :)
Kudos to all of you, you :pint: and Dennis :pint: are competing for the COOLEST Amiga Hardware projects of the year ! (SW-wise, AROS immetiately comes to mind)
-
Dingo_aus wrote:
Sounds cool.
What AVR are you running? I'd guess a low power Mega128 but would be really happy if you said something like a Mega32 (something that comes in PDIP)
I happened to have ATmega161, a 40-pin DIP chip suitable for most simple projects. First I ran it at 4MHz, than had to go for 8MHz.
I am planning to upgrade to ATmega128 (if they are still in production by the time), mostly because I am running out of IO pins. 16MHz will hopefully speed things a little (say, 20 seconds of loading instead of 30), bit it is the conversion part that is the most heavy one in terms of CPU power. I will look into pre-encoding .ADF into some .MFM format in advance.
-
patrik wrote:
@tnt23:
How fast mcu do you estimate would be needed to convert tracks from the adfs to mfm data on the fly?
/Patrik
Quite a bit I'm afraid. You have to deal with ~12k of data, with bit shifting, masking and checksumming, all within 0.2sec or so.
-
Amiga stays alive as long as theres hackers in the playground.
Nice work
-
When can i buy it? :-P
-
@humppa
Thanks, will look into MMC64 project. I've heard of a similar thing for the VIC-20 I believe, maybe that is it.
-
It's this one: http://www.jschoenfeld.de/news/news103_e.htm
It uses a nice plug-in system and there are some geeks who are developing for it.
There is even a WAV-plugin, so I can have audio "streaming" from the 1GB MMC through my C64. :lol:
You can also use it for writing D64-files (similar to ADF for Amiga) back to a 5 1/4" floppy disk or starting programs.
It takes some time though to fill a 1GB MMC just with C64 stuff. ;-)
-
@motorollin
Really can't tell. I have completed the most tricky part only last weekend - dealing with FAT clusters - and there are for sure lots of bugs and assumtions to be fixed and approved. I am planning to design a decent PCB for the prototype, too.
-
Subdirectories support is almost complete, browsing the directory tree back and forth surprisingly works.
I have completed PCB design for the new prototype, and ordered a couple of boards. The design features MCU with 4K of static RAM and plenty of I/O pins, and also a 8Mx8 EDO DRAM chip. With that much of static RAM I should be able to speed up the MFM coding phase drastically.
Have a happy New Year everybody!
-
Ah, this is great.. Thanks for coming to an English speaking forum to tell us about this too. :-)
I hope you get it finished and into a product somehow (be it diy or sold as ready built)
-
Fantastic effort! Hope you get it finished - this'd make an ideal accessory to turn an A500 or A600 into a fully portable and fully loaded machine without worrying about ageing floppies!
- Ali
-
Yep. Great thing. If that could be made compatible with IPFs, that would be THE replacement for the real drive. I could revive dozens of "dead" machines (mostly dead drives) and turn them in fully equipped gaming machines. Don´t like the new tpes of games anyway...
BTW: That also means that I´d be buying a couple of those...
Cheers
Chris
-
Put me down for two :-)
--
moto
-
You can put me down for one as well. I have just added a standard external drive connector to my A4000T (thanks PaSha for advice). It faces forwards so I will be accessing that MMC from the front 8-)
Edit: my device is df2: will that be a problem?
-
Sounds like something usefull. This device can be the thing to fill the gap between floppys and whdload.
Wasn't there a design from jim brain for the C64 that used compact flash and could connect to the normal serial floppy port of C64. I can imagine it is the same idea but that this device is able to emulate the amiga floppy interface.
http://www.jbrain.com/vicug/gallery/uIEC
-
@X-ray:
I use DF1 since it is available on external floppy connector, but I don't see why it cannot be DF2 or even DF3 :) It is a matter of soldering to the right pin.
-
I LOVE your avatar :-)
--
moto
-
tnt23 wrote:
@X-ray:
I use DF1 since it is available on external floppy connector, but I don't see why it cannot be DF2 or even DF3 :) It is a matter of soldering to the right pin.
The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.
-
PaSha wrote:
The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.
BTW, can big Amigas be booted from floppy other than DF0?
-
motorollin wrote:
I LOVE your avatar :-)
--
moto
I wonder if it can be done in 84x48, mono :-)
-
tnt23 wrote:
patrik wrote:
@tnt23:
How fast mcu do you estimate would be needed to convert tracks from the adfs to mfm data on the fly?
/Patrik
Quite a bit I'm afraid. You have to deal with ~12k of data, with bit shifting, masking and checksumming, all within 0.2sec or so.
Only if you did the work an entire track at a time before you started streaming the data. If you did it all a byte at a time while you were sending the data the processor requirements would be a lot lower (of course getting the timing right would be a major pain).
-
tnt23 wrote:
PaSha wrote:
The DF1: pin on "small" Amigas (A500, A600 & A1200) is the same as the DF2: pin on "Big-Box" Amigas. So no worries.
BTW, can big Amigas be booted from floppy other than DF0?
Depends in the Kickstart AFAIK.
Personal experience:
Kick 1.3 in A500 & A2000 : Boots only from DF0
Kick 3.x in A1200 & A4000: Boots from any floppy drive (but DF1-DF3 have rather low boot priorities, usually lower than any harddrives. But you can ofcourse select any boot device in the early startup menu).
-Paul
-
MskoDestny wrote:
tnt23 wrote:
patrik wrote:
@tnt23:
How fast mcu do you estimate would be needed to convert tracks from the adfs to mfm data on the fly?
/Patrik
Quite a bit I'm afraid. You have to deal with ~12k of data, with bit shifting, masking and checksumming, all within 0.2sec or so.
Only if you did the work an entire track at a time before you started streaming the data. If you did it all a byte at a time while you were sending the data the processor requirements would be a lot lower (of course getting the timing right would be a major pain).
Unfortunately, you ought to have some data to be streamed in advance (right before you start to stream it), and it is impossible to know exactly which track will be requested the next second.
I must confess I don't quite get your point here.
-
tnt23 wrote:
Unfortunately, you ought to have some data to be streamed in advance (right before you start to stream it), and it is impossible to know exactly which track will be requested the next second.
I must confess I don't quite get your point here.
Perhaps I misunderstood your statement about having to process 12K in .2 seconds. I was under the impression that you had .2 seconds from when a track is requested to when you needed to start streaming data in which case you wouldn't need to do the MFM encoding on the whole track in that .2 seconds as long as you could keep up with the data stream.
If that .2 seconds figure was the amount of time from the beginning of the request to the end of the transfer of the whole track than I misunderstood and you can ignore what I said.
-
MFM being so simple, it should be pretty fast to encode using a table - or rather two, one when previous bit was 0 and one for 1.
Dunno the Atmel Controller, but 8 MHz clock frequency for a 500 kbit/s signal gives 16 clocks/bit which should be plenty of time - provided you've got a shifting register at hand and don't have to do it in software...
-
@Zac67:
You're right, MFM itself is no big deal. My early setup managed to generate MFM flow on the fly completely in software, and that was running mere 4MHz. The tight loop was pretty tight; and it could not generate sync marks on the fly since they specially violate MFM standard.
I had to throw an idea away when it came to Amiga sector encoding scheme. All these odd and even bits splits, shifts and CRC calculations require a lot of CPU work.
In fact, I use table approach as the last step in building the MFM track.
-
That's amazing! :-D It would be really slick if the screen was small enough to fit in a 5 1/4" drive bay so you could just mount it there! Obviously that would only work for the big box Amigas that have 5 1/4 bays.
-
Definately needs to work as DF0: replacement as well. Perhaps as a second, simplified design (sans the LCD screen) it would be easy to fit in the floppy bay of big box miggys. It really only needs a slot for the card and two buttons for scrolling though the ADFs... You'll know what disk it loads by what shows up on WB.
-
wow, very nice work ! Seems like all the good ideas are coming into reality these days.
I think you can make your device behave as more than one floppies when necessary (not only df1, but also df2, df3 etc.) without much effort. it would be even cooler that way.
-
Dr_Righteous wrote:
Definately needs to work as DF0: replacement as well. Perhaps as a second, simplified design (sans the LCD screen) it would be easy to fit in the floppy bay of big box miggys. It really only needs a slot for the card and two buttons for scrolling though the ADFs... You'll know what disk it loads by what shows up on WB.
Given a floppy mounts in 100 seconds, now that would be a torture :-) The LCD I use is 39mm x 36mm and seems to fit in 5 1/2 inch drive bay well.
-
countzero wrote:
wow, very nice work ! Seems like all the good ideas are coming into reality these days.
I think you can make your device behave as more than one floppies when necessary (not only df1, but also df2, df3 etc.) without much effort. it would be even cooler that way.
It is indeed tempting to just wire all drive selects into the device. I think this can be implemented in one of subsequent designs. I'd like the first design to be as simple as possible, so the whole bunch of great ideas like simulating four floppies, automounting via the BOOT root directory and such are left for the future.
-
@MskoDestny
Sorry I didn't make myself clear. What I failed to say was that the track has to be delivered over and over again while the virtual drive is selected, in order to simulate the real floppy. That means that the flow is repeated every 0.2 seconds, so you have to keep these 12k buffered somewhere.
Besides, it is quite possible that the Amiga will query another side of the floppy any moment. This makes me think of keeping 24k of stuff. What is worse, the seek timings leave very little time for fetching and preparing new track data.
-
Could it be made to work as a general floppy emulator, rather than just one for the Amiga? Many old machines including old computers and electronic musical instruments which depend on 3.5" DD floppy drives are beginning to gradually deteriorate, and finding and using old floppies and floppy disks is becoming harder and harder as the old ones break down.
Also, for general use, would it work better reading and writing using larger "raw" data files rather than dedicated MFM or ADF files? It seems that encoding and decoding takes a lot of effort. Could that stage be left out entirely?
You mentioned before that writing is not possible. Is this a fundamental problem, or something that could be solved if enough cpu power was available?
Well anyway. I think many of us have been waiting for someone to do something like this. We'll wait in anticipation to see what comes of it :)
-
tnt23 wrote:
@MskoDestny
Sorry I didn't make myself clear. What I failed to say was that the track has to be delivered over and over again while the virtual drive is selected, in order to simulate the real floppy. That means that the flow is repeated every 0.2 seconds,
I later looked at the Amiga floppy timings and realized my error. I also realized the data checksum is towards the beginning of the sector which makes things more problematic.
so you have to keep these 12k buffered somewhere.
If you could do the encoding in realtime then you'd only need enough buffer for a single sector (maybe two). Of course that assumes you could do the encoding in realtime.
Besides, it is quite possible that the Amiga will query another side of the floppy any moment. This makes me think of keeping 24k of stuff. What is worse, the seek timings leave very little time for fetching and preparing new track data.
3ms(or is it microseconds? I cant remember) is certainly harsh. You could cheat a bit and always present the track gap first. If I'm calculating it correctly that should get you an extra 9ms (about 72000 cycles @8MHz). So I suppose the real question is can you read a sector off the MMC card and produce a single encoded sector complete with header and checksum in a mere 9ms.
Out of curiousity, do you know of a good link that discusses the CRC algorithm used for the data and header checksums?
-
polardark wrote:
Could it be made to work as a general floppy emulator, rather than just one for the Amiga? Many old machines including old computers and electronic musical instruments which depend on 3.5" DD floppy drives are beginning to gradually deteriorate, and finding and using old floppies and floppy disks is becoming harder and harder as the old ones break down.
I guess so. INDEX support must be added, and the whole thing shall be tweaked with regard to INDEX and hard sectoring.
Also, for general use, would it work better reading and writing using larger "raw" data files rather than dedicated MFM or ADF files? It seems that encoding and decoding takes a lot of effort. Could that stage be left out entirely?
Well, I was thinking of some MFM format just as if it were 'raw' files, i.e. complete ones and zeroes array that can be output right after you load it. It turns out that to simplify things in my design, such a raw file will be 2.5M in size, or three times bigger than ADF one. On the other hand, loading it will take more time, too.
You mentioned before that writing is not possible. Is this a fundamental problem, or something that could be solved if enough cpu power was available?
To be honest, I haven't spent much time thinking about writing. I was obsessed with reading in the first place you see :-) There are good chances another tight loop can be built to aquire writing flow and to somehow deal with it, not necessarily turning that into pure ADF.
It won't take much CPU power to record the flow into RAM, but it definitely will be a challenge to later process it when it comes to flushing it back to the flash card.
-
MskoDestny wrote:
tnt23 wrote:
@MskoDestny
Sorry I didn't make myself clear. What I failed to say was that the track has to be delivered over and over again while the virtual drive is selected, in order to simulate the real floppy. That means that the flow is repeated every 0.2 seconds,
I later looked at the Amiga floppy timings and realized my error. I also realized the data checksum is towards the beginning of the sector which makes things more problematic.
so you have to keep these 12k buffered somewhere.
If you could do the encoding in realtime then you'd only need enough buffer for a single sector (maybe two). Of course that assumes you could do the encoding in realtime.
For DD track, we need to deliver 11 MFM sectors every 0.2 seconds. This makes it 18ms per sector.
Loading one ADF sector from MMC now takes 13ms, and preparing one MFM sector takes 56ms. These times can be optimized in variety of ways, from code to hardware (going high megaherz, using SDRAM instead of EDO/FPM DRAM etc).
Maybe the code can be built so that while one MFM sector is being delivered to the floppy bus, next one is being loaded and processed. I am afraid this technique is beyond my skills, at least using current hardware :-)
Besides, it is quite possible that the Amiga will query another side of the floppy any moment. This makes me think of keeping 24k of stuff. What is worse, the seek timings leave very little time for fetching and preparing new track data.
3ms(or is it microseconds? I cant remember) is certainly harsh. You could cheat a bit and always present the track gap first. If I'm calculating it correctly that should get you an extra 9ms (about 72000 cycles @8MHz). So I suppose the real question is can you read a sector off the MMC card and produce a single encoded sector complete with header and checksum in a mere 9ms.
I am talking SPI @4MHz now, it is half of MCU's main clock. If I go for 16MHz, I will probably get 6-7ms of one sector loading time. Still not enough.
Out of curiousity, do you know of a good link that discusses the CRC algorithm used for the data and header checksums?
You may wish to check "The .ADF (Amiga Disk File) format FAQ" at http://lclevy.club.fr/adflib/adf_info.html.
-
tnt23 wrote:
I am talking SPI @4MHz now, it is half of MCU's main clock. If I go for 16MHz, I will probably get 6-7ms of one sector loading time. Still not enough.
That would be a bit of a problem wouldn't it. How high of a clock can an MMC card take in SPI mode?
You may wish to check "The .ADF (Amiga Disk File) format FAQ" at http://lclevy.club.fr/adflib/adf_info.html.
I've looked at that document and I see a discussion of the bootblock and rootblock checksum algorithms, but it doesn't say anything about the algorithm used for the sectors themselves (other than that it's applied to the MFM encoded longs). Is it the same basic algorithm?
-
MskoDestny wrote:
tnt23 wrote:
I am talking SPI @4MHz now, it is half of MCU's main clock. If I go for 16MHz, I will probably get 6-7ms of one sector loading time. Still not enough.
That would be a bit of a problem wouldn't it. How high of a clock can an MMC card take in SPI mode?
My MMC card is of some unknown manufacturer, I recall reading something about 10MHz as the highest speed possible for MMC cards. For SD card, I've heard of 20MHz, and this can be figured out of quering some SD card registers AFAIK.
SD cards can be read in their native mode, way faster than in SPI compatibility mode. This however requires more complex bus. And CF cards will beat the hell out of SD and MMC for sure, if you can allocate that much of I/O pins.
You may wish to check "The .ADF (Amiga Disk File) format FAQ" at http://lclevy.club.fr/adflib/adf_info.html.
I've looked at that document and I see a discussion of the bootblock and rootblock checksum algorithms, but it doesn't say anything about the algorithm used for the sectors themselves (other than that it's applied to the MFM encoded longs). Is it the same basic algorithm?
In chapter 2.4, 'How to decode MFM data?', there is a small C snippet. I used mainly that to construct own checksum routines. Another piece of information was C code from some Amiga emulator sources, but I can't find that now.
-
@tnt23
I love your avatar!
-
Tim, can you shed some light on your new prototype?
-
I have posted the photo of partly assembled proto PCB in the gallery this morning. (EDIT: check it out here (http://www.amiga.org/gallery/index.php?n=1323=5).)
Got PCBs last week, only am waiting for the DRAM chips to arrive in a week or so. The code is being tweaked against the new design here and there, MMC and LCD and buttons already work.
There are some issues though. One is with DRAM chips which are no longer manufactured since 1995 I believe and thus are rather hard to obtain. I am addressing this by working on another design which would use legacy 72 pin SIMM. This also would boost overall performance since these are 5 volt and so the MCU can toot whole 16MHz.
Another issue is the Nokia 3310's LCD. Popular and affordable and all, it is a challenge to build simple and eye appealing connector for it. (See JELU Web-Shop (http://www.myplace.nu/mp3/nokialcd.htm) for more info)
On my PCB there is an 2.54mm grid 2x10 pin male LCD connector (see the photo in the gallery). I use simple ribbon cable with 2x10 pin female plug on one end and a bit of soldering on the other to attach the LCD. This hardly can be an option for non-DIY persons out there.
-
Hello,
this project seems really *A LOT* interesting. What about giving more information in english of the project and creating a web page of it? It seems really promising but too few information for non-russian people.
About the project, it can have a very great future in retro machines using floppies. This project can be even more interesting if adapted for other floppy-based architectures too (Acorn Archimedes, Amstrad CPC, Apple II, Atari 8bit/ST/Falcom, BBC Master, BBC Micro, C64, Dragon 32/64, MSX, Nec PC-100, NEC PC-8801, Nintendo Famicom Disk System, SAM Coupé, Sharp X1, Spectrum +3/Sprinter/Scorpion, Sharp X68000, Sega SC-3000, Sinclair QL, TRS-80, TI-99/4A, Jupiter ACE...) using some kind of modular platform design (two modules and one being used for connecting to the floppy interface of different computers). Of course I'm not asking you for supporting the wide variety of floppy-based architectures, but designing your project with this on mind, supporting a few and providing the necessary information for others developing modules for it.
Best regards,
timofonic
PS: MskoDestny, I found you here! You never replied my emails, please do it about the SCD stuff, read the PM.
-
I am trying to report as much as possible here at Amiga.org, too, mostly in English :-) I don't think the project is mature enough to arrange a separate web page for it.
Covering all floppy formats sounds attractive. Maybe PC DD format should be implemented in the first place as there are ancient synthesizers and measurement equipment with decaying 720K floppy drives out there.
MSX people probably won't need this type of emulator since there is already a number of flash media projects for the platform, and MSX roms are much easier to tinker with.
I like the idea of modular approach, too. There are so many ways for the project to evolve, from USB to standalone floppy writer, but I'd try to first accomplish simple things :-)
-
OK, so I've got my DRAM chips this week and the prototype board is complete. A usial number of wire fixes to the board can be seen in the photo section :-)
I have tailored the code, too, and it now takes 35 seconds to both load and encode an ADF image. I think this is almost minimum possible for current design, maybe I'll squeeze a couple of seconds more.
DMT's speed test shows ~21K/sec. There are some glitches in FAT16 code I have to iron yet. And I'm going to sacrifice an I/O pin for audio seek indication :crazy:
-
That's fantastic - well done! :-) What is the IDC header for on the board? Is it for connecting to the internal floppy connnector to use it as DF0?
--
moto
-
Yeah, the big 34-pin IDC is for the floppy ribbon cable. I haven't tested it with real A500 yet, only with A1200 as DF1 using some custom cabling.
On the board there are two ugly jumpers allowing the device to respond as DF0 or DF1.
-
So does it work as a total DF0 replacement?
--
moto
-
motorollin wrote:
So does it work as a total DF0 replacement?
--
moto
As a read-only, ADF-based replacement :lol: Give me a couple of hours to fit the thing into my A500 and I'll report back :-)
-
Read only huh, well that will make it a lot easier to transfer files from my Mac, which doesn't have a floppy drive. That means I have to copy files to DOS disks at work :roll:
If I could use an ADF explorer on the Mac, then copy the ADF file to the MMC card, and then mount the ADF as PC0 then all my problems would be solved :-D
So when can I buy one?
--
moto
-
tnt23 wrote:
Another issue is the Nokia 3310's LCD. Popular and affordable and all, it is a challenge to build simple and eye appealing connector for it. (See JELU Web-Shop (http://www.myplace.nu/mp3/nokialcd.htm) for more info)
Have you thought about using a Nokia colour LCD?
Display3000.com webshop (http://www.shop-en.display3000.com/pi2037397089.htm?categoryId=0) sells them in a variety of configs, and a SMD connector for it too(no more soldering to the flexible PCB like you have to on the 3310). I've currently got one hooked up to the parallel port which shows MP3 album art.
-
tnt23 wrote:
"To be honest, I haven't spent much time thinking about writing. I was obsessed with reading in the first place you see There are good chances another tight loop can be built to aquire writing flow and to somehow deal with it, not necessarily turning that into pure ADF."
Perhaps the Amiga could write ADF-images to the flash card, via somekind of serial protocol through the floppy port? It is not the same thing as writing to a floppy, but you could do things from the Amiga keyboard. And similarly since microcontrollers usually have UARTs, you could read and write floppy-images from a remote computer via RS-232.
"Loading one ADF sector from MMC now takes 13ms, and preparing one MFM sector takes 56ms. These times can be optimized in variety of ways, from code to hardware (going high megaherz, using SDRAM instead of EDO/FPM DRAM etc)"
May a job for an FPGA?
-
Read only huh, well that will make it a lot easier to transfer files from my Mac, which doesn't have a floppy drive. That means I have to copy files to DOS disks at work :roll:
If I could use an ADF explorer on the Mac, then copy the ADF file to the MMC card, and then mount the ADF as PC0 then all my problems would be solved :-D
Still seems a bit complicated to me. You don't have to take your files back from Amiga to Mac do you?
So when can I buy one?
After I fix most of the bugs and figure out a way of producing and delivering the device in small quantities I guess. What would you suggest the price can be?
-
@Doobrey
Isn't the fifty bucks color LCD an overkill? I doubt there's much to show on it in my case :-)
-
@tnt23:
Sorry, little OT: Are you the "tnt" I know from the C64/MMC64-scene? If yes, glad to hear you're also working on Amiga-stuff now. I appreciate your work!
-
Are you going to publish source/schematics when the project is finished or is this going to be a commercial product?
Anders M.
-
Avoid Spaceballs - State of the Art, I remember that demo turning my floppy drive into a buzzsaw!
:-D
Looks great, I think it should be for DF0: internal and it would need to work well with the desktop casing (the eject button could be replaced with an access light).
Just out of curio, what is the maximum transfer rate of the floppy interface? The drives only do 10k/s and the flash cards 1MB/s!
EDIT: Oh, the F.Disk LED will be the access light right? We'll have to use putty for the eject button hole. ;-)
-
@humppa
No, I have never been to the C64 scene [unfortunately] :-) I love the MMC64 project, too.
-
mrmkl wrote:
Perhaps the Amiga could write ADF-images to the flash card, via somekind of serial protocol through the floppy port? It is not the same thing as writing to a floppy, but you could do things from the Amiga keyboard. And similarly since microcontrollers usually have UARTs, you could read and write floppy-images from a remote computer via RS-232.
Amiga also has RS-232 port, this could be used, too. Some software support from Amiga side would be necessary, like drivers.
UARTs are great, but there is USB. A guy from Amiga Floppy Project (http://techtravels.org/amiga/amigablog) interfaces his reader with computer via USB.
"Loading one ADF sector from MMC now takes 13ms, and preparing one MFM sector takes 56ms. These times can be optimized in variety of ways, from code to hardware (going high megaherz, using SDRAM instead of EDO/FPM DRAM etc)"
May a job for an FPGA?
Maybe. I will teach myself FPGA some day for sure, just look at the Minimig :-) It is that I'm having fun with Atmel AVR's now.
-
Yesterday I've put the device into A500's drive bay and set it to DF0. Workbench 1.2, 1.3 and utilities like DOpus, AMOS Pro boot just great!
Bad news is that of six or seven games on my MMC only ARKANOID managed to load and run. Also, only two demos loaded and run OK, one is some 40K intro and ANNOUNCE.
Maybe this is due to the fact that AmigaDOS doesn't use INDEX pulse (says DiskMonTools manual), which is not implemented in my design, but can well be used by other software to sync to.
Hyperspeed wrote:
Avoid Spaceballs - State of the Art, I remember that demo turning my floppy drive into a buzzsaw!
:-D
State of the Art didn't run either. If I do a diskcopy from emulated DF1 to real floppy it runs just fine. There must be something important I miss about the floppy interface.
Looks great, I think it should be for DF0: internal and it would need to work well with the desktop casing (the eject button could be replaced with an access light).
Just out of curio, what is the maximum transfer rate of the floppy interface? The drives only do 10k/s and the flash cards 1MB/s!
EDIT: Oh, the F.Disk LED will be the access light right? We'll have to use putty for the eject button hole. ;-)
There is an LCD with all sorts of indications, like head movement, drive selection, side and dir signals :-)
Floppy speed test shows values around 21K-22K bytes per second. I don't know if the floppy DMA can be faster than 500K bits per second, or roughly 60Kbytes/s. We are trying to mimic the FDD as much as possible, so don't expect any breakthrough here :-)
-
tnt23 wrote:
Read only huh, well that will make it a lot easier to transfer files from my Mac, which doesn't have a floppy drive. That means I have to copy files to DOS disks at work :roll:
If I could use an ADF explorer on the Mac, then copy the ADF file to the MMC card, and then mount the ADF as PC0 then all my problems would be solved :-D
Still seems a bit complicated to me. You don't have to take your files back from Amiga to Mac do you?
No I don't need to transfer back to the Mac. And I do have my A1200 networked to the Mac. It would only be in cases of emergency when I needed to use floppies (real or emulated :-) )
So when can I buy one?
After I fix most of the bugs and figure out a way of producing and delivering the device in small quantities I guess. What would you suggest the price can be?[/quote]
Well, that depends on how much it costs to manufacture :-)
--
moto
-
Great to hear about your progress (there are always drawbacks, so keep going).
I think you should keep the 'use this device as a card reader, too' in mind while making changes to the hardware. It'd be a very good chance to attach the emulator in such a way that it can be used to access the flash card in a more efficient way (faster and higher capacity access).
Maybe through serial (probably slow), parallel (lot of hardware involved) or through the floppy port, just with a more efficient protocol - after all, you don't really need MFM for transport.
If you provide the means of accessing the flash card for real, someone else will probably write a driver for it, so it could be used as a hard drive replacement. It could even auto boot, just emulate booting a workbench disk with the drivers, mount the card and go on from there. How does that sound?
-
Zac67 wrote:
I think you should keep the 'use this device as a card reader, too' in mind while making changes to the hardware. It'd be a very good chance to attach the emulator in such a way that it can be used to access the flash card in a more efficient way (faster and higher capacity access).
Maybe through serial (probably slow), parallel (lot of hardware involved) or through the floppy port, just with a more efficient protocol - after all, you don't really need MFM for transport.
If you provide the means of accessing the flash card for real, someone else will probably write a driver for it, so it could be used as a hard drive replacement. It could even auto boot, just emulate booting a workbench disk with the drivers, mount the card and go on from there. How does that sound?
Sounds reasonable. I was thinking of a similar approach looking at A500 non-booting IDE interface where there needs to be a system boot floppy allowing for later mounting IDE drive(s). Will keep that in mind, thanks.
Another thing I'd like to implement is multiple floppy images handling. The amount of memory emulator has now allows for at least 2 floppies to be stored and switched between. Imagine 1st image is Workbench disk (probably autoloaded from MMC card BOOT directory) and 2nd is some game or utility disk, and you can swap them in an instant.
-
tnt23 wrote:
mrmkl wrote:
...
...UARTs, you could read and write floppy-images from a remote computer via RS-232.
Amiga also has RS-232 port, this could be used, too. Some software support from Amiga side would be necessary, like drivers.
ZModem for RS-232? It is usually included with terminal programs. (as an amigaos library in libs:)
-
What about megring with 1541-III? I think meging your design with that and using a modular design like I said you before could make this device a lot interesting for more people (more retroplatforms supported = more people interested). What about releasing the technical stuff with some Creative Commons license for non-commercial use? It could be nice having the stuff you did in self-mounting manner and technical stuff too for hardware geeks and the mounted stuff for the average people ;)
http://commodore-gg.hobby.nl/feb18.htm
What about supporting other formats like DMS (compressed ADF) and IPF? It could be nice if not needing to convert between formats and only copying to the SD/MMC.
-
timofonic wrote:
What about megring with 1541-III? I think meging your design with that and using a modular design like I said you before could make this device a lot interesting for more people (more retroplatforms supported = more people interested). What about releasing the technical stuff with some Creative Commons license for non-commercial use? It could be nice having the stuff you did in self-mounting manner and technical stuff too for hardware geeks and the mounted stuff for the average people ;)
http://commodore-gg.hobby.nl/feb18.htm
What about supporting other formats like DMS (compressed ADF) and IPF? It could be nice if not needing to convert between formats and only copying to the SD/MMC.
Don't know much about 1543-III, will look up the link. I am really uncertain which shape the emulator should take eventually. Making things as universal as possible can be evil sometimes :-)
For IPF format, the problem is that it is not documented, only available as compiled binaries (libraries) and that is not suitable to implement IPF support in this design.
DMS format can be an option, although I believe a desktop (Amiga or PC, or MAC) can be used to convert stuff between DMS and ADF.
-
Hey ho!
I have fixed that games/demos loading (or rather not loading) problem which turned out to be me not following common floppy timing guidelines. So now I am watching excellent :banana: ARTE! :banana: demo loaded from emulated df0!
-
I've read through the whole thread, but I haven't seen mentioned if you are going to publish source code or compiled .hex-files. Are you?
Excellent project,,keep up the good work!
Anders M.
-
@Mikkel
Can't tell. Definitely not before I solder a couple of boards for fellow Amiga users to test and see wether thing is a success.
-
Hi tnt23!
Can you report any news on your floppy project?
/M
-
Not much news here. While waiting for another couple of PCBs to be done, I am fixing this and that. I had to rework original design a bit to implement INDEX support, as a number of games (namely Cannon Fodder) would not load properly without sensing INDEX pulse.
Different type of LCD, either character 4x20 or graphics 128x32, will probably be used in another design of emulator, along with universal SD/MMC connector.
-
Go for the big lcd, that would be hitech!
but with that index pulse problem fixed everthing seems to go as planed? My hope is that the floppy emulator will turn in to a product, so i can buy one ;)
/M
-
5char wrote:
Go for the big lcd, that would be hitech!
but with that index pulse problem fixed everthing seems to go as planed? My hope is that the floppy emulator will turn in to a product, so i can buy one ;)
/M
Touchscreen would be more dramatic :lol:
Yes, I'd say the emulator is more or less done. Time to go for feature freezing and feed it into production :-)
-
How are you, can buy?
-
I'm fine, still waiting to pick up PCBs. Haven't got much time to work on the new (faster) design.
-
How are you, and how contact with you?
It reads 1.44M还是144M？
44 Ms are still 144 M? :-)
-
Use Private Messages to reach me.
As for 1.44M media - no, the device only emulates DD floppies, that is 720K or 880K. What do you mean by '44 Ms are still 144 M?' :-o
-
How are you, you of e- mail?
My is a gcyly@126.com
:-)
-
Hi tnt23
I work on a similar project since January. My floppy emulator is a parallel port interface for PC with 2 SRAM buffers (2* 32Ko) and an shift register and some others TTL components. The PC send in real time the MFM flow to the floppy interface.
Actually this interface works for Atari ST and Amiga.
To see some pictures of the prototype of this interface go to this page (in French) :
http://jeanfrancoisdelnero.free.fr/floppy_drive_emulator/ (http://jeanfrancoisdelnero.free.fr/floppy_drive_emulator/)
Jeff / HxC2001
-
Ah, cool, so you effectively use the PC as a disk image fileserver...
Does it cope with protected disks and the extended ADF format, or CAPS images?
- Ali
-
Not for the moment but the software will cope with these formats soon. :-)
-
Good stuff! Keep us all updated!
- Ali
-
Jeff,
Cool stuff. I guess you just upload track or two to SRAM and then shift the data out clocking from the PC? Neat!
-
Any updates on the project?
-
Unfortunately, no updates on the project so far.
That's because I've been busy releasing an even more exciting project - my second baby was born on April, 10, and it's a boy! :-D
I guess I'll get back to floppy emulator quite soon.
-
That's because I've been busy releasing an even more exciting project - my second baby was born on April, 10, and it's a boy!
Congratulations!
:-)
-
Congratulations!
Have you decided if you want to make it open source or a commersial product?
Anders M.
-
@Mikkel
That's the only design that doesn't need neither schematics nor special equipment for building. Everyone can DIY this :-)
-
That's the only design that doesn't need neither schematics nor special equipment for building. Everyone can DIY this
:roflmao:
-
Why not just use the Amiga RAM disk or RAD to unpack DMS or ADF too.....
-
AnamigaKid wrote:
Why not just use the Amiga RAM disk or RAD to unpack DMS or ADF too.....
Sounds far too complicated if I only want to watch a few demos on my unexpanded A500 :-o
-
hi!Floppy emulator ok?
-
Very cool project.
Any sort of updates?
-
No updates yet, sorry.
Probably will revive the project right after the Chaos Constructions 2006 party (http://cc6.org.ru/index.php?uid=english) taking place in St.Petersburg, Russia this August, where the emulator will be shown.
-
hmm i'd like one too
if you were going to sell some, what do you think the price would be?
-
Umm, I really have no idea now.
-
Any news? :-)
-
Still no news here :( Another project still keeps me busy.
Good thing is, that project is based on a similar chip, and this makes me believe it won't be too hard to switch back to my floppy emulator.
-
tnt23 wrote:
Still no news here :( Another project still keeps me busy.
Good thing is, that project is based on a similar chip, and this makes me believe it won't be too hard to switch back to my floppy emulator.
So theres still some hope :) ...
-
I thought that I should mention that I dont think you can sell a Floppy disk emulator without first licensing the technology from 3COM. They own an international patents on it dating back to 1994 that effectively sew up free commercial use of this technology
Here is the US one
http://www.freepatentsonline.com/5473765.html
-
tnt23 wrote:
Another project still keeps me busy.
Ooh! Do tell! What is it?! :-)
- Ali
-
I don't think, that the lawyers of 3com interested in a hobbyist market.
Anyway we can use the microsoft strategy:
This device is not a floppy emulator, this is an amiga turbo floppy drive.
or as i know the patents go public domain after a period of time. Mostly 10 years
-
Ooh! Do tell! What is it?! :-)
- Ali
It's a piece of hardware dealing with another industry standard pieces of hardware :-) Nothing fascinating, just that sort of job you make your living with.
-
Hope it will goes well and you can switch to this nice project asap 8-)
-
Great project, any news about this?
I hope this project not die and if the author abandon it, another one can continue it...
-
I have just bought a A500+ just like used to have and i was hunting for this project as i had seen it a while ago, im very interested in it, you really need to get get it working so i can give u some money for one!
:) please dont give up
-
I want this device too for an A500+ :)
-
Wow, have just closed browser window with lengthy reply by accident :)
In short, I haven't put the project aside, although I wasn't able to update it for a while.
Here's (http://milliways.chance.ru/~tnt23/pics/misc/tic149.jpg) a nice new LCD I'm considering to include in future design: it is a cheap COG 133x65 LCD with I2C interface.
Merry upcoming Christmas (and a Happy New Year :-))
-
Merry Christmas and a Happy New Year!
keep this project alive, its great tnt23 !
-
tnt23 wrote:
In short, I haven't put the project aside, although I wasn't able to update it for a while.
Here's (http://milliways.chance.ru/~tnt23/pics/misc/tic149.jpg) a nice new LCD I'm considering to include in future design: it is a cheap COG 133x65 LCD with I2C interface.
Merry upcoming Christmas (and a Happy New Year :-))
Merry Christmas to you too.
Would this project work in a 2000? I assume it would. Yes, keep it alive. I'm very interested in it.
Fester
-
tnt23 wrote:
Here's (http://milliways.chance.ru/~tnt23/pics/misc/tic149.jpg) a nice new LCD I'm considering to include in future design: it is a cheap COG 133x65 LCD with I2C interface.
Looks good, and a reasonable resolution/size on that... How cheap is "cheap", and going off-topic a bit, how easy is it to interface one of those to an old 8-bit Z80 or 6502-based system?
Keep up the work on the floppy emulator though!
- Ali
-
I used a Toshiba 4030CDT as a test platform for the floppy drive simulator which is available from my website:
http://amiga.krishnasoft.com.
I started this project when my floppy disks getting read/write errors. Now I can boot up the ADFs directly from my Toshiba laptop. It's currently works in read-only mode and for all parallel ports capable of 1 megabyte/second throughput.
I previously did this for Atari disk drives which were much simpler to deal with and did not require a fast throughput so the read and write modes both work.
For desktops, you can easily get a PCI parallel port that does 1 megabyte/second so I can use the same machine for simulating both Atari disk drives and Amiga disk drives.
Now I have a whole bunch of amiga image disks on my Toshiba laptop and I can boot from any of them or make them come up as an external disk (DF1..DF3).
-
InTheSand wrote:
Looks good, and a reasonable resolution/size on that... How cheap is "cheap", and going off-topic a bit, how easy is it to interface one of those to an old 8-bit Z80 or 6502-based system?
Well, I got it for $6, plus bought two LED backlight modules to try, green one (shown) and white, $4 each. Not very expensive I think.
Driving i2c is not difficult, you'll only need 2 wires - clock line and data line. Everything should be done in software, and you must not exceed 400kHz barrier when talking to the indicator. You may wish to check this link (http://members.iinet.net.au/~daveb/downloads/i2c.html) for schematics and i2c software drivers for Z80.
-
Fester wrote:
Would this project work in a 2000? I assume it would. Yes, keep it alive. I'm very interested in it.
Fester
I guess it should as soon as 2000's drives are ordinary DD ones.
-
Not only Dennis' Minimig is an outstanding project, it also gives the rest of us good kick of inspiration and creativity :)
So I've finally managed to route the new board, with most, if not all, possible enhancements and future expansion possibilities (i.e. buzzer and fifth button :lol: ). The picture can be seen here (http://www.amiga.org/gallery/index.php?n=1870=5). (It doesn't show silk unfortunately, which has some nice artwork :-))
The boards are expected to arrive by the end of the week, and then the code will have to be rewritten for the new design. The MCU is faster now (16MHz instead of 8Mhz) There also is a possibility of adding Write support as all the necessary signals from the floppy bus have now been routed, too.
-
very nice work! it's great to see more development happening on any of the replacement floppy drive emulators in progress.
IDE port? that certainly could be interesting! Does it allow the use an IDE drive on a normal A500 or does it serve some other purpose? Any further info on your project would be great, I love reading about these tech projects :)
-
IDE socket is there to help interfacing to CompactFlash in the future :)
-
Compact flash ? wow ...
edit : removed silly comment.
-
tnt23 wrote:
IDE socket is there to help interfacing to CompactFlash in the future :)
that was my first thought - stick a compact flash card in there for fast IDE access.
Is it possible to interface IDE to the floppy port, or does it connect elsewhere on the motherboard as well?
-
tnt23 wrote:
There also is a possibility of adding Write support...
Ooh! Yes please - this'd make it very useful indeed!
- Ali
-
gizmomelb wrote:
Is it possible to interface IDE to the floppy port, or does it connect elsewhere on the motherboard as well?
It doesn't - it can only be used by emulator's MCU for CompactFlash access.
-
@gizmomelb
You've made a good point BTW. Since the IDE interface in the emulator is just a bunch of I/O pins and is (or rather will be) done in software, part of it can be reprogrammed if it is not used.
For example, its high 8 data lines used for 16-bit IDE access can control a real floppy for example. Like dumping ADF to a real floppy, how does that sound?
I just got my boards from the factory, here's what they look like (http://www.amiga.org/gallery/index.php?n=1876=5). Let the tinkering begin! :hammer:
-
Nice project indeed.... my 1200 drive has gone long ago, so i'm more than happy when i see such solutions.... ;)
-
Just bought an IDE/CF converter board. Plugged it in, wrote some quick and dirty IDE code, fixed a couple of issues. Surprisingly, it works.
http://www.amiga.org/gallery/index.php?n=1921=5
-
Wow that's a nice job you've done there. Is everything fully functional how you wanted it to be now?
Andy
-
@tnt23
Is it possible to add 5v to pin 20 of the IDE connector? (Via jumper) That way you can use flash disks like Trancend IDE Flash Modules.
Edit: Never mind, it looks like you are using a 44pin IDE.
-
Wow very good work tnt23!
-
AJCopland wrote:
Wow that's a nice job you've done there. Is everything fully functional how you wanted it to be now?
Andy
LCD works, as well as the very basic SIMM support. I haven't ported SD/MMC part, and haven't even tried floppy bus interface yet. Still plenty of work to do.
-
@adolescent
Yes, it is quite possible. Altough my adapter works with standard 'missing' pin 20, it can take +5v from it (settable by adapter's jumper). A jumper or optional zero ohm SMD resistor can be added in new revision of emulator's board.
My IDE socket is of plain 40-pin IDC type.
-
I am looking forward to this project being a success.
I can see it being more of a viable commercial product than most other homebrew hardware.
I appreciate this is a new version, but if you can in the future... make it the same form factor as a floppy drive.
To be able to remove a broken drive and insert one of these in it's place would be ideal.
-
This project looks great, any news?
Does it have a project website? There are free hosting on sourceforge, not sure if it's the more appropiated one but is a possibility.
-
Yeah, news of any kind? Me wants it!!! ;D
-
Hey mon, any news?
:roll:
-
progress ?
:inquisitive:
-
:bump:
-
If you understand Russian, tnt23 also posts on a Russian forum (http://amiga.org.ru/forum/viewtopic.php?t=1298&postdays=0&postorder=asc&start=150&sid=84a3cde9ac48fda5b05859a663760fae). Well, I don't understand a word they are saying :lol:, but the picture on that page says enough :-D
-
still waiting for an update on this puppy!
-
why do amiga people work like this? 2 years of one man work and nothing? couldn't someone else help speed this up?
i am probably ignorant but anyway why can't a floppy emulator be done in software? wouldn't that be an easier job? :roll:
-
monami wrote:
I am probably ignorant but anyway why can't a floppy emulator be done in software? wouldn't that be an easier job? :roll:
There is a lot of floppy software-based emulators on Aminet. But not a single one have ability to use N-DOS disks or survive a reset (except RAD:). They are useless to emulate a real floppy drive.
Remember one thing: this floppy emulator is a drop-in replacement to the real floppy drive, giving the Amiga the ability to use ADF files directly placed in a SD/MMC card. Much better than a real floppy drive (no bad blocks, small footprint, easy transfer from peecees, etc).
-
monami wrote:
i am probably ignorant but anyway why can't a floppy emulator be done in software? wouldn't that be an easier job? :roll:
There is already a software floppy disk emulator for the Amiga (kind of) it's called WHDload.
I still feel this device has a commercial potential, especially if made to work with Spectrum's and C64 etc. and whatever other Retro computers dont have a WHDload.
It could even be extended to be a TAPE emulator in the form of a compressesed sample player.
-
few questions .....
so this emulator will be like external floppy diskdrive and will be autoboot so i dont have choose from early startup screen anything..
assuming someday it will be for sale...will it work also Escom A1200 :)
-
Read the author statement: linky link! (http://jeanfrancoisdelnero.free.fr/floppy_drive_emulator/)
[edit]: Silly me! this is from the author of the USB floppy link!
-
monami wrote:
i am probably ignorant but anyway why can't a floppy emulator be done in software? wouldn't that be an easier job? :roll:
Because software which is hard-coded to load from trackdisk.device unit 0 (DF0) would fail to load if it is booted from some software emulated floppy drive. The bootloader would fail when it tried to load data from the drive. As has already been pointed out, WHDLoad gets around this by patching the software. Alternatively, hardware projects like this replace the drive physically connected to the internal floppy connector and emulate the drive itself, so any software which directly access the drive will behave in exactly the same way as it would with a real disk.
--
moto
-
i like the concept of whdload but to be honest it's going to take forever to get half the games finished and them hunt down original floppies. i no longer want to use floppy disks. it's 2008!
"Because software which is hard-coded to load from trackdisk.device unit 0 (DF0) would fail to load if it is booted from some software emulated floppy drive. The bootloader would fail when it tried to load data from the drive. As has already been pointed out, WHDLoad gets around this by patching the software. Alternatively, hardware projects like this replace the drive physically connected to the internal floppy connector and emulate the drive itself, so any software which directly access the drive will behave in exactly the same way as it would with a real disk."
i no longer believe in impossibilities!
uae on amiga did floppy emulation so can anyone take advantage of that code?
-
UAE is an emulator. No doubt to "emulate" the floppy drive it has to emulate many other parts too which in turn slow-down the Amiga. You cannot simply replace a part of the hardware with software running ON the hardware.
A hardware plug-in replacement for the floppy drive however is self contained. The Amiga merely sees a floppy drive so it runs just the same as if it was a REAL floppy drive, possibly faster for software which doesn't rely on strict read timings.
-
monami wrote:
uae on amiga did floppy emulation so can anyone take advantage of that code?
How would a game which switches off the Amiga OS and halts all other code and in all other ways takes over the machine, and is also hard coded to read data from DF0, know anything about some kind of software floppy drive unless it is modified to do so? The only reason this works in UAE is because UAE is an emulator. A piece of software running inside UAE, e.g. a game, makes a call to what it thinks is hardware, but is actually more software which can do whatever it wants, and in this case that means feeding data to the game from a file instead of a disk. The same game running on actual Amiga hardware does not have the luxury of this flexibility unless you patch the software, which is what WHDLoad does, or replace parts of the hardware - which is what this project is for.
[EDIT]
Changed some of the instances of the word "software" to make that less confusing :-)
[/EDIT]
--
moto
-
Folks,
I would like to apologize for not posting any updates on the project. In fact, there simply haven't been any for quite a while.
Now for the good news. User interface is somewhat usable now. It still takes 16 seconds for ADF to load; if I find a way to cut it down further I will. A bunch of PC formats has been added, among them 720K and TR-DOS.
And what I am really excited about is this: write mode! The emulated floppy can not only be read, but formatted and written, too. The top level code for dumping the changes back to the flash is still to be worked out, but the low level write support seems to be working properly. (At least Linux' fdformat command takes it for real.)
A slightly redone board has been ordered, with some fixes (and possibly few bugs), able to accomodate LCD's backlight module. I am hoping to populate it in a week and tell you how it goes.
-
Wow! Great news, indeed.
Keep the superb job.
And if you want a brazilian "beta-tester", count on me! :-D
-
@tnt23
Hello,
I plan to have a full floppy emulation for my stratix II minimig. I want to use the propeller chip from Parallax to do the emulation.
I have some technical questions:
- It looks like every signal has to be open collector with 1K pull-up resistor (because of bus sharing between different drives). Did you do it that way ?
- Paula generates the 500 kbit/s bitrate for the floppy by dividing 3.57 MHz by 7 (511364 bit/s for NTSC and 506699 bit/s for PAL). What frequency do you use for your HW ?
- Did you implement write precompensation ?
- Any support for HD floppy drives planned ?
Regards,
Frederic
-
@rkauer, thanks :)
I was thinking about adding boot loader to the emulator, so that its firmware could be updated via the same SD card. Otherwise it would require a JTAG capable programmer and software to reprogram the MCU.
-
@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
Have you considered supporting the IPF format of www.softpres.org?
That would make it a "complete" floppy emulator for the amiga :)
-
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. :-)
-
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 wrote:
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.
That is why there is no IPF support for Minimig, Only Softpres release the binary libraries.
-
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 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.
But I would like to see the floppy emulator in a 3.5" form factor, and with ADF and IPF read and write capabilities.
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?
-
tnt23 wrote:
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)
Thanks for that info. We're all used to having "ugly hacks" hanging out of our Amigas. A few tie-wraps, some duct tape and a little extra wiring and it will look perfect. :-D
-
Regarding IPF, why bother?, must be simpler to create our own free bitexact format?
It's not exactly rocketscience.
-
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 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.
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).
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.
-
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 wrote:
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.
I think I'd prefere the buttons on individual wires (like a4k leds and key) and the LCD sandwich on a separate board connected with a ribbon cable.
This way it's most flexible for users to choose how to mount and use the emulator.
What about the mounting holes, is it possible to change that to fit most amiga chinon drives?
Also, have you been contacted by, or considered to coperate with Vesalia, AmiKit or ACube to manufacture and distribute this puppy?
-
tnt23 wrote:
@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.
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.
- 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 have seen that scope trace already. I was surprised by the duty cycle. Was it an issue in your design ?
- 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.
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.
BTW, Amiga Floppy Project (http://www.techtravels.org/amiga/amigablog/) also is based on Parallax chip.
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.
Regards,
Frederic
-
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.
-
@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 wrote:
@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 think that if you build it that way then it will help to keep the costs down as one design will fit all needs. The same boards can be subsituted into all model Amigas with either a custom faceplate or holes added as required (or a simple box and PSU for an external drive).
If you do any sort of production run then please let me know. :-)
-
tnt23 wrote:
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.
Yesterday night, I have found more information in the patents : during write, a delay is introduced in the data part of the MFM bit cell. The clock part is not delayed (if you delay both, there is no delay anymore.:lol:). This is done by the floppy drive controller not by the drive itself so, it should not impact your design (maybe some delays would be slightly off during write :-?). Usually, for 2DD floppies, there is no precomp. It is important for 2HD ones.
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.
It can run up to 100 MHz. Each instruction takes 4 cycles.
But with 8 cores, you have 200 MIPS of CPU power. You can assign the I/Os to any core. Each core has 2 KB of RAM (512 instructions). There is 32KB of shared RAM to do data exchange between the cores (perfect for buffering a whole track).
You can get the CPU as a DIL40, QFP44 or QFN44. The unitary price is $13.
Regards,
Frederic
-
@ tnt23
I don't think AmiKit or Vesalia will be interested in manufacturing the emulator, at least not in small quantities.
Go ask ACube Systems then! :-D
-
@tnt23
I think this is fantastic and will be making one once the schematics are released.
Don't worry about the layout too much as plenty of us have the ability to move the board around. :)
-
What about joining with the HxC floppy emulator (http://torlus.com/floppy/)? This floppy emulator is designed for supporting more kind of drives and formats, maybe both can collabore in some way too.
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?
-
timofonic wrote:
What about joining with the HxC floppy emulator (http://torlus.com/floppy/)? 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.
-
I still feel there is a commercial opportunity here.
If the board was made so that it was the same size as a floppy disk drive, with the screw holes in the right places so that it could fit internally, with the controller button in the same place as the eject button it would be great.
-
alexh wrote:
I still feel there is a commercial opportunity here.
If the board was made so that it was the same size as a floppy disk drive, with the screw holes in the right places so that it could fit internally, with the controller button in the same place as the eject button it would be great.
Well I'd certainly buy at least one for my A1200T, my A3000 and my A2000. My A3000 drives definately have problems "remembering" that they actually have a disk inserted at times.
-
tnt23 wrote:
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.
You can contact with the authors directly over his forums.
http://torlus.com/floppy/forum/viewforum.php?f=2
The good thing is that they are already two people, probably one more could make thigs easier. It could be very nice if you join the HxC Team as providing experience on Amiga and TR-DOS :)
tnt23 wrote:
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.
I know about that interface is quite popular in Russia, I would like to get a Pentagon/Scorpion machine. Not sure if those machines are now produced properly and not know if the D+ is compatible with it.
http://www.worldofspectrum.org/NotThePlusD/
-
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
-
@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 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?
I prefer the idea of only one button (which would be in the position of the Eject) and using the host machine to select disk images.
How would you do that?
A default boot image (selected on power-up or if the eject is held down for 2 seconds).
The boot image is part binary file, and part interaction with the controller.
The binary file provides the preliminary boot media and the menu system. The controller provides the flash card file listings and a way of selecting a disk image by writing data (back to the controller).
Of course you would need a different "default image" for each target platform, but I am sure they could be knocked together with partners from each scene in 5-10 mins.
Especially if you open-sourced the API (i.e. which tracks do what etc.)
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.
If we could agree a partnership and an API, then I would arrange to get the default boot image (dual-format) coded for the Amiga/ST for an experiment?
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 ;-))
-
I saw someone mention the propeller chip earlier in the thread. That chip can generate it's own video with one cog and do the floppy emulation with another. You could even genlock it over the Amiga's own display. I understand the minimig does this with it's cpu.
The other cogs could be used for expansion like reading pc style keyboards and mice or talking to SPI peripherals....
just a notion...
-
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" 3.5" floppy drive.
Is the price really a problem ? The price difference of an LCD based device and an OSD based device is about 10 euros.
After all you have a powerful computer and a TV, why do you need an LCD?
The device that you are talking about already exist:
http://atariamiga.free.fr/installation_sdiskemul_stf.php (http://atariamiga.free.fr/installation_sdiskemul_stf.php)
http://atariamiga.free.fr/installation_sdiskemul_amiga600.php (http://atariamiga.free.fr/installation_sdiskemul_amiga600.php)
http://atariamiga.free.fr/plateformes.php (http://atariamiga.free.fr/plateformes.php)
But what do you do when you need to plug the emulator on this kind of "computer" ?:
http://www.reflexmusic.de/DSS-1/HxCEmu.htm (http://www.reflexmusic.de/DSS-1/HxCEmu.htm)
Hi Tim, yours device looks great ! :-)
One question: why didn't you use SDRam in this version like in the first version ?
-
Is the price really a problem? The price difference of an LCD based device and an OSD based device is about 10 euros.
Yes. If we want someone to mass produce them at a price that is inoffensive, and leaves the developer a good margin so they develop something else. Also the LCD's dont have a good MTBF. I know I develop with them.
The device that you are talking about already exist:
I've seen it, but it doesn't work with RGB output and no-one (outside the US) uses anything else do they?
But what do you do when you need to plug the emulator on this kind of "computer" ?
True, that is a case where you need the LCD.
-
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.
-
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.
-
Hello Tim, i want to know if you will ever do those floppy emulators at a price, because i'm not good at electronic skills. Have you done it already?
It's a good and interesting project and i'm following it since i first hear of it.
Thanks in advance!!!!
-
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?
Yes, Original file image are converted to a prepared MFM file. The emulator simply read MFM data directly from this file and send it through the Pic EUSART.
-
I act in a role of a tester of the floppy emulator 'megadrive' from tnt23.
I confirm, that work goes by accelerated tempo, for last month tnt23 has let out about seven versions of updatings, and some times it was necessary to solder some contacts.
By the current moment the basic modes work on a1200, and correctly works with dos diskettes. Gradually the same comes to life the rest.
That represents megadrive at me (tnt23 will probably do on another, it that has made with it)
(http://kawai.spb.ru/files/lj/megadrive/megadrive.jpg)
On controller board: floppy and power connector, SD cardreader, IDE connector (megadrive is able to read images and from SD, and from IDE hard drives, or CF on CF2IDE adapter), speaker (emulates a sound of the disk drive)
I have transferred the display and buttons on a separate board, for convenience of management. It looks here so:
(http://kawai.spb.ru/files/lj/megadrive/mega_pad.jpg)
As on pad I plan to transfer led of ide/sd/floppy activity.
Possibly later I shall place it inside of any old gamepad or something similar.
The board is located inside of the case, pad remains outside, it is not required changes of the case.
(http://kawai.spb.ru/files/lj/megadrive/mega_inst.jpg)
For storage or movemen pad it is easily disconnected, the cable can be hidden inside of the case.
(http://kawai.spb.ru/files/lj/megadrive/mega_int2.jpg)
Screenshots during work:
(http://kawai.spb.ru/files/lj/megadrive/mega_1.jpg) (http://kawai.spb.ru/files/lj/megadrive/mega_2.jpg)
(http://kawai.spb.ru/files/lj/megadrive/mega_3.jpg) (http://kawai.spb.ru/files/lj/megadrive/mega_4.jpg)
(http://kawai.spb.ru/files/lj/megadrive/mega_5.jpg) (http://kawai.spb.ru/files/lj/megadrive/mega_6.jpg)
(http://kawai.spb.ru/files/lj/megadrive/mega_7.jpg)
-
I have just finished reading this whole thread... I must admit that this project looks awesome. :-)
I have a few questions though.
1) How do you interface the card with different computers? For instance, the connector pinout of the floppy interface is slightly different on the PC and Amiga for example. How does the card know which kind of a computer it is connected to? Is this all selectable through software, or is there a jumper of some kind?
2) For the buffer, I guess you just use a 4 MB simm, right? what if you haven't got a 4 MB simm, would the interface work with (e.g.) an 8 MB one? Also are there any limitations on the type of SIMMs you can use (FPM/EDO/Buffered...)?
3) A question for alexh: you mentioned a "default boot image (dual-format) coded for the Amiga/ST". How can you create a single image that is bootable on both Amiga and the ST?? :-? That doesn't sound right...
-
I have a few questions though.
1) How do you interface the card with different computers? For instance, the connector pinout of the floppy interface is slightly different on the PC and Amiga for example. How does the card know which kind of a computer it is connected to? Is this all selectable through software, or is there a jumper of some kind?
Connector on PC and Amiga identical, the difference in signals was processed in software.
At this time there is a menu item to switch. but it may changed many times to the release.
2) For the buffer, I guess you just use a 4 MB simm, right? what if you haven't got a 4 MB simm, would the interface work with (e.g.) an 8 MB one? Also are there any limitations on the type of SIMMs you can use (FPM/EDO/Buffered...)?
At this time Megadrive use only about 2.5 MB ram, so any simm that more 3MB are okay.
-
@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.
-
Wow, this might be the answer Super Magicom owners have been looking for since 1992 :)
Great work, can't wait to get hold of one of these.
-Joel
-
@TNT23:
Superb work 'till now.
For the people willing to use it in big box Amigas, it's a simple matter of move the display and buttons to a front panel, maybe in a 5 1/4" fascia.
I want the hardware as is it now!
-
For the people willing to use it in big box Amigas, it's a simple matter of move the display and buttons to a front panel, maybe in a 5 1/4" fascia.
Now it is a problem.
The height of the display is more than height 5.25 drive bay.
Now we argue with tnt23 on how should look his "megadrive".
It suggests to do its built in, and to do holes in Amiga case.
I approve, that it is necessary to do so, that the device would be possible to add and to remove simply, without changes of the case, i.e. to be only used floppy slot (for card reader) and eject button hole (to connect external pad).
-
Xenepp wrote:
Wow, this might be the answer Super Magicom owners have been looking for since 1992 :)
Surely SuperMagicom owners use the parallel port interface? I know I did.
-
alenppc wrote:
3) A question for alexh: you mentioned a "default boot image (dual-format) coded for the Amiga/ST". How can you create a single image that is bootable on both Amiga and the ST?? :-? That doesn't sound right...
Where have you been for the last 18 years?
There were 10's of games with DualFormat disks and 100's of Magazine coverdisks.
Lethal Xcess,
Monster Business,
Starglider 2,
Stunt Car Racer,
Bionic Commando,
3D-Pool,
Carrier Command,
Indiana Jones,
Zero Magazine,
ST-Amiga Format Magazine
"The One For 16-bit games" Magazine
etc. etc.
Rick Dangerous II is Tri-Format supporting Atari-ST, Amiga and PC on one disk!
The technique I *think* was discovered and utilised mainly by "Rob Northen Computing" but it may have been simultaneously developed elsewhere.
-
alexh wrote:
Where have you been for the last 18 years?
There were 10's of games with DualFormat disks and 100's of Magazine coverdisks.
Lethal Xcess,
Monster Business,
Starglider 2,
Stunt Car Racer,
Bionic Commando,
3D-Pool,
Carrier Command,
Indiana Jones,
Zero Magazine,
ST-Amiga Format Magazine
"The One For 16-bit games" Magazine
etc. etc.
Rick Dangerous II is Tri-Format supporting Atari-ST, Amiga and PC on one disk!
The technique I *think* was discovered and utilised mainly by "Rob Northen Computing" but it may have been simultaneously developed elsewhere.
I admit I never ever heard of this feature before. :-o But how is it possible? The file systems are completely incompatible, so how do you create a multi-filesystem disk?? And if you use a non-dos encoding for the Amiga, then surely the bootblock won't be read by any other machine... non-dos disks are not supported on MS-DOS and I would suspect Atari either (but not sure about this one).
-
Small games that three different versions fit on one disk. They would be non-dos disks so the filesystem does not matter as they would be cutom and handled by the bootloader
-
You are thinking at the data block level. I am not 100% sure but I *think* it is done at the MFM level
-
JJ wrote:
Small games that three different versions fit on one disk. They would be non-dos disks so the filesystem does not matter as they would be cutom and handled by the bootloader
As I wrote above "And if you use a non-dos encoding for the Amiga, then surely the bootblock won't be read by any other machine... non-dos disks are not supported on MS-DOS and I would suspect Atari either (but not sure about this one)." ;-)
Well, I will definitely have to look into this...
-
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?
Yes, Original file image are converted to a prepared MFM file. The emulator simply read MFM data directly from this file and send it through the Pic EUSART.
If you want, i can add a new output file format in the software for your emulator !
The only thing to do is specify it! :-)
-
Hi tnt23.
Great project! I'am looking forward, that you hopefully release your great project files in a not so far future ;-) ?
I really would like to build one or more of these devices. I prefer DIL package, but SMD is also a possibility.
So if you use eagle as the layout software, the smd avr could be easily replaced with a dip avr and a new board routed..
I have just placed an order at pcbcart in china.. I will know
in 2 weeks, how the quality is ;-) The price in quite cheap!
Many thanks,
Peter
-
So.. another dead project..?
Too bad! Why do we have 2 projects, and with both, it takes weeks to get an answer, if you get one at all..?
BTW:
The pcb's ordered from china where excellent quality for an unbeatable price.. just to let one know.. (pcbcart.com).
Peter
-
I think there are 3 projects
-
This is an awsome project! Great work.
I want two of them!!! When ill it be available (extimate) and how mutch is it expected to cost?
-
I'd like parallel port version and driver so that card is seen as HDD.
-
Get making it then. I've not had a parallel port on any of my last two motherboards. No-one is going to make parallel port designs these days are they?
-
alenppc wrote:
I admit I never ever heard of this feature before. :-o But how is it possible? The file systems are completely incompatible
Ah, you never experienced the ST Amiga Format coverdisks!
I'm not 100% sure of the technical details, but believe the ST side of things was to mark the disk as single-sided and any Amiga-specific tracks/sectors as "bad" as far as the ST was concerned.
Likewise for the Amiga, it was marked to use the other side of the disk and the ST tracks/sectors as "bad".
It also helped that the Amiga would look at track 40 for its directory, etc, whereas the ST would look at track zero.
Something like that, anyway! It was a long time ago!
- Ali
-
Any news on the project?
-
It work very well to me.
Read all dos and non dos from .adf images.
Write to .mfm images (save games, temp files, etc)
Work good in my 600/1200, and with 4000 (only in external box at this time).
-
alexh wrote:
I think there are 3 projects
Wrong, there are at least 5 projects, even more:
SVD Floppy Emulator:
http://www.thesvd.com/SVD/
the "MegaDrive":
http://www.sensi.org/~tnt23/megadrive/
the HxC Floppy Emulator USB/SDCARD:
http://hxc2001.free.fr/floppy_drive_emulator/
the SdiskEmul:
http://atariamiga.free.fr/sdiskemul.php
the TFE : Tolga Floppy Emulator:
http://www.commodore.gen.tr/forum/index.php?topic=2278.0
Additionnaly there are some others "commercials" devices :
http://www.datex.fr/emulateur/DTX200_EN.pdf (an industrial grade floppy emulator)
and some others floppy remplacement for musical instrument...
So the floppy emulator is now an "classical" concept/project.
-
ok, so the way I see it at the moment is:
(http://petersieg.webng.com/Floppy_Emulatoren.jpg)
I did not include TFE - I don't understand the language ;-) and it don't seem to be ready for consideration..
So, since I am seeking for Amiga usage, the HxC and SDiskEmul are the best options/projects.. Hopefully at HxC the release of pcb layout files will be not so far in the future..
There seems to be an odering of devices in progress of SDiskEmul right now!!
MegaDrive seems to be dead to me.. too bad!!
And SVD ist just fine, but no Amiga format supported..
Peter
-
Some corrections :
HxC Floppy Emulator support those computers :
Atari ST,Amiga, Amstrad CPC6128, Korg DSS-1, Oric+MicroDisk, PC (720kB & 1.44MB), Super Wildcard DX-SWC3201 (Super NES/famicom rom loader), MSX 2 .
Some others support are planed.
The emulator support copy protections (Pasti/STX images, IPF/Caps/SPS images, etc).
More informations here : http://hxc2001.free.fr/floppy_drive_emulator/index.html
the PCB of the USB version are available from 1 or 2 years! (you can read some small reviews from people who make the device here :
http://torlus.com/floppy/forum/viewtopic.php?t=125 ,
http://torlus.com/floppy/forum/viewtopic.php?t=109 ,
http://www.reflexmusic.de/DSS-1/HxCEmu.htm ,
http://torlus.com/floppy/forum/viewtopic.php?t=144 ,
...
)
additionnaly a small batch of 21 devices was made this year:
http://torlus.com/floppy/forum/viewtopic.php?t=129&postdays=0&postorder=asc&start=0
Actually SdiskEmul's pcb seems to be not available !
-
Hi Jeff.
Thank you for the corrections. I didn't want to upset you and your great project!
You said:
"the PCB of the USB version are available from 1 or 2 years!"
Yes, but in a format, that one can make oneself a single copy with printing on photo-pcb and using chemicals and drilling holes at the end..
That ist not what I ment.. I ment in a format that a pcb manufacturer can directly use (eagle/gerber).
You said:
"Actually SdiskEmul's pcb seems to be not available!"
According to the web site, it should be in the zip archive.
(I didn't check that myself)
So for me, I am only able to start to ask for pcb prices when I have a suitable format.. So I hope, that you are releasing them when you find some time..
Many thanks for your work!
Peter
-
So for me, I am only able to start to ask for pcb prices when I have a suitable format..
For one device ? this will be very expensive ! ;-)
Seriously it cost ~30euros with pcbpool for one 1 pcb:
PCB-POOL Prototype double sided: 30.63 EUR
Length in mm: 100
Width in mm: 100
File name: floppyemu.max
File format: ORCAD
Delivery time: 8 working day (WD)
Soldermask: no
Position print / Silkscreen: no
Would you like to buy overdelivery at half price if available? no
Do you require electrical test? no
So I hope, that you are releasing them when you find some time..
this should be done this WE :-).
You said:
"Actually SdiskEmul's pcb seems to be not available!"
According to the web site, it should be in the zip archive.
(I didn't check that myself)
i didn't found it!
-
@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: ok. Are you also planning to release eagle files and firmware on your web side? Looking forward to that..!!
@Jeff: I would not ask for a single pcb, but rather for 20,30 up to 50 pcb's.. there are already some interrest in the forum64 and a lot of other places.. but mostly for the stand alone version.. That should bring the price down to <10€ per piece..
BTW: How to get the FPGA software into the FPGA an startup..?
Do you need this to load from pc everytime you power up the device..? I didn't see a special flash to load from..?
Looking also forward to the release of pcb files..
Many thanks, Peter
-
@Jeff: I would not ask for a single pcb, but rather for 20,30 up to 50 pcb's.. there are already some interrest in the forum64 and a lot of other places.. but mostly for the stand alone version.. That should bring the price down to <10€ per piece..
right, but the standalone version isn't ready: no copy protection emulation and no write support for amiga !
BTW: How to get the FPGA software into the FPGA an startup..?
Do you need this to load from pc everytime you power up the device..? I didn't see a special flash to load from..?
it's not an fpga but an cpld ! so i don't need flash ! ;-)
Looking also forward to the release of pcb files..
you can find all you need in this file:
http://hxc2001.free.fr/floppy_drive_emulator/HxCFloppyEmulator_ipcore.zip
-
Hi.
Many Thanks!
I was not aware off, that the stand alone version is not ready in the mentioned functionality..
Oh, a CPLD, ok.. the bitstream is flashed inside and stays after power loss.. fine.
So from the homebrew directory, I see that the pcb size is 87 x 96mm.. correct?
I will optain a quote from pcbcart.. we will see..
EDIT: Quote: 87x96 2 sides under 300 holes is app. 100€ for 20 pieces + shipping (app. 25€) = 125€/20 = app. 6,50€/Piece.
I have problems understanding the working of the usb version..
One connect the floppy cable to the floppy connector on the pcb. An usb cable connection between pcb and pc... ok.
Is there a usb driver required?
Which Software Part is needed on pc side? Same as for the stand alone version..?
Thanks, Peter
-
So from the homebrew directory, I see that the pcb size is 87 x 96mm.. correct?
no, you must take the "prod" version : 100mm*100mm 2 layers
Is there a usb driver required?
yes : this one http://www.ftdichip.com/Drivers/D2XX.htm
Which Software Part is needed on pc side? Same as for the stand alone version..?
yes the same !
if you have more questions about HxCFloppyEmulator,it is better to put them on this forum : http://www.torlus.com/floppy/forum/index.php.
it's not the HxCFloppyEmulator thread but the "Megadrive" thread here ;-)
-
Thanks.. but on megadrive is so much silence..? ;-)
Strange, when I click on the link, I get 404.. when I copy it to the url box of my browser it works..?
Please allow 2 more questions.
1. Are you planning to release the pcb files also for the stand alone version? Probably also as a 2 layer design to save space?
2. Does a pc with the mentioned software needs to be running all the time, or is one floppy image stored inside the usb version in flash(sram?=loss when power is off)?
Sorry for the many questions.. but I want to make sure all my questions are answered, before I invest so much money..
(for me at least..)
Many thanks,
Peter
-
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: ok. P-Cad.. another one ;-) Anyway, I wish you all the best for your project and will stop by from time to time to see your progress.. If I can be of any help.. just let me know..
Best regards, Peter
-
Hi,
I'm curious to know, have you had any time to spend lately on this? :)
-
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.
-
Im just happy to see that you are hanging in there:)
Keep up the motivation, and ask if you need any motivational help:)