This subject was replied to in an email Fabrice Frances sent me a while ago.
In theory it should work, but please be aware of the large timings associated with floppy disks:
if you wait for the music player interrupt (polling it), service it and then issue a fdc command, it will work if the fdc command takes less than 10 ms, otherwise your music will then be out of synchro (it's not so severe if the 10 ms duration is exceeded within a reasonable margin)...
For example, when you wait for the music player interrupt, the disc continues to turn, which means that you might have already passed the next desired sector, and thus when you will ask for its reading, you will have to wait a complete rotation (i.e 200 ms without music refresh)...
This could be optimized by using a proper formatting routine, interleaving the sectors in a way that the sectors are separated by an adequate rotation angle, so that the loading is synchronized with the music loader frequency, but you will still have a problem with the first sector you load in each track...
Mhhh, I'm just taking the calculator... Here are some interesting values:
with the standard 17-sectors sedoric format, sectors come every 358 bytes, which translates to 11.456 ms (not very far from the 10 ms interval at 100 Hz), you could adapt your music-player period to synchronize with this "sector-period". Be careful though, your music routine has to be very fast otherwise you will pass over the beginning of next sector (and have a one-turn penalty, i.e 200 ms). More precisely, I would say it has to be less than a thousand cycles (roughly)...
Then you have the bigger problem: moving to the next track (with the disk rotating at the same time)...
The question is when does the first sector comes under the head ?
It depends of many things: what angle separates it from the last sector of the previous track, how fast does the head move and stabilize on the next track...
You already know about the stepping motor rate, but what is important is which stepping motor rate was used at format time, how much delay elapsed between two write-track commands when formatting, and in which order the sectors were stored when formatting...
So, it would make sense to develop a special formatting routine that reduces those delays, so that you will know for example that 11 ms after reading the last sector of a track, you will be at the correct angle to read the first sector of the next track, which gives you enough time to move the head with a stepping rate of 6 ms...
Remember also that disks formatted with the writedsk PC tool haven't got the same timing characteristics has those formatted on a real Oric, and that head move delays aren't emulated by Euphoric...
Implications of playing Music during a Disc Load
My own idea is to actually consider the problem on a track by track basis.
At maximum we have 18 sectors to load in a track. And the loading of these sectors are critical. The track change is not that important.
The idea is to have the replay routine to not actually sent data to the PSG, but instead write them in a buffer. You just preload a 256 bytes buffer with some sets of PSG values that you then dumbly send to the PSG later one at a time between each sector.
Advantage is that you have a constant time replay that can be able to replay complex sounds without taking more time.
256 bytes, 18 sectors, that's a maximum of 14 bytes per replay. That's cool it's more than enough for storing all PSG registers
Another interesting feature would be to be able to unpack data while loading. My lz77 unpacking routine is easy -I think- to adapt for such a thing, so it would be possible to unpack in realtime data coming from the 256 bytes read buffer.
At maximum we have 18 sectors to load in a track. And the loading of these sectors are critical. The track change is not that important.
The idea is to have the replay routine to not actually sent data to the PSG, but instead write them in a buffer. You just preload a 256 bytes buffer with some sets of PSG values that you then dumbly send to the PSG later one at a time between each sector.
Advantage is that you have a constant time replay that can be able to replay complex sounds without taking more time.
256 bytes, 18 sectors, that's a maximum of 14 bytes per replay. That's cool it's more than enough for storing all PSG registers
Another interesting feature would be to be able to unpack data while loading. My lz77 unpacking routine is easy -I think- to adapt for such a thing, so it would be possible to unpack in realtime data coming from the 256 bytes read buffer.
Dbug, finally managed to find time to understand that a bit. what you say is cool except i'd have concerns regards how constant the tempo would really be between sectors. On the emulator it is exact but unsure how exact a sector read is.
Here is an interesting idea that kind of lends itself to a reliable constant tempo.
The process of loading each byte from the Disk Drive spares just a few cpu cycles on some of the more picky hardware.
So say we have 12 spare cycles..
The speed of the loading process cannot be relied upon enough to play samples during each byte load.
Is this statement true?
my idea is to load x from the high byte of the VIA Timer counter then load from memory indexed by x, then store the byte to VIA port A which can be set up as a virtual AY register like Volume register A..
During loading of a 256 or 512 byte sector, x will decrement at a fixed rate of 3.9Khz (1Mhz / 256) producing a 3.9Khz Sample.
After loading a sector the Sample address is adjusted by both the current value of x and the predicted value in t1ch next time x is loaded.
So long as the next sector load not starting with x loaded with a very low value this should work and produce a very tempered sample.
I guess adapting this to a chip replay would be difficult because of the unchangeable speed of timer1. :/
Here is an interesting idea that kind of lends itself to a reliable constant tempo.
The process of loading each byte from the Disk Drive spares just a few cpu cycles on some of the more picky hardware.
So say we have 12 spare cycles..
The speed of the loading process cannot be relied upon enough to play samples during each byte load.
Is this statement true?
my idea is to load x from the high byte of the VIA Timer counter then load from memory indexed by x, then store the byte to VIA port A which can be set up as a virtual AY register like Volume register A..
Code: Select all
LDX via_t1ch
LDA SAMPLE,x
STA via_portaAfter loading a sector the Sample address is adjusted by both the current value of x and the predicted value in t1ch next time x is loaded.
So long as the next sector load not starting with x loaded with a very low value this should work and produce a very tempered sample.
I guess adapting this to a chip replay would be difficult because of the unchangeable speed of timer1. :/