Page 1 of 1

Floppy motor signals

Posted: Wed Aug 12, 2020 3:11 pm
by retrorepair
Can anyone point me to where these are located in this core or if they even exist since this is ported from software?

I need the motor_on, step, direction and select signals.

Re: Floppy motor signals

Posted: Wed Aug 12, 2020 4:23 pm
by AntialiasedPixel
I would be surprised if that overhead is emulated in the fpga, seems like it would be easier to just wire the floppy controller to stream in data from the .img files. Could be wrong though, but curious on what project you have in mind? Maybe audio to emulate drive access sounds?

Re: Floppy motor signals

Posted: Wed Aug 12, 2020 8:02 pm
by retrorepair
It's in the amiga and atari st cores and quite a few emulators too.

This is what I'm working on:

https://twitter.com/whybrow_joel/status ... 15106?s=19

The hardware is done and I've got the Amiga core working great, the ST core is WIP, just going through and adding support for the rest.

Re: Floppy motor signals

Posted: Wed Aug 12, 2020 8:06 pm
by retrorepair
This was while prototyping:

https://twitter.com/whybrow_joel/status ... 34208?s=19

Buzzer (bit lame IMHO)

https://twitter.com/whybrow_joel/status ... 33538?s=19

And some Atari ST loading:

https://twitter.com/whybrow_joel/status ... 33475?s=19

It is just controlling the drive motors, no data transfer at all but the sound is so important to me so quite happy with it. No read errors either 😉

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 12:04 am
by AntialiasedPixel
That's awesome, I hope those signals are available on the ao486 core, and that you can get something similar working there. Drive sounds were a big part of the nostalgia! Most of my gaming growing up was on DOS PCs, so anything that can makes ao486 better is exciting to see.

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 9:26 am
by retrorepair
I found this in /rtl/soc/floppy/floppy.v

Code: Select all

    (io_address == 3'd2)?   { 3'b0, motor_enable, dma_irq_enable, enable, selected_drive } :        //digital output register
This looks like it could be it, motor_enable is self explainatory, selected drive I assume will be your sel signal, enable = step? dma_irq_enable can't be direction..

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 9:27 am
by retrorepair
AntialiasedPixel wrote: ↑Thu Aug 13, 2020 12:04 am That's awesome, I hope those signals are available on the ao486 core, and that you can get something similar working there. Drive sounds were a big part of the nostalgia! Most of my gaming growing up was on DOS PCs, so anything that can makes ao486 better is exciting to see.
Yep, though the most nostalgic sound of all won't be present.. that all too familiar read error sound :lol:

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 11:42 am
by ToothbrushThreepwood
Are you nostalgic/masochistic enough to do HDD and fan sounds too? Whenever I power up my old desktop PC I’m equally annoyed and pleased with the vacuum-cleaner-esque symphony of noises that thing makes compared to my everyday-use modern laptop. It’s such a distinct sound environment that just takes me back to the good old alow days :)

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 12:05 pm
by retrorepair
For the HDD: USB to IDE and plop all your files on an old Quantum Fireball :)

Fans? I believe they just need 12v ;)

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 3:26 pm
by ToothbrushThreepwood
retrorepair wrote: ↑Thu Aug 13, 2020 12:05 pm For the HDD: USB to IDE and plop all your files on an old Quantum Fireball :)

Fans? I believe they just need 12v ;)
Haha! We’re talking hardware preservation here, not using old hardware :D

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 3:32 pm
by retrorepair
ToothbrushThreepwood wrote: ↑Thu Aug 13, 2020 3:26 pm
retrorepair wrote: ↑Thu Aug 13, 2020 12:05 pm For the HDD: USB to IDE and plop all your files on an old Quantum Fireball :)

Fans? I believe they just need 12v ;)
Haha! We’re talking hardware preservation here, not using old hardware :D
Well my adapter uses a real floppy drive so still not hardware preservation, more hardware authentication :lol:

Re: Floppy motor signals

