Hi, I saw this project and it looks interesting for use with the Sanyo MBC-55x computer. I'm writing a BIOS for that machine and I was wondering what kind of capabilities this floppy emulator can offer.
A few questions:
1: Is there a cost reduced version without LCD, buttons, speaker? (I saw mention of a version without LCD but didn't find pricing info)
2: Can the host machine format tracks, or is operation strictly limited to reading tracks and writing sectors? Related but slightly different, can the emulator clone a disk being read out by another drive on the same cable?
3: [edit: just found that this capability is present from the changelog] If the emulator doesn't provide functions to format tracks under host machine control, is it possible to access the SD data directly through the floppy interface, so that this can be accomplished another way? Once the device is installed it wouldn't be an option to put the SD card in another PC.
4: Can a stored disk in MFM format be read out in FM format? This slower data rate might be advantageous for streaming audio so the CPU isn't as overwhelmed moving floppy data (I've yet to work out all the details on audio playback with this machine, though it seems with a low pass filter before the speaker, at least something recognizable should be heard).
Thanks!
A few questions on emulator use with custom machine BIOS
Re: A few questions on emulator use with custom machine BIOS
1- No, not for the moment.bradn wrote:Hi, I saw this project and it looks interesting for use with the Sanyo MBC-55x computer. I'm writing a BIOS for that machine and I was wondering what kind of capabilities this floppy emulator can offer.
A few questions:
1: Is there a cost reduced version without LCD, buttons, speaker? (I saw mention of a version without LCD but didn't find pricing info)
2: Can the host machine format tracks, or is operation strictly limited to reading tracks and writing sectors? Related but slightly different, can the emulator clone a disk being read out by another drive on the same cable?
3: [edit: just found that this capability is present from the changelog] If the emulator doesn't provide functions to format tracks under host machine control, is it possible to access the SD data directly through the floppy interface, so that this can be accomplished another way? Once the device is installed it wouldn't be an option to put the SD card in another PC.
4: Can a stored disk in MFM format be read out in FM format? This slower data rate might be advantageous for streaming audio so the CPU isn't as overwhelmed moving floppy data (I've yet to work out all the details on audio playback with this machine, though it seems with a low pass filter before the speaker, at least something recognizable should be heard).
Thanks!
2- Read Track - Write sector only.
This could change in the future.
Why did you need this feature ?
3- Yes but what is the purpose ?
4- To slowdown the floppy throughput you can increase the gap3 len.
The main reason I'd like to be able to format tracks is that for real disks, I may want to use unusual sector layouts (say, 5 1KB sectors and a 128 or 256 depending what fits) to fit more data while still allowing random access, as well as using tracks in raw mode for even more storage (may be useful for audio to fit ~510KB on a disk, but could require extra processing because a few data values can't be easily written). Having the emulator support this just improves consistency of the virtual drive and will let me both easily copy these disks into images or create them directly on the emulator.
Normally changing the gap lengths could help for streaming purposes but it's not the sector gap time I'm worried about, it's that there is no DMA controller in this machine so the CPU is rather busy moving data. I believe a mod to enable FM/MFM selection should only need cutting one trace and connecting 2 or 3 wires, and should be backwards compatible with Sanyo software.
I may be able to accomplish some goals here without FM encoding, but it's going to result in a hulking mess of tangled virtual DMA code - basically, when using the floppy and doing anything else at the same time, there isn't time to constantly poll the DRQ status to synchronize transfers, but instead it must be at least mostly timed out by CPU execution cycles with infrequent status tests to adjust sync (when reading). The code will become convoluted and ugly since different execution paths must be used to handle varying phases of data movement.
The problem is I'd like to transfer at a rate of 32000 bytes (disk) + 9825 bytes (audio) per second with both endpoints using 2 byte max buffers, and ease into and out of the floppy transfer without disrupting audio, on a machine where instruction bytes can be loaded at max 890K/s and anything that touches memory or I/O is even slower.
So a floppy reading + audio DMA engine might look like...
shut down audio IRQ & initiate disk transfer
sync to audio output phase
;waiting for transfer to begin
loop {
--write audio
--check disk transfer status, jump into main loop if ready
--prepare audio
--check disk transfer status a few times, jump into main loop if ready
--exact delay to sync to audio speed
}
;transfer has begun
loop {
--read disk byte & store
--loop {
----check audio buffer and maybe write audio
----read disk byte & store
--}
--check disk transfer status
--prepare audio data
--check disk transfer status
--read disk byte & store
--delay differently depending if & where disk buffer was empty at checks
}
restart audio IRQ
It would be nice if it can be this "simple" but I suspect it may grow even more complex than that to handle timing precisely enough, and I'll be happy if I ever make it work correctly at MFM speed, but FM speed should be comparatively easy and probably simpler than above, and would probably have time to buffer keyboard input as well.
Normally changing the gap lengths could help for streaming purposes but it's not the sector gap time I'm worried about, it's that there is no DMA controller in this machine so the CPU is rather busy moving data. I believe a mod to enable FM/MFM selection should only need cutting one trace and connecting 2 or 3 wires, and should be backwards compatible with Sanyo software.
I may be able to accomplish some goals here without FM encoding, but it's going to result in a hulking mess of tangled virtual DMA code - basically, when using the floppy and doing anything else at the same time, there isn't time to constantly poll the DRQ status to synchronize transfers, but instead it must be at least mostly timed out by CPU execution cycles with infrequent status tests to adjust sync (when reading). The code will become convoluted and ugly since different execution paths must be used to handle varying phases of data movement.
The problem is I'd like to transfer at a rate of 32000 bytes (disk) + 9825 bytes (audio) per second with both endpoints using 2 byte max buffers, and ease into and out of the floppy transfer without disrupting audio, on a machine where instruction bytes can be loaded at max 890K/s and anything that touches memory or I/O is even slower.
So a floppy reading + audio DMA engine might look like...
shut down audio IRQ & initiate disk transfer
sync to audio output phase
;waiting for transfer to begin
loop {
--write audio
--check disk transfer status, jump into main loop if ready
--prepare audio
--check disk transfer status a few times, jump into main loop if ready
--exact delay to sync to audio speed
}
;transfer has begun
loop {
--read disk byte & store
--loop {
----check audio buffer and maybe write audio
----read disk byte & store
--}
--check disk transfer status
--prepare audio data
--check disk transfer status
--read disk byte & store
--delay differently depending if & where disk buffer was empty at checks
}
restart audio IRQ
It would be nice if it can be this "simple" but I suspect it may grow even more complex than that to handle timing precisely enough, and I'll be happy if I ever make it work correctly at MFM speed, but FM speed should be comparatively easy and probably simpler than above, and would probably have time to buffer keyboard input as well.
With the emulator you can reduce the bitrate of the floppy (+/- 15%), and make very special floppy image (with for example 30 sectors per trackbradn wrote:The main reason I'd like to be able to format tracks is that for real disks, I may want to use unusual sector layouts (say, 5 1KB sectors and a 128 or 256 depending what fits) to fit more data while still allowing random access, as well as using tracks in raw mode for even more storage (may be useful for audio to fit ~510KB on a disk, but could require extra processing because a few data values can't be easily written). Having the emulator support this just improves consistency of the virtual drive and will let me both easily copy these disks into images or create them directly on the emulator.
Normally changing the gap lengths could help for streaming purposes but it's not the sector gap time I'm worried about, it's that there is no DMA controller in this machine so the CPU is rather busy moving data. I believe a mod to enable FM/MFM selection should only need cutting one trace and connecting 2 or 3 wires, and should be backwards compatible with Sanyo software.
I may be able to accomplish some goals here without FM encoding, but it's going to result in a hulking mess of tangled virtual DMA code - basically, when using the floppy and doing anything else at the same time, there isn't time to constantly poll the DRQ status to synchronize transfers, but instead it must be at least mostly timed out by CPU execution cycles with infrequent status tests to adjust sync (when reading). The code will become convoluted and ugly since different execution paths must be used to handle varying phases of data movement.
The problem is I'd like to transfer at a rate of 32000 bytes (disk) + 9825 bytes (audio) per second with both endpoints using 2 byte max buffers, and ease into and out of the floppy transfer without disrupting audio, on a machine where instruction bytes can be loaded at max 890K/s and anything that touches memory or I/O is even slower.
So a floppy reading + audio DMA engine might look like...
shut down audio IRQ & initiate disk transfer
sync to audio output phase
;waiting for transfer to begin
loop {
--write audio
--check disk transfer status, jump into main loop if ready
--prepare audio
--check disk transfer status a few times, jump into main loop if ready
--exact delay to sync to audio speed
}
;transfer has begun
loop {
--read disk byte & store
--loop {
----check audio buffer and maybe write audio
----read disk byte & store
--}
--check disk transfer status
--prepare audio data
--check disk transfer status
--read disk byte & store
--delay differently depending if & where disk buffer was empty at checks
}
restart audio IRQ
It would be nice if it can be this "simple" but I suspect it may grow even more complex than that to handle timing precisely enough, and I'll be happy if I ever make it work correctly at MFM speed, but FM speed should be comparatively easy and probably simpler than above, and would probably have time to buffer keyboard input as well.
You can also make a mixed floppy image (some track in MFM some in FM.
If you want keep the real floppy disk compatibity, you should be able to make the 5*1024+1*512 format easily with the software tools (this format is used by some keyboards, and the emulator already support them)
Some tech docs:
https://hxc2001.com/floppy_drive_emulat ... 20mode.pdf
https://hxc2001.com/floppy_drive_emulat ... format.pdf
Very cool, thanks for the info. I'll have to save up for one of these! It even allows different track types on the same disk.
I had another bizarre thought, does the virtual floppy drive emulate the behavior of the write protect tab and index sensor when switching diskettes with the "front panel" buttons? It would be a cheap way to achieve disk change notification for both emulated and real drives on a system like this that uses ready instead of changeline.
The signal sequence would be like:
(removing disk)
Index hole becomes covered if it landed open at last stop -> Index goes inactive
Notch no longer over write protect sensor -> WP goes active
Edge of disk goes past index sensor -> Index goes active
Edge of disk goes past WP sensor -> WP goes inactive
I'm toying with the idea of a small animation displayed when disks are inserted or removed that makes use of this, but it must be the best way to implement disk change notification for FreeDOS. It's interesting in that it can differentiate betwen a disk pulled out part way and put back in and one taken out entirely (or almost), as long as the drives are checked frequently enough.
I see that it's possible to detect disk change in direct access mode, but reading status lines is very inexpensive compared to reading a sector.
Are any other systems known to use a scheme like this, or any that don't register changed disks if it's not implemented now?
I had another bizarre thought, does the virtual floppy drive emulate the behavior of the write protect tab and index sensor when switching diskettes with the "front panel" buttons? It would be a cheap way to achieve disk change notification for both emulated and real drives on a system like this that uses ready instead of changeline.
The signal sequence would be like:
(removing disk)
Index hole becomes covered if it landed open at last stop -> Index goes inactive
Notch no longer over write protect sensor -> WP goes active
Edge of disk goes past index sensor -> Index goes active
Edge of disk goes past WP sensor -> WP goes inactive
I'm toying with the idea of a small animation displayed when disks are inserted or removed that makes use of this, but it must be the best way to implement disk change notification for FreeDOS. It's interesting in that it can differentiate betwen a disk pulled out part way and put back in and one taken out entirely (or almost), as long as the drives are checked frequently enough.
I see that it's possible to detect disk change in direct access mode, but reading status lines is very inexpensive compared to reading a sector.
Are any other systems known to use a scheme like this, or any that don't register changed disks if it's not implemented now?