I've been having a look at the Cumulus sources (not too deeply, anyway). Just some random ideas:
The main loop does:
Code: Select all
/* See if a command request has arrived */
if (PORTBbits.RB0 == 0)
/* So handle it */
/* Do UI Stuff */
The ui_run() simply takes care of user input through the Cumulus buttons and it is not done until any pending command has been handled. Certainly the PORTBbits.RB0 could be assigned to an interrupt, so an ISR may serve commands whenever the Oric asks for them to avoid delays, but I think this is not creating problems as you don't usually do anything while the disk is being read/written.
The apparent delays may come from the fact that the commands do update the UI, log events, etc. This seems that could be a lengthy process and could be the reason why read/write operations have quite variable timings (if they do, as I think, anybody experienced this?). Maybe the efforts could concentrate on solving this then (if you think this is an issue, that is). One possibility would be to defer screen updates (such as sector/track number display). If the command handling is set as interrupt driven, the above loop could be altered with something such as:
Code: Select all
if (UI needs updating)
Update UI with sector/track number, log,...
/* Do UI Stuff : User inputs*/
And the command handling routines may just drop the values to display in global variables, for instance, and signal that UI needs updating.
This has a clear drawback (or two): Type III commands which read/write full tracks and addresses (don't know what this is) will not show these values onscreen. We could leave the blinking of the small square indicating activity and maybe other visuals inside the command handling if they don't take too much time.
Or we can leave things as they are now. In fact it is working...
Another thing is about communicating from the Oric to the Cumulus. The FD179x has 11 different commands. It is possible to use any invalid command to broaden the possibilities. For instance any command whose bits are 11111xxx is invalid. It is possible, therefor, to implement extended behaviour in the Cumulus by creating new commands. Whenever a new command is detected, the track and/or sector registers may be used to indicate extra information.
This way it could be possible to implement commands on the Oric side which could ask the Cumulus to send the directory information, select a disk image, mount it, reset, etc. I am sure you can imagine the possibilities... even a whole new OS.
But yeah, it would only be compatibe with Cumulus and I am not sure about the amount of memory that it would require on the PIC.
I still think this is an interesting project, but it is complex. In fact we have not found a solution to store tape based games on disk (at least not all). A program which loads a memory dump created with an emulator and stored in a disk file into the Oric would be much more practical. And it could be done with the Cumulus as it is and would be compatible with Microdisc too.
As I said, just some random thoughts...