HostFS+TCPIP

discuss both original and modern hardware for the bbc micro/electron
dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

HostFS+TCPIP

Post by dominicbeesley » Fri Feb 22, 2019 2:29 pm

I'm not sure if everyone in the world needs another transfer method from PC to beeb but here's one I've got on the simmer.

I've hooked a WizNet 5300 module up to the 1MHz bus of my beeb and tweaked my 6809 port of JGH's HostHS to run over TCP/IP and tweaked Sweh's TubeHost perl script for the other end.

It's a bit buggy and thrown together still but as a proof of concept it works - there's a lot to do especially on the server end it tends to send a lot of single byte packets at the moment that need to be coalesced. I've added an extension to the HostFS for block mode transfers which seems to work well giving 100KB/s plus transfers which is nice!

If there's interest I'll post up more details...

Here's the current rat's nest
20190222_140047-s.jpg
And a video of it running some test mode2 screendump transfers https://youtu.be/iAKUF1bdECs


D

User avatar
jgharston
Posts: 4008
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: HostFS+TCPIP

Post by jgharston » Fri Feb 22, 2019 7:13 pm

Need a thumbups smiley...
Image

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
IanS
Posts: 1273
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

Re: HostFS+TCPIP

Post by IanS » Fri Feb 22, 2019 7:14 pm

Can't belive thsi doesn't have more responses yet. It looks amazing. How much of a TCP/IP stack have you had to implement on the beeb?

tom_seddon
Posts: 387
Joined: Tue Aug 30, 2005 12:42 am
Contact:

Re: HostFS+TCPIP

Post by tom_seddon » Fri Feb 22, 2019 8:07 pm

Excellent... the more PC<->BBC filing systems, the better, in my view! It's such a good way to do things.

Can't remember if I saw this particular device when looking for wifi/eithernet BBC<->PC options, but if I did, I definitely didn't notice it was 5V tolerant! What does this look like from the BBC end? I/O ports in page $fc?

--Tom
Last edited by tom_seddon on Fri Feb 22, 2019 8:08 pm, edited 1 time in total.

User avatar
paulv
Posts: 3854
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: HostFS+TCPIP

Post by paulv » Sat Feb 23, 2019 9:07 am

Very cool :D

Paul

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Sat Feb 23, 2019 10:05 am

Thanks all,

These chips/modules make it pretty easy. They contain a microcontroller and 128k RAM and implement a Berkley sockets interface so programming them is fairly easy. I tried a 5100 first but could not get the fast mode working reliably. The 5300 is a bit more tricky as it is aimed at 16bit machines and uses FIFOs that need bytes sending in pairs.

The chip is presented on the 1MHz bus as 3 16bit registers at FC28 ive used a 74LS138 a GAL a buffer and a hex inverter but that is probably overkill (trying to tame the 5100s misbehaviour). If I get time this week I'll look at reducing this to two 138s... The datasheets are a bit unclear..not the best translation from Korean but once I'd worked out the basics fairly straight forward.

I still sometimes get one incorrect byte in a screen transfer but I can't work out why. It is always the same byte but not at any special address. I'm starting to suspect that might be a dodgy byte in ram so need to write a memory test to write stuff to the internal buffer and check it back out.

Glad there's interest and ill keep at it.

My main interest was to get a faster transfer method for my blitter board but I'be discovered a timing bug which is stopping that working...ill try not to let that distract me too much but the theoretical speed would then be more like 800k/s. Useful when loading up big graphics or sound.

Another use would be to speed up TUBE transfers but would require a tweak to the tube timing. I shelved the Linux port to the Arm copro as it was taking far too long to boot. This might be a way to improve it?

User avatar
MartinB
Posts: 5287
Joined: Mon Mar 31, 2008 10:04 pm
Location: Obscurity
Contact:

Re: HostFS+TCPIP

Post by MartinB » Sat Feb 23, 2019 3:15 pm

Dominic wrote:The chip is presented on the 1MHz bus as 3 16bit registers at FC28....

