Hi
@oktology , it already supports subdirectories - but they are fully conforming CP/M subdirectories at present - ie, I use the offset index in the DPB and they show up as a file in the local directory and are preallocated in terms of size and are mounted as a drive via the BIOS system as their own disk, even though they are part of an existing disk- It will support non-CP/M subdirectories ( ie, No allocation vector ) but I am working to make it more compatible with CP/M presently before I start diverting from there. The failure point in supporting CP/M subdirectories is the CP/M file system that requires allocation vectors and extents to locate the files in physical space as well as DPH, DPB etc.
Because I use a memory-as-disk architecture, all memory can be accessed as disk space, so memory management is fairly easy and external drives can be treated as a different kind of memory and all get mapped into physical space. So hard drives will probably start at $100000 just above the 1mb mark, and it supports up to 256Mb of total space.
Because of the driver structure within the hardware architecture, there is no problem with code size, and I'll probably end up making a single drive that can traverse directory structures over a network subsystem, since directories can be mostly omitted on smaller systems, and because native CP/M applications don't support directories either, I'll need to come up with a clever way to make sure any logged directory looks like a normal CP/M directory -
I still have some thinking to do about what an effective strategy to implement directories like that though, and will end up having to extend the FDOS to support it, so I'll almost certainly end up supporting it via other calls in the zero page rather than the one at 0005 since I don't want to contaminate the defacto CP/M calls.
That way it will happen transparently to the OS, in case someone drops in a real CP/M over the top -
What I will probably need is a way to have a "pop up" type window that allows me to mount a directory and traverse a directory structure and then present a flat single-directory file view of that directory to the OS - then it will work with other apps, eg, Wordstar, etc. Also, I'm planning on mixing graphics and text on the screen in the long run to allow graphics windows to be superimposed on the terminal background - and a mouse as well.
But the mechanics of that are still a way off and I haven't thought too much about it presently while I'm still working on fixing compatability issues. And I'm planning on building the hardware over the Christmas break if I get time.
As for the basic thing, well, BASIC is really just a syntax. The underlying language is what does the work, and to be honest, I'd love it if I could write something like, "Open "10.10.10.10:8080" for random as #2" to open TCP streams with it rather than having to use the converted C libraries... But the language itself is not really any less powerful than any other third generation language. It's just that it became the pariah from the 80s, because people liked to bag it, and very few people stayed with it, yet Freebasic is a very advanced language. It abstracts far more than is apparent and is approaching 4th generation, yet still has the comfortable syntax and feel that BASIC users know and love. It even accepts good-old QBASIC (MS_BASIC) format code if you like, though does ask you to let it know you're using a deprecated syntax. And it's not that hard to translate it up to the newer syntax and runs on all major platforms.
You can write Windows apps in it, and I've started using it's graphics routines to simulate a graphics display, and it was close enough that I can get an idea what the real display should be like - as well as letting me write code to support it before the hardware is finished. I write all my Linux code in basic too, and it performs almost as well as C and far better than any other linux based language I've tried.
David
github.com
