Disk Drive Sounds

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • The one feature I envy about the Ultimate products is their ability to mimic the 1541 disk drive sounds. Of course part of it is nostalgia, but I've also realized that the disk drive sounds actually play a significant part of the UX. It's very common for C64 games or programs to have a "press a key to continue" message, and the only immediate feedback you get when you press a key is the sound of the disk drive spinning up. And although the TC64 does replicate the disk drive light, it is often obscured for me by the buttons or the computer depending on where I'm sitting, and it would be so much better if there was sound too.


    I'm guessing that it's infeasible due to memory/FPGA limitations to pipe audio samples of a disk drive into the TC64 audio output.


    But I was wondering if it would be possible to have a mode that causes a real 1541 disk drive plugged into the TC64 IEC port to mimic the sounds/light/motor movements of the simulated drive in the FPGA without actually reading or writing any data? Then the sounds of the disk drive would be reproduced with perfect fidelity. :)

  • But I was wondering if it would be possible to have a mode that causes a real 1541 disk drive plugged into the TC64 IEC port to mimic the sounds/light/motor movements of the simulated drive in the FPGA without actually reading or writing any data?

    Remember that the 1541 is a computer of it's own: A 6502 CPU with peripherals, ROM and RAM (though not much of the latter). Executing the exact same code would require it to run in cycle-exact lock-step and listen on the IEC bus for whatever commands come flying by. Then the code would have to be re-written in real-time to not alter any bits on the IEC. This does not sound like a fun thing to code, and given the limitation of CPU power, you won't be able to make it in real-time.


    Why not just look at the debug output at the top of the VGA screen? That tells you A LOT about what the computer and the drive "currently" do. Even more than what sounds and the drive LED tell you. It's what I always dreamed about when I was a teenager.

  • Remember that the 1541 is a computer of it's own: A 6502 CPU with peripherals, ROM and RAM (though not much of the latter). Executing the exact same code would require it to run in cycle-exact lock-step and listen on the IEC bus for whatever commands come flying by. Then the code would have to be re-written in real-time to not alter any bits on the IEC. This does not sound like a fun thing to code, and given the limitation of CPU power, you won't be able to make it in real-time.

    For the sake of making sounds, I was thinking this could potentially be accomplished without needing to fully mirror what the real and FPGA drives are doing in terms of 6502 and ROM/RAM, etc. It really just needs to roughly mimic the things that actually make sounds, ie. the drive motor starting/stopping, the stepper motor moving to positions, and the LED being in the error flashing state (probably a few other things I'm forgetting). Your FPGA knows the exact positions of all the virtual motors and the LED state. Couldn't these be translated into a simple set of special IEC commands sent to real drive that pretty closely mimic the sounds/sights of what the FPGA drive is doing? Maybe the timing of the sound wouldn't be totally perfect and some sounds might not be recreated exactly, but it would be good enough for the sake of basic sound reproduction and conveying what the FPGA drive is doing.


    I tried using the VGA status display when you suggested it before, and I can see how that's great for debugging and development, but to me that's a different use case. The text is small and not easy to figure out or read casually. And having separate mirrored LCD flatscreen in addition to my CRT doesn't feel very much like playing games in the 80s. I sometimes do develop for the C64, but most of the time I'm playing games and want a relatively authentic experience with all the original sights and sounds of the machine.


    I also think it would be a nice feature because it gives a use for disk drives that may no longer fully be working in terms of reading/writing (although my 1541 does still fully work)

  • It really just needs to roughly mimic the things that actually make sounds, ie. the drive motor starting/stopping, the stepper motor moving to positions, and the LED being in the error flashing state (probably a few other things I'm forgetting).

    One major thing that you're forgetting is that these sounds are a result of running code that is completely user-settable. You either have access to the physical lines that go to the drive motor/stepper/LED, or you are deep in cycle-exact emulation of the whole subsystem.


    Sending non-IEC related data over that bus would make it unusable for other things like a printer or a plotter. And you'd open a whole new can of worms in terms of testing and support, as this does create incompatibilities, no matter how careful you design it.


    The one and only way I see is to relay the information "step or motor on/off" somehow directly out of the Chameleon. However, this is deep in feature-creep territory, and we are feature-complete, focusing on making things work cycle-exact like the original. Once we're out of beta, I could think of a way to modulate these signals on the drive LED, so a little microcontroller and LDR can pick the signal up and generate sounds. If that fits the FPGA, it sounds like a fun DIY project.

  • Drive sounds are certainly out of scope now - we dont have the logic resources on the FPGA for that.


    As for using the real drive - that is totally out of the question and wouldnt work in most situations, if only for the simple fact that many loaders will not work with more than one device on the IEC bus. There is also no way for the second drive to even know what the other drive does without writing specific drive code for both(!) drives.

  • One major thing that you're forgetting is that these sounds are a result of running code that is completely user-settable.

    I was actually taking that into account. What I'm suggesting is to basically set up a circuit that "samples" the state of the drive motors and LED every several milliseconds. That would not be very much state information, and so it should be possible to encode all of it into a byte or two. Then that byte maybe with a header would be sent to the drive over IEC. The drive would have a small custom program loaded into its 6502 that would read this data and make its own motors and LED match the state of the FPGA drive.


    It seems to me that this could potentially be light on FPGA resources, and I would be willing to write the 1541 6502 code, create the format, and make a proof of concept, assuming this could someday become feasible.


    Sending non-IEC related data over that bus would make it unusable for other things like a printer or a plotter.

    I assumed that was the case, but I'm not sure why this is an issue? I thought it would be an IEC bus feature that you enable or disable, and that it would be isolated from the "real" IEC bus that the C64 uses. If somebody is using the "drive sound" mode, then they probably are not also using a drive to load and save things. I think a lot of people use the TC64 as a full disk drive replacement like I do. It's pretty rare that I use my drive anymore since all my 1980s disks are already archived.


    But also, I was actually imagining that this would be a feature that only works as a special independent feature on the TC64's own IEC bus, leaving the IEC bus on the actual C64 still operational as normal, unaware that there's also a real drive connected to the TC64's own IEC bus. I'm not sure if that's possible, but that design seemed simpler to me.


    Once we're out of beta, I could think of a way to modulate these signals on the drive LED, so a little microcontroller and LDR can pick the signal up and generate sounds. If that fits the FPGA, it sounds like a fun DIY project.

    What I'm proposing would basically facilitate that, and you could achieve sample-based disk drive sound playback with a relatively simple software mod to a Pi1541 setup, which many C64 enthusiasts already own.


    This all may just not be possible, but I do really love the idea and would be willing to put some time into developing the 1541 code and the drive motor/LED state protocol. I've developed similar software before.


    Thanks for taking the time to respond.

  • Quote

    It seems to me that this could potentially be light on FPGA resources, and I would be willing to write the 1541 6502 code, create the format, and make a proof of concept, assuming this could someday become feasible.

    As said, this can not be done. There is one (!) IEC bus, and if that is used for loading it cant be used for sending commands to a drive.

  • As said, this can not be done. There is one (!) IEC bus, and if that is used for loading it cant be used for sending commands to a drive.

    I should have said "IEC connector" instead of "IEC bus". For this purpose only a very small subset of IEC bus functionality is required, and it could even potentially be reduced to just a simple serial transmitter. If we forget about trying to actually support a real 1541, you could use the TC64's IEC connector to send a serial stream format of drive state data to a Pi1541, which would be running special software that interprets the data and plays the appropriate 1541 drive audio samples. This is essentially the same solution Jens proposed for the future, but I'm just saying that the IEC connector seems like a good way to get the drive state data out of the TC64 since it's basically a plug-and-play solution and many C64 enthusiasts already have the Pi1541 adapter.


    Doing it this way with a simple serial transmitter on the TC64 IEC connector would also potentially leave the possibility open of the sound system working with a real 1541 drive at some point. It seems maybe possible that with some very clever anticipation of 1541 responses and timing, that the 1541 could be programmed and controlled with just a serial transmitter and some simple state logic. Or if not, then maybe it could be achieved with a custom 1541 drive ROM. I might look into these concepts myself at some point out of curiosity, but the method described above with custom Pi1541 software and digital audio samples is obviously a lot more straightforward.

  • I should have said "IEC connector" instead of "IEC bus". For this purpose only a very small subset of IEC bus functionality is required, and it could even potentially be reduced to just a simple serial transmitter.

    What Tobias meant is that we've put a lot of effort into having two connectors (on the Chameleon and the host C64) that are logically identical with the third, internal IEC bus that "connects" the emulated drives. You'd open a huge can of worms if you want to separate that and use one of the connectors for "something else". You have no idea how much testing would ahve to go into such a feature - all drive related tests would have to be doubled, as you're adding "only one bit" ("separated or not"). If this isn't planned into the product from the very beginning, it *will* explode on you.

  • Yes, what i ment is that in the current design it is one bus. Changing that would mean a complete redesign of a core component. And it probably still wont work correctly, even the current design is short on time slots for the IEC bus. So no, this is not doable.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.