I don't really understand what this device is but if it matters, that address clashes with my BeebSID allocation of $FC20-$FC3C :?:

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Sat Feb 23, 2019 4:21 pm

Its a network card. I picked that address more or less at random. I use SID so happy to shift. So what would people suggest a block of 8 bytes preferably good on all generations of machines

D

User avatar
MartinB
Posts: 5287
Joined: Mon Mar 31, 2008 10:04 pm
Location: Obscurity
Contact:

Re: HostFS+TCPIP

Post by MartinB » Sat Feb 23, 2019 4:41 pm

Ok, thanks Dominic 👍

It’s probably not something I’d use (over my head 😊) but thought I’d better mention the potential conflict.

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Sat Feb 23, 2019 5:16 pm

Thanks Martin,

Does anybody have any opinions on a good fred slot. &FC50 maybe. Its easy to change at the moment. I intend to use the extra two addresses to do done sort of eeprom to store local ip address and default hostfs name or ip


If there's enough interest we look at internet filestore or even bbs/telnet?

User avatar
jgharston
Posts: 4008
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: HostFS+TCPIP

Post by jgharston » Sat Feb 23, 2019 6:29 pm

I try to keep this list as up to date as possible to be usable as a reference.

For eight bytes you could think of:
&FC50-58
&FC58-5F
&FC78-7F (&FC7F clashes with Electron shadow RAM register)
&FC88-8F
&FC90-97 (listed as Electron Sound and Speech - I'm currently reverse engineering
&FC98-9F (an Electron Sound expansion card, so that will clarify what's here)
&FCA0-A7
&FCA8-AF
&FCC8-CF
&FCE8-EF

I'd advise avoiding &5x, &9x and &Ax to leave these available for devices that need a block of 16 addresses, so think about one of the blocks based at &FCx8, listed in italics.

Sorry, for some reason I read '3 addresses' as '8 addresses'
Last edited by jgharston on Sat Feb 23, 2019 6:30 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
jgharston
Posts: 4008
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: HostFS+TCPIP

Post by jgharston » Sat Feb 23, 2019 6:35 pm

I try to keep this list as up to date as possible to be usable as a reference.

For four bytes you could think of:
&FC74-77
&FC78-7B
&FC7C-7F (&FC7F clashes with Electron shadow RAM register)
&FC88-8B
&FC8C-8F
&FCC8-8B
&FCD4-D7
&FCE8-EB
&FCEC-EF

You might think of avoiding &xxx8/&xxxC blocks to leave those available to devices that need a block of eight, and consider the &xxx4 blocks.
Last edited by jgharston on Sat Feb 23, 2019 6:37 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
jgharston
Posts: 4008
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: HostFS+TCPIP

Post by jgharston » Sat Feb 23, 2019 6:39 pm

Argh!
The chip is presented on the 1MHz bus as 3 16-bit registers at FC28
So what would people suggest a block of 8 bytes preferably good on all generations of machines
Ok, go back to:
I try to keep this list as up to date as possible to be usable as a reference.

For eight bytes you could think of:
&FC50-58
&FC58-5F
&FC78-7F (&FC7F clashes with Electron shadow RAM register)
&FC88-8F
&FC90-97 (listed as Electron Sound and Speech - I'm currently reverse engineering
&FC98-9F (an Electron Sound expansion card, so that will clarify what's here)
&FCA0-A7
&FCA8-AF
&FCC8-CF
&FCE8-EF

I'd advise avoiding &5x, &9x and &Ax to leave these available for devices that need a block of 16 addresses, so think about one of the blocks based at &FCx8, listed in italics.

That does it, I'm going to put the kettle on! :D
Last edited by jgharston on Sat Feb 23, 2019 6:40 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Sat Feb 23, 2019 11:13 pm

Thanks jgh,

I'll go with fc88 then as that will just involve swapping two connections.

D

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Tue Oct 08, 2019 11:28 pm

I haven't forgotten this but I did put it to one side...well right in the middle of my desk but under a load of stuff.

I was making progress but was getting occassional glitches whereby there would be a double read from the card causing data to be skipped, the particularly seems to happen when reading bytes such as "FF" / "FE" where most of the bits are set. I tried all manner of decoupling and making better ground connections but to no avail. Then one day recently I needed to regression test some blitter changes and I noticed that the problem didn't happen if I touched the scope lead to the nRD input of the WIZ830 module. To cut a long story short I've found the "fix" is to add a 100-220pF capacitor to ground on nWR and nRD...this is not a "nice" fix but it works!

All these details aside the huge breadboard has been annoying me and so I designed a PCB. It came back and after a few false starts it now seems to work and seemingly flawlessly. There are a few problems though:
- I made an error in the board and forgot to ground some pins which needs a board bodge
- I forgot to change the address to FC88 so it's currently at FC28

I'm a bit annoyed with myself as these were silly mistakes...I've fixed the first with some blobs of solder but the second requires careful track bodges which is probably not a good idea. For now I'll finish the software off on this board and try and get a finished ROM and corrected board out soon(ish)...

D
Attachments
20191008_224338 (002).jpg

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Wed Oct 09, 2019 2:41 am

That looks really cool.

What changes to my host software did you have to make? I guess the socket filehandle, but you also mentioned a 'block mode'.

I'd be interested in seeing the diffs! Maybe we can merge it into the mainstream as another alternate flag ("-T <portno>" perhaps).
Rgds
Stephen

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Wed Oct 09, 2019 12:00 pm

Thanks sweh,

Code attached. I didn't change much really I just tweaked the code to try and clump larger transfers. I wouldn't bother merging this yet but it does work, I'd like to do more in trying to clump data into packets. The tubehost protocol is byte based but it should be possible to clump more into fixed/known sized packets. I know in theory it should be possible to interrupt with an escape at any point and halt a transfer but of course that slows stuff down at the BBC end of the pipe by requiring a check of each byte as it is processed. At the moment I've just changed the OSFILE transfer parts of the code to do a set of larger writes (IIRC).

Having said that it already works well enough on a local network but I suspect it would cause issues on a larger/slower network where latency would slow things down.

I'll try and get a look at this properly this evening as I can't really remember where I got to with the "packetizing" stuff I'd like to keep the protocol true to JGH's original intentions and allow the ROM/server code to be as similar as possible for the serial and block protocols.

D
Attachments
TubeHostTCP-stardot20191009.zip
(15.5 KiB) Downloaded 19 times

User avatar
Elminster
Posts: 4112
Joined: Wed Jun 20, 2012 9:09 am
Location: Essex, UK
Contact:

Re: HostFS+TCPIP

Post by Elminster » Wed Oct 09, 2019 12:46 pm

I don't need one as have a load of ways of transferring data, but I probably want one anyway. :D

Hmmm not sure I added this to hardware list..... I often add Dominic's but they do seem to stay in 'In Development' and in the meantime I add another 6 projects of yours :)

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Wed Oct 09, 2019 1:58 pm

Thanks Elminster please do add it. And, sorry, yes, I need to finish more projects :roll: ...the 1MHz BOB got released at least!

The blitter is still rumbling on but it is a _big_ project and needs a lot of testing and supporting software ... I've still not got it working on the master yet...

Hopefully this will be ready fairly soon and then I'll have a go at porting the hostfs code to also work with Sprow's LanManager card which I also have but don't have room to use at the moment.

I had plans for smashing the hostfs code out this week but now my daughter's off sick from school real life has to take precedence!

Of all my transfer/storage methods this is about the fastest and I've not fully optimised yet, ADFS to hard disc might be close I need to benchmark. I've never tried proper UPURSFS so I'm not sure what sort of speeds that can achieve.

Once I've got the software nailed on I'll have a go at adding the blitter/dma into the mix that should speed things up considerably but will need a change to the protocol so that memory transfers aren't interruptible and don't contain escapes then it should really fly! It might seem daft to chase speed like this but I still have my Linux on a CoPro project which is where this all started. It was shelved for want of a faster filing system! (about 5 years ago)

D

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Wed Oct 09, 2019 2:34 pm

dominicbeesley wrote:
Wed Oct 09, 2019 1:58 pm
Of all my transfer/storage methods this is about the fastest and I've not fully optimised yet, ADFS to hard disc might be close I need to benchmark. I've never tried proper UPURSFS so I'm not sure what sort of speeds that can achieve.
When Dave was doing some optimisations, I did some testing; basically "load a 16K file, save the file under a new name, load the new file, save it under another name" type loop 1000 times. At the end of the 1000th iteration I compared the first and last file and they were identical, so there was no data corruption after reading/writing around 16MByte of data:-)

Code: Select all

>RUN
Loading FILE.1: 12
Saving FILE.2: 18
Loading FILE.2: 526
Saving FILE.3: 795
Loading FILE.3: 1304
Saving FILE.4: 1573
Loading FILE.4: 2083
Saving FILE.5: 2353
Loading FILE.5: 2868
Saving FILE.6: 3138
Loading FILE.6: 3646
Saving FILE.7: 3919
Loading FILE.7: 4427
Saving FILE.8: 4698
Loading FILE.8: 5206
...
Loading FILE.998: 856526
Saving FILE.999: 856888
Loading FILE.999: 857496
Saving FILE.1000: 857865
Loading FILE.1000: 858476
Saving FILE.1001: 858845
Finished: 859423

Code: Select all

Loads:  999 in 3092.95 secs ==> 15.609 Mbytes at 42335.3 bps
Saves: 1000 in 5501.10 secs ==> 15.625 Mbytes at 23826.5 bps
At the same time I had a *SPOOL running, which meant a lot of small writes to a second channel, which would have slowed down things as well. I bet the speed would be faster without the SPOOL.

Code: Select all

TIME=0
FOR A=1 TO 1000
LET B=A+1
O$="FILE."+STR$(A)
N$="FILE."+STR$(B)
PRINT "Loading ";O$;": ";TIME
OSCLI "LOAD "+O$+" 3000"
PRINT "Saving ";N$;": ";TIME
OSCLI "SAVE "+N$+" 3000+4000"
NEXT
PRINT "Finished: ";TIME
Rgds
Stephen

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Wed Oct 09, 2019 4:12 pm

Thanks, that looks about right. So far IIRC I'm getting about 80KB/s doing repeated loads well about 4 mode2 screens a second I reckon that could be improved easily with a few protocol tweaks. With the dma/blitter card it should be possible to push this towards the theoretical maximum of 0.66MB/s for transfers to main RAM, 1MB/s to chip RAM and then look at options for speeding up TUBE transfers.

For now the first thing I need to do (I am starting this minute) is to do all this in 6502 code, the testing so far has mainly been on my 6809 port of UPURSFS/HOSTFS not on the mainline.

So before I start where's the current *best* sources for HostFS/UPURSFS?

D

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Wed Oct 09, 2019 5:00 pm

I'll answer my own question: I've re-found your GitHub repository.

I've sent you a pull request (at least I think I have - I hate Git) which contains my base-line 6502 code. There's not many changes but it does contain stuff for Phil's (myelin) 1MHz bus serial/sdcard which is another serial port - what I mostly use.

I'll start folding the TCP stuff in now...

D

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Thu Oct 10, 2019 12:45 am

dominicbeesley wrote:
Wed Oct 09, 2019 5:00 pm
I've sent you a pull request (at least I think I have - I hate Git) which contains my base-line 6502 code. There's not many changes but it does contain stuff for Phil's (myelin) 1MHz bus serial/sdcard which is another serial port - what I mostly use.
Thanks. I made some small cleanups and updated the README. Hopefully I didn't break anything while merging :-)
Rgds
Stephen

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Thu Oct 10, 2019 1:26 am

Thanks sweh,

I'll try and get a look and some testing soon. I got some time to play tonight and I've been going back over my 6809 code and looking at the TubeHost code. I'm not sure how to merge back the other changes - I notice there's some stuff from Dave that I don't have in my fork. I'll have a play when I get a chance and do some testing.

I've made some tweaks to TubeHost to better clump together stuff into packets which is working well - basically send_byte just copies to a buffer and there's a send_flush sub that needs to be called to flush the buffer. This has reduced the number of 1 byte packets a lot.

I also tweaked the code in the 6809 ROM and I'm getting ~130KB/s i.e. about 6 and a half mode 2 screens per second. [It's probably slightly faster than this, the test program is in BASIC and so is eating into the timings]

Now I've got my head back into it I'll make a start on the 6502 port in earnest when I next get some dev time.

D

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Thu Oct 10, 2019 1:47 am

I definitely might want to buy some of these boards when you've got everything working!

This'd be a great way of transferring files between machines; Beeb1 can write to a *DIN'd disk, Beeb2 will see the new files immediately!
Rgds
Stephen

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Thu Oct 10, 2019 10:53 am

You will be first on the list. I certainly find this very useful already using serial cards!

I've been thinking a bit more about this.

On the next board I'll include a small eeprom for storing:
- mac address
- favourite sites
- site session id - this could be used so a site can remember the state i.e. what disks are inserted?

I need to think about security as well, there needs to be some sort optional of user/password mechanism if these sites are to be hosted online!

So far I've only been interested in the file transfer possibilities but I need to have a think about BBS/telnet style operations too...maybe later!

Once that is done we might look at a simple windows/linux/etc program to allow UPURS/Serial/Myelin connected beebs to use a local pc as a tunnel through to the internet?

D

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Thu Oct 10, 2019 2:49 pm

dominicbeesley wrote:
Thu Oct 10, 2019 10:53 am
I need to think about security as well, there needs to be some sort optional of user/password mechanism if these sites are to be hosted online!

So far I've only been interested in the file transfer possibilities but I need to have a think about BBS/telnet style operations too...maybe later!

Once that is done we might look at a simple windows/linux/etc program to allow UPURS/Serial/Myelin connected beebs to use a local pc as a tunnel through to the internet?

D
I was thinking a bit about this on the train this morning, for other reasons.

I started with thinking of adding another level of organisation to the file system. Currently if I do a *DCAT then I get hundreds of entries and my test disks are mixed with the games disks and so on. So maybe have a *CHDIR type command that would let the base to change, so I could have GAMES/ and TEST/ areas. This should be pretty simple to add; I might do it this evening.

Then I thought, hmm, we could allow different users to all connect with their own "home". Now I don't want to run as root, so segregation would be in the perl software. Perhaps have a shared COMMON area that everyone can see.

Extending "*IAM" to allow for a password to be entered as an authenticator would be a simple method of providing access control.

It's clear how this would extend to "internet access". The only real downside is that the password would probably be in clear text over the 'net unless we have a very simple encryption protocol that will fit into a few bytes :-) Unless the ethernet board can do native TLS so it's all offloaded from the Beeb!

This should nicely be at higher levels of the software stack, so the low-level communications should be mostly hidden. Probably all the ROM would need is a "*HCONNECT" type command to specify the host to connect to

Code: Select all

*HCONNECT my.beeb.warez
*IAM GROOT
*CHDIR COMMON/THE-GOOD-STUFF
*DIN 0 0
Would need to work out some form of permissions model; "Harry lets Fred see TESTWORK1" (which may be the hardest part)

Heheheh, if you come up with a version of this board that can work WiFi then people at expos could use their phone as a WiFi hotspot and access the internet hosted repos without wires :-)
Rgds
Stephen