Posted: Thu Aug 13, 2020 8:37 pm
by LamerDeluxe
Great to see this project is still being worked on. I still wonder if something could be done with one of those tiny haptic motors used in phones (the solenoid axial style ones, not the spinning vibration motors).

Re: Floppy motor signals

Posted: Sat Nov 07, 2020 10:22 pm
by mahen
Hi ! I'm a big fan of this feature (Minimig core) -- using Antonio Villena's IO Board which has the buzzer built-in.
Is it actually implemented in the Atari ST core ? Doesn't seem to be the case.
As it's an "unofficial" feature, do you think it will be maintained in the future ? Thanks a lot !

Re: Floppy motor signals

Posted: Sun Nov 08, 2020 1:43 pm
by NightShadowPT
I hope this makes it into the official cores. May be stupid for some, but sound plays a big part on nostalgia and I always enable floppy sounds when I use WinUAE :)
ToothbrushThreepwood wrote: ↑Thu Aug 13, 2020 11:42 am Are you nostalgic/masochistic enough to do HDD and fan sounds too? Whenever I power up my old desktop PC I’m equally annoyed and pleased with the vacuum-cleaner-esque symphony of noises that thing makes compared to my everyday-use modern laptop. It’s such a distinct sound environment that just takes me back to the good old alow days :)
Not sure if I would like to have this playing all the time, but having the sound of an old PC during the boot process of AO486 would be amazing (HDD spin ups, memory check clicks, fans, that distinct electrical "oooommmmm").

Re: Floppy motor signals

Posted: Sun Nov 08, 2020 2:02 pm
by mahen
Well, there must be a difference between floppy & HDD sounds, because you cannot reduce floppy access times that much when emulating a standard A500/A1200, and it gives a good indication of what's happening. Also it's great when it makes you realize some games / demos are getting data without interrupting the action. Well, I don't know, I feel very frustrated now when I don't get the floppy sounds. :) But sure, it's mostly nostalgia and also a little useful !

But isn't the whole MiSTer thing mostly about nostalgia anyway ??

Re: Floppy motor signals

Posted: Sun Nov 08, 2020 10:59 pm
by pgimeno
Not just nostalgia, it's also some audible feedback about activity.

Re: Floppy motor signals

Posted: Thu Dec 03, 2020 10:13 am
by mahen
Hi ! Would it be possible to bring the floppy sound buzzer support upstream ? It's great, useful, very simple, and doesn't IMHO compromise anything to add it.

It's a bit annoying to have to use an alternate build for this feature. Also, bringing it upstream would enable other people to add it to their IO Boards at a ridiculously low price.

Re: Floppy motor signals

Posted: Tue Dec 08, 2020 6:38 am
by NightShadowPT
mahen wrote: ↑Thu Dec 03, 2020 10:13 am Hi ! Would it be possible to bring the floppy sound buzzer support upstream ? It's great, useful, very simple, and doesn't IMHO compromise anything to add it.

It's a bit annoying to have to use an alternate build for this feature. Also, bringing it upstream would enable other people to add it to their IO Boards at a ridiculously low price.
Assuming it does not have any downsides, I second this request. Can this be made as a pull request on the main branch?

Re: Floppy motor signals

Posted: Tue Dec 08, 2020 11:57 am
by Caldor
Sure would be nice with official support. But there are more than one project to add floppy support right now... Sorg might be wanting to find a solution that can support floppy drives for cores in general. But it might also just be because he does not seem to find it important or relevant to support floppy drives. I have tried arguing that it should obviously be relevant. For me its one of the big reasons that I support FPGA, because the biggest benefit of FPGA, as I see it, is without doubt its ability to have native hardware support for stuff like floppy disks, CD drives, old types of screens and TVs, original controllers and so on.

Having floppy drive support for AO486 and the Minimig Amiga core is something I am hoping to see happen soon... and I pretty much expect it to happen sooner or later. But it might be relevant to figure out what the best solution would be to implement. Although I guess it might also make sense to just support several solutions, if that is possible using options in the cores. Might complicate the cores and take up core FPGA space though.