hoglet wrote:Am I right in thinking that the critical interface to the storage system is OSWORD A=&7F, and that each call is returning exactly one track?
Do you have a feel for what sustained performance is required? i.e. how long is the OSWORD call permitted to take before things will go wrong. Even a ballpark figure would be useful.
Hi Dave, just some background to this as I've been mulling over the issue too (and just spotted this conversation). Both my version of Bad Apple and Kieran's use OSWORD &7F to load compressed data into a circular buffer, and on DFS using 5.25" discs, the next track (10x256 bytes) of data is loaded as soon as enough space is available. Interrupt driven code (VSync event) is used to decode and display the data on screen, then update available space in buffer.
This works fine under DFS, but fails on the mmbeeb MMC and SmartSPI SD implementations because the VSync event isn't serviced correctly while OSWORD &7F is in progress. I can't comment on MMFS as I've not yet had the chance to try (although just downloaded - so will do this weekend).
The solution we've used when running from MMC and SmartSPI was to load individual sectors each time 256 bytes is free, rather than whole track when 10x256 bytes is free. This approach doesn't work on real DFS with 5.25" discs because the load time for 10 individually loaded sectors is longer than loading 1 full track, due to a full disc rotation required for each sector when loaded individually (leads to buffer under-run) - but on SD there is no such delay, so loading sectors worked fine, but it sounds like Kieran's experience with MMFS suggests a difference here.
The SD interface is clearly much faster than DFS, so even loading a full track should be possible, but there must be something in these implementations causing a clash with the interrupt driven code.
I need to look back at my notes, but I had narrowed it down to interrupts being disabled during OSWORD &7F on MMC and SmartSPI. DFS also disables interrupts during OSWORD &7F, but re-enables (CLI/SEI) between sectors, which is enough to keep the VSync event serviced for the video playback.