dominicbeesley
Posts: 1060
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: HostFS+TCPIP

Post by dominicbeesley » Thu Oct 10, 2019 4:14 pm

I've yet to think it through thoroughly but this should all be possible with the flexibility of the HostFS idea. The permissions would be down to the "server" - i.e. the perl script at the moment but of course other servers could do what they liked. I've got to look at the perl script in terms of perfomance the way I made it starts up new threads is a bit lazy I just found a simple example on google and used it without thought!

Where I'm thinking is that the client should "remember" connection string (including optionally user / password) and the server could/should optionally remember where you were logged in to and what directories / drives / etc were available - this would require a unique key (mac address?) for each client.

I think *CHDIR should be *DCD or *DCHDIR to disambiguate with other directory changing but it is something I keep meaning to graft in. I "only" have 30 or so disks but it is still sometimes difficult to find them.

D

tom_seddon
Posts: 387
Joined: Tue Aug 30, 2005 12:42 am
Contact:

Re: HostFS+TCPIP

Post by tom_seddon » Thu Oct 10, 2019 6:46 pm

Sign me up for a board too! I'd like to add support for this to BeebLink. Not sure what the Beeb-side UI will look like yet, but I'll be having a think.

--Tom

User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: HostFS+TCPIP

Post by sweh » Fri Oct 11, 2019 2:04 am

