Open tom-seddon opened 2 years ago
Hmm... PC volumes don't support drives! How would this work in that case?
Perhaps just note the full *LIB
setting when set, and retain it when changing volume. Do *LIB :1.$
with volume TOOLS
selected, and when you change volume the library dir is still ::TOOLS:1.$
.
Or maybe track how specific the *LIB
setting was, and reset it (or not) based on that. Do a *LIB :1.$
, and it gets reset to :0.$
when you change volume. Do *LIB ::TOOLS:1.$
, and it sticks.
Default lib setting possibly one for the command line/json config file.
Maybe introduce some analogue of the Unix/Windows PATH
functionality.
Even though it's completely useless (due to non-support for load/exec addresses), you should be able to select a PC volume path as your lib folder.
Noticed there's no DFS track 0 re-seek with FileSwitch on Master 128, so that's good. But the disk parsing stuff is annoying to code, and annoying to debug, and super slow in BASIC, and has to be tediously compactly written so it can buffer as much as possible if it's to work even remotely reasonably on a B (due to that track 0 seek thing).
So: keep the server-side *READ
/*WRITE
flow, since it's written and debugged, and just redo the client side bit in BBC BASIC using OSWORD $99. Needs different requests to initiate (no *
commands any more), but everything's otherwise there. Can just point it at something like TOP+&400
to HIMEM
and off it goes.
Can change the disk image flow API if necessary - e.g., messages should at least be CR-terminated so they're convenient to print with the $
operator. With *READ
and *WRITE
gone, there's no way for old ROMs to access this stuff.
With enable_selfupdate=false
-rw-r--r-- 1 tom staff 6815 20 May 21:06 .build/beeblink_avr_fe60.rom
-rw-r--r-- 1 tom staff 9619 20 May 21:06 .build/beeblink_tube_serial.rom
-rw-r--r-- 1 tom staff 8034 20 May 21:06 .build/beeblink_upurs_fe60.rom```
transfer_file_data_driver_routine
gets expanded a lot - it could easily just be a routine that makes some indirect calls. This might affect the benchmarks - though would it really make a detectable difference in use?
3fd1ffcc65fca0910eec95412edbcaa3bcd73f0e tweaks things so that every version is <= 8 KB.
f793ce44b6b1c9133b99ae0114998acfc1e8fc1b ensures there's no page-crossing branches in the key Tube Serial routines.
Would be nice to get the BeebLink ROM down to 8 KB or less. Main rationale for this: optionally combine it with a slightly feature-reduced Beeb wi-fi driver ROM (see https://stardot.org.uk/forums/viewtopic.php?f=3&t=20468), so that the proposed wi-fi BeebLink can occupy a single 16 KB bank. But, this would also make it easier to combine it with some other 8 KB ROM.
To save space, replace a few inbuilt mod cons with external programs. Current hit list:
*SPEEDTEST
Got WIP alternative in BASIC - just does exactly what *SPEEDTEST does, using OSWORD &99*SELFUPDATE
Got WIP alternative in 6502 - with some extra checks and a slightly nicer UI*READ
,*WRITE
A lot of the server side logic could be done on the Beeb, probably just in BASIC. This could also form the basis of a FS-agnostic tool that uses OSWORD &99 when available (avoid the DFS track 0 seek behaviour) but can also operate using OSGBPB*VOLBROWSER
Probably not much point doing this in BASIC... there's not much to it, and the 6502 code is basically already writtenWhat's annoying about this though is that the commands become a bit unwieldy. Before:
*VOLBROWSER
. After:*::BEEBLINK.0.$.VOLBROWSER
.What about some permanently accessible tools drives or something? So you could have drive
@
, or whatever, always the same regardless of volume. Then all you need is*:@.VOLBROWSER
- and his would also work naturally with*LIB
, though maybe that's not actually much use, as the lib directory gets reset quite often.Or maybe it just won't be a problem.