beebem-windows
beebem-windows copied to clipboard
stardot
Emulator filing system trap opcodes
This pull request supersedes #14 by fixing the line endings and restoring changes on master that were overwritten.
I've also moved the documentation changes to the update-documentation branch (see #11).
@jgharston Please take a look. This is missing some changes to the resource file beebem.rc to add menu items for the emulator trap commands which weren't part of your pull request (ID_EMTACN, ID_EMTWSS, and ID_EMTBAS).
On 15-04-2017 15:14, Chris Needham wrote:
@jgharston [1] Please take a look. This is missing some changes to the resource file beebem.rc to add menu items for the emulator trap commands which weren't part of your pull request (ID_EMTACN, ID_EMTWSS, and ID_EMTBAS).
Sorry, I'm catching up on emails, the snap general election announcment has thrown all my timetabling to pot.
-- J.G.Harston - [email protected] - mdfs.net/jgh
I've put a version of beebem.rc relative to this pull request here: https://github.com/mungre/beebem-windows/commits/emulator_traps
I'll get write access here and then add it here.
@mungre I've just granted you write access. If you add the .rc file changes to this branch I can test and merge to master.
I'm not sure how to use this feature, any suggestions? It might be helpful to add some info to the HTML documentation.
Load the VDFS05 sideways rom, enable "WFS/VDFS traps", run *VDFS and then *. You get a list of files in the current directory on the PC! And you can load and save them. It's very impressive. "*DIR \" takes you to the root. "*DIR :D" changes drive. Though it's easy to forget you're no longer in a sandbox. I managed to overwrite one of my BASIC files with garbage.
I don't know what the other two options on the menu do.
Some related discussion of a similar feature in B-Em: https://github.com/stardot/b-em/issues/24
I found a bug: *DELETE succeeds but still raises the error "Bad command".
There are some points about security here: http://stardot.org.uk/forums/viewtopic.php?t=11654 This implementation does write .INF files.
jgh has documented the opcodes at the bottom of this: http://mdfs.net/Docs/Comp/6502/OpList
A couple of thoughts: The B-Em issue discusses a different approach. I think both emulators should be consistent, so that software works as expected in both when this feature is enabled. Also, I tend to agree with comments about sandboxing in the stardot thread.
You can access host files using VDFS in a consistent manner on both emulators. Providing a consistent low-level interface would only encourage people to code to it. That said, jgh has implemented an existing trap mechanism so presumably there is already some software somewhere that uses it. But possibly only the equivalent of VDFS in the original emulators.
Anyway, I don't feel strongly about consistency in the low-level interface.
The sandboxing is a concern. I am reminded of this and more seriously this.
Some random thoughts: at the moment VDFS just uses the process current directory so it changes directory every time you access one of the file dialogs. This is a pain. It needs at least a VDFS root directory and a VDFS current directory. The UI could be drag-and-drop (as suggested in the original post) or a directory selection dialog. Should it default to a new folder User\Documents\BeebEm\VDFS? Should a new root be saved automatically? I think not. Should it be saved by "Save Preferences"? I think it should. What about if "Autosave All Prefs" is selected? Probably. A command-line option to set the root would be enormously useful for development. This could also enable the traps. Otherwise people will get bored of setting them manually and leave them enabled.
A user-configurable root directory sounds like the right approach. I'm happy to work on it, time allowing.
@mungre I could also take a look at the *DELETE bug, unless you're already working on a fix?
@jgharston Would you be willing to write some HTML documentation?
@chrisn I've been meaning to look at this but other stuff keeps happening. Anyway, I've pushed a fix for the *DELETE bug.
Chris Needham wrote:
In Src/host.cpp [1]:
- fclose(handles[idx]);
- handles[idx]=nullptr; (snip) Note sure that code running in the emualor should be able to do this.
Code running in the emulator has opened the files, code running in the emulator has every right to be able to close the files. And if it doesn't, eventually the emulated Beeb will run out of file handles.
-- J.G.Harston - [email protected] - mdfs.net/jgh
My comment was in reference specifically to minimising the application window: ShowWindow(GETHWND, SW_MINIMIZE);
Chris Needham wrote:
My comment was in reference specifically to minimising the application window: ShowWindow(GETHWND, SW_MINIMIZE);
Ah, sorry.
What else should *QUIT (which calls OS_QUIT) do? It's what OS_QUIT on the WarmSilence 6502Em emulator on RISC OS does.
-- J.G.Harston - [email protected] - mdfs.net/jgh
A bit late to the party here but just picking up on Chris's link to a feature request on B-Em above (https://github.com/stardot/b-em/issues/24).
On the question of the exact mechanism by which a trap is made from the emulated BBC to the emulator, or indeed standardisation of "opcodes" for those traps, I also agree with the point already raised that this is not an API that user programs should be written to. In an implementation of something like VDFS there are cases where at least some of the code for a particular operation could be written in 6502 assembler and put in the service ROM or written in C/C++ and run on the host, i.e. the exact function of the traps may not be to provide some function that is useful to user programs directly but to compliment code in the service ROM.
For filing operations the API user programs should work to is the OS API within the emulated BBC micro, i.e. OSFILE, OSFIND, OSARGS, OSBGET, OSBPUT, OSGBPB etc.
In the event the trap mechanism is extended to cover non-filing operations that may be common to multiple emulators it would be better to standardise either OS commands (.e.g. *QUIT etc) or OSWORD calls.