dominicbeesley wrote:
Thu Oct 10, 2019 4:14 pm
I think *CHDIR should be *DCD or *DCHDIR to disambiguate with other directory changing but it is something I keep meaning to graft in. I "only" have 30 or so disks but it is still sometimes difficult to find them.
I decided on *H based commands since they impact the Host, and so match *HSTATUS.

You can check the "folders" branch of the repo: https://github.com/sweharris/TubeHost/tree/folders

Basically:

Code: Select all

Folders
=======
In v0.13 a new concept was added, called Folders.  These are directories
in the tree that begin with the underscore (_) character.  These don't
show as disks for *DCAT/*DIN purposes, but allow us to organise disks
in an easier manner.  So, for example, you could put games disks in the
_GAMES folder, test work in the _TEST folder.

e.g.
    % find Beeb_Disks -type d | sort
    Beeb_Disks
    Beeb_Disks/_GAMES
    Beeb_Disks/_GAMES/0.Mr_Ee
    Beeb_Disks/_GAMES/1.test1
    Beeb_Disks/_GAMES/10.test10
    Beeb_Disks/_GAMES/TAPES
    Beeb_Disks/_JUNK
    Beeb_Disks/_JUNK/_FOO
    Beeb_Disks/_JUNK/_FOO/_BAR
    Beeb_Disks/_TEST
    Beeb_Disks/_TEST/Folders
    Beeb_Disks/_TEST/Stuff

Folders are displayed with *HFOLDERS, changed into with *HCF and can
be created with *HMKF.  When a disk is loaded from a folder then the
path is shown in the *HSTATUS command

    >*HFOLDERS
    Folders present:
      ..
      _GAMES
      _JUNK
      _TEST
    >*HCF _GAMES
    Current folder is: _GAMES
    >*DCAT
    Disks available:
         0: 0.Mr_Ee
         1: 1.test1
        10: 10.test10
        11: TAPES
    >*DIN 0 0
    >*HCF ..
    Current folder is: 
    >*HCF _JUNK
    Current folder is: _JUNK
    >*HCF _FOO
    Current folder is: _JUNK/_FOO
    >*HCF ^
    Current folder is: 
    >*HCF _TEST
    Current folder is: _TEST
    >*DIN 1 Folders
    >*HSTATUS D
    Disk 0: _GAMES/0.Mr_Ee
    Disk 1: _TEST/Folders
    Disk 2: 
    Disk 3: 
    Disk 4: 
    Disk 5: 
    Disk 6: 
    Disk 7: 
    Disk 8: 
    Disk 9: 
    
    Current drive: 0
    Current directory: $ (:0.$)
    Current library: :0.$
    Current folder: _TEST

Code: Select all

  *HCF
     Host Change Folder
     Changes the folder we look in for disks.  Folder names must start
     with an underscore (_).  A special name of ".." means go up a level,
     and "^" means go to the top of the tree

  *HFOLDERS
     Show sub-folders under the current folder.  Folders can be nested
     as deeply as the filename allows.

  *HMKF
     Host Make Folder
     Creates a new subfolder in the current folder.  Folder names must
     start with an underscore (_)
Rgds
Stephen

Post Reply

Return to “8-bit acorn hardware”