Discussion:
ProDOS 2.5 discussion
Add Reply
John Brooks
2018-01-27 18:42:31 UTC
Reply
Permalink
Raw Message
I've been working on a number of improvements to ProDOS. I'll list them here to give a heads-up to other developers in the community and to foster discussion.

Oliver Schmidt has created a new Github for ProDOS 8 development (thanks Oliver!). My new ProDOS drivers and other open-source-able code will go up there:

https://github.com/orgs/ProDOS-8


ProDOS 2.5 improvements under test now:

1) Lowercase name support for vol, dir, & files, coded using the ProDOS16 & GS/OS format:
16 lowercase bits stored in the VERSION, MIN_VERSION fields of dir & file entries

2) New driver for the no-slot clock

3) /RAM driver is replaced with a /RAM (aux 64k) and /RAM3 (Ramworks) driver

4) xHD 230kbps serial-port drive GS client & cross-platform server

5) Bitsy Bye includes the Bitsy Boot features 'Boot slot #' and 'Exit to GS/OS'

6) The number of user IRQ handlers reduced from 4x to 2x


Likely future improvements (minor compatibility impact)

7) Extended date & time. Year extended to 10 bits, 1900-2923. Time extended to milliseconds via a 'seconds' word (6-bit seconds, 10-bit ms)

8) Extended MLI calls to read directories, launch files, and read/write blocks on large volumes


Optional future improvements (minor compatibility impact)

9) Simple memory API to alloc, free, and copy memory between GS or Ramworks extended memory banks and app main & aux banks

10) Extend 4-bit unit DSSS0000 (7x slots, 2x drives) to 8-bit DSSSsddd (14x slots, 16x drives)

11) Dynamic code loading & relocation for drivers, etc.


Possible future improvements (larger compatibility impact)

12) ProDOS can load into a high GS or Ramworks bank, so main 64k mem use drops to just $BF page and LC bank 1 (4.25KB). Main $D000(bank2)-$FFFF is freed up for app use

13) Large volume support. Max volume size of 2048 GB

14) Extended file support:
A) 10 bit year with 250ms time precision
B) Max file size extended from 16MB to 4GB
C) File name length extended to 30 characters


Thoughts, requests, concerns?

-JB
@JBrooksBSI
Antoine Vignau
2018-01-27 20:00:37 UTC
Reply
Permalink
Raw Message
Great ideas, as usual, John.

My only concern is a sync between GS/OS and P8 for compatibility...

av
MG
2018-01-27 20:08:17 UTC
Reply
Permalink
Raw Message
Post by John Brooks
I've been working on a number of improvements to ProDOS. I'll list them here to give a heads-up to other developers in the community and to foster discussion.
https://github.com/orgs/ProDOS-8
3) /RAM driver is replaced with a /RAM (aux 64k) and /RAM3 (Ramworks) driver
Will there be a relatively easy way to disconnect and reconnect /RAM3 and specifying its maximum size?

I think that this kind of calls for a way of enabling/disabling certain features, either through the Aux Type of the ProDOS file, or maybe configuration data embedded at a fixed location of the ProDOS file (perhaps immediately after the three entry points)
Post by John Brooks
6) The number of user IRQ handlers reduced from 4x to 2x
What are the particulars for this change? Not that I've ever run into using more than two, but being an AppleTalk user I always have one handler slot in use, and using a clock card or music card interrupt uses another.
Post by John Brooks
Likely future improvements (minor compatibility impact)
10) Extend 4-bit unit DSSS0000 (7x slots, 2x drives) to 8-bit DSSSsddd (14x slots, 16x drives)
That would be handy, but most existing software definitely won't be expecting that, but an obvious workaround is that software that can't be fixed will only know about what falls under the existing convention.

I assume that the extra 7 slots are for support of some sort of slot arbitration on the IIgs and perhaps for slot 3 of the //e? Plus there's that Mountain Hardware expansion chassis...
Post by John Brooks
11) Dynamic code loading & relocation for drivers, etc.
I think this is probably going to be a requirement for some of these other features, as ProDOS is going to get much bigger.

Though interim support for features by loading into RamWorks and IIgs memory puts this off for a while.
Post by John Brooks
Possible future improvements (larger compatibility impact)
12) ProDOS can load into a high GS or Ramworks bank, so main 64k mem use drops to just $BF page and LC bank 1 (4.25KB). Main $D000(bank2)-$FFFF is freed up for app use
I'm working on an EhBASIC port that would substantially benefit from this. My current plans are for a 128K version that locates itself into the Aux LC.
Post by John Brooks
13) Large volume support. Max volume size of 2048 GB
A) 10 bit year with 250ms time precision
B) Max file size extended from 16MB to 4GB
C) File name length extended to 30 characters
As you and I have previously discussed, that will be quite the feat(ure). If we all can pull that off and maintain a fair bit of compatibility with existing applications, that would be amazing.

MG
Steve Nickolas
2018-01-27 20:26:35 UTC
Reply
Permalink
Raw Message
Post by MG
I'm working on an EhBASIC port that would substantially benefit from
this. My current plans are for a 128K version that locates itself into
the Aux LC.
No doubt it would be better than my dirty hack from years ago. ;)

-uso.
MG
2018-01-28 00:47:45 UTC
Reply
Permalink
Raw Message
Post by Steve Nickolas
Post by MG
I'm working on an EhBASIC port that would substantially benefit from
this. My current plans are for a 128K version that locates itself into
the Aux LC.
No doubt it would be better than my dirty hack from years ago. ;)
-uso.
I won't claim to be dirty-hack-free. :-)

The 64K version is coming along.

http://apple2.guidero.us/doku.php?id=projects:ehbasic

MG
John Brooks
2018-01-28 07:10:56 UTC
Reply
Permalink
Raw Message
.
Post by b***@gmail.com
Post by John Brooks
16 lowercase bits stored in the VERSION, MIN_VERSION fields of dir & file entries
Good idea, but will such a disk be readable in ProDOS < 2.5? How would legacy compatibility be maintained, if any?
Yes, I'm using the same approach that Apple used with ProDOS16 & GS/OS which means that all volume names, directory names, and file names are stored on-disk as uppercase only. There is a separate 16-bit array which says which characters should be lowercase.

ProDOS versions 1.8 & later will read the names as uppercase (knowing nothing about the extra 16-bit array), and they will write $0000 to the bit array when a file is created or renamed because they write a $00,$00 to the version fields which is where the lowercase bit array is stored.

ProDOS before 1.8 (and SOS) may not like the non-zero version fields. See 1989 Apple tech note:
http://www.1000bit.it/support/manuali/apple/technotes/gsos/tn.gsos.08.html
Post by b***@gmail.com
Post by John Brooks
5) Bitsy Bye includes the Bitsy Boot features 'Boot slot #' and 'Exit to GS/OS'
Perhaps these GS-specific changes could go into a seperate fork / version for the 65816... Otherwise, the only worry is that they will increase the size of the PRODOS.SYS file for non-GS users. Could perhaps have a "delete" feature like ProDOS 2.4.2small?
Luckily most of that 'Exit to GS/OS' code is inside GS/OS itself in high memory banks. All Bitsy Bye is doing is looking for the Delete key and doing an RTS to ProDOS which then does a 24-bit JMP to GS/OS, so not much code size there.

But yes, as improvements are made to ProDOS there is a very real size bloat of trying to bundle in every driver & code path for all Apple II platforms. The medium-term plan is to allow a config tool to add or remove drivers & subsystems so that we can trim the size down to just the useful bits for a specific config.
Post by b***@gmail.com
Post by John Brooks
7) Extended date & time. Year extended to 10 bits, 1900-2923. Time extended to milliseconds via a 'seconds' word (6-bit seconds, 10-bit ms)
Compatibility in < v 2.5?
Copy the text below and reformat using a fixed-space font.

Standard format:

49041 ($BF91) 49040 ($BF90)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DATE: | year | month | day |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

49043 ($BF93) 49042 ($BF92)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
TIME: |0 0 0| hour | |0 0| minute |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+


Extended format:

49039 ($BF8F) 49038 ($BF8E)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
xTIME:| xSeconds | xMilliseconds |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

49041 ($BF91) 49040 ($BF90)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DATE: | year | month | day |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

49043 ($BF93) 49042 ($BF92)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
TIME: |xYear| hour | |0 0| minute |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

The 3 bits above the hour hold the extra 3 year bits. That will cause the hour to print badly on apps which assume the top 3 bits are zero.

The extended directory format adds a seconds+1/4sec byte ($BF8F) to the Create & Modify timestamps, increasing them from 4 bytes to 5 bytes. The low milliseconds byte ($BF8E) is only used for runtime Apps and is not part of the timestamp (in the current design).
Post by b***@gmail.com
Post by John Brooks
8) Extended MLI calls to read directories, launch files, and read/write blocks on large volumes
Best idea yet. this, and HD-support for > 32MB are highest of all from both a functionality point, and usability point. This one change makes ProDOS "future-proof" in the sense that even now a 2048 GB drive is quite large...
Yes, that is my thought/hope. If we change apps to use a new MLI call to read directories, and ProDOS then returns both standard-format entries and extended-format entries in the same 'extended' data structure, then we just have to patch Disk util apps & whatnot once and they will work for both existing standard-format drives and large extended-format drives.
Post by b***@gmail.com
Only concern is how large PRODOS.SYS might become, for loading on 5.25" drives. How about making a "ProDOS Lite" with as small a filesize as possible, with greatly reduced, but compatilbe to ProDOS <= ProDOS 1.x? Perhaps it can get down to 10 to 12k?
Yes, we will definitely need more than one PRODOS config to meet the needs of Apple ][ 5.25 vs power //e or GS users with HD & lots of cards (ie drivers).

I suspect a slimmed-down read-only ProDOS with minimal drivers (ie 5.25, no /RAM, IRQ, clock) could be 4K-8K.
Post by b***@gmail.com
Will there be a relatively easy way to disconnect and reconnect /RAM3 and specifying its maximum size?
What use-case(s) do you have in mind for disconnecting and reconnecting /RAM3?

I am leaning toward having one Ramworks bank for ProDOS with the other 'extra' banks assigned to /RAM3 by default. A new MLI call would allow alloc/free and copy between GS/Ramworks extended banks and main/aux memory.

That would allow drivers and apps to share the extra memory without having to reboot or use a static 'reserved bank' config.
Post by b***@gmail.com
I think that this kind of calls for a way of enabling/disabling certain features, either through the Aux Type of the ProDOS file, or maybe configuration data embedded at a fixed location of the ProDOS file (perhaps immediately after the three entry points)
Yes, there are a number of ProDOS config choices which should move to user control via a Kconfig-like utility.
Post by b***@gmail.com
Post by John Brooks
6) The number of user IRQ handlers reduced from 4x to 2x
What are the particulars for this change? Not that I've ever run into using more than two, but being an AppleTalk user I always have one handler slot in use, and using a clock card or music card interrupt uses another.
I just halved the number of IRQ buffers & handlers to save memory. I couldn't find a scenario that needed more than 2x IRQ handlers.

My goal is to eventually have the IRQ mgr as an optional driver so users can replace it with other drivers, or choose a 2-IRQ or 4-IRQ version.
Post by b***@gmail.com
I assume that the extra 7 slots are for support of some sort of slot arbitration on the IIgs and perhaps for slot 3 of the //e? Plus there's that Mountain Hardware expansion chassis...
Yes, allowing access to slot cards without 'losing' built-in firmware or built-in devices.
Post by b***@gmail.com
Though interim support for features by loading into RamWorks and IIgs memory puts this off for a while.
Yes, I am trying to pick my battles, so getting Ramworks & GS high bank capability is the first step, with a general relocation and driver model later.
Post by b***@gmail.com
Post by John Brooks
13) Large volume support. Max volume size of 2048 GB
A) 10 bit year with 250ms time precision
B) Max file size extended from 16MB to 4GB
C) File name length extended to 30 characters
As you and I have previously discussed, that will be quite the feat(ure). If we all can pull that off and maintain a fair bit of compatibility with existing applications, that would be amazing.
I'm at a bit of a fork-in-the-road. The easiest and most-compatible approach is to just expand the ProDOS block pointers to 32-bits and leave all the file attributes alone:
1) Keep timestamps to minute precision
2) Keep 16MB max file size
3) Keep 15-character filenames

However, even this most-compatible option will require new MLI calls for read/write block, and to read directories consistently across both standard and extended-format volumes. In short, there will be changes needed to at least the Disk util apps and possibly to several apps that are reading directories and presenting lists of files.

So if the most-compatible option will still (likely) require modifying apps, should we just 'go for it', improve all these issues, and make a not-quite-as-compatible, but far-more-capable extended directory format?

I'm interested in what people think here because I'm not sure how much people care about ProDOS's current limits to timestamps, file size, or filename length.

-JB
@JBrooksBSI
MG
2018-01-28 09:16:02 UTC
Reply
Permalink
Raw Message
Post by John Brooks
Post by MG
Will there be a relatively easy way to disconnect and reconnect /RAM3 and specifying its maximum size?
What use-case(s) do you have in mind for disconnecting and reconnecting /RAM3?
Well, programs that use RamWorks memory often assume they can have all of it unless they are patched (AppleWorks comes to mind). The RamWorks tools give the option to reserve X low banks for the RAM disk, and Y for AppleWorks (with a patch), for instance.

People who actually use the machines for non-hobby work (the die-hard holdouts are out there!) might appreciate the ability to continue that practice.

Then there are other reasons... maybe I want to use the memory for some other purpose besides a RAM disk. Even Apple didn't box people into having to use /RAM... there are tech notes about disconnecting and reconnecting it, polite use of aux ram, etc.
Post by John Brooks
I am leaning toward having one Ramworks bank for ProDOS with the other 'extra' banks assigned to /RAM3 by default. A new MLI call would allow alloc/free and copy between GS/Ramworks extended banks and main/aux memory.
That would allow drivers and apps to share the extra memory without having to reboot or use a static 'reserved bank' config.
That works for anything new, and I truly like the idea, but it doesn't work for anything old. Old software is potentially going to walk all over that, as I mentioned above.
Post by John Brooks
Post by MG
I think that this kind of calls for a way of enabling/disabling certain features, either through the Aux Type of the ProDOS file, or maybe configuration data embedded at a fixed location of the ProDOS file (perhaps immediately after the three entry points)
Yes, there are a number of ProDOS config choices which should move to user control via a Kconfig-like utility.
That would certainly be useful.

If we are really going to go "all-out"... in the future, a relocating loader could make it a matter of dropping options into a directory.
Post by John Brooks
Post by MG
Post by John Brooks
6) The number of user IRQ handlers reduced from 4x to 2x
What are the particulars for this change? Not that I've ever run into using more than two, but being an AppleTalk user I always have one handler slot in use, and using a clock card or music card interrupt uses another.
I just halved the number of IRQ buffers & handlers to save memory. I couldn't find a scenario that needed more than 2x IRQ handlers.
My goal is to eventually have the IRQ mgr as an optional driver so users can replace it with other drivers, or choose a 2-IRQ or 4-IRQ version.
That's perfectly reasonable on all counts. I had forgotten about the IRQ buffers... my first thought was "what's 4 measly bytes in the Global Page worth?
Post by John Brooks
Post by MG
I assume that the extra 7 slots are for support of some sort of slot arbitration on the IIgs and perhaps for slot 3 of the //e? Plus there's that Mountain Hardware expansion chassis...
Yes, allowing access to slot cards without 'losing' built-in firmware or built-in devices.
That would be rather sweet. As far as I can tell, the GS firmware doesn't use nearly as many screen holes, and with expanded memory
Post by John Brooks
Post by MG
Post by John Brooks
13) Large volume support. Max volume size of 2048 GB
A) 10 bit year with 250ms time precision
B) Max file size extended from 16MB to 4GB
C) File name length extended to 30 characters
As you and I have previously discussed, that will be quite the feat(ure). If we all can pull that off and maintain a fair bit of compatibility with existing applications, that would be amazing.
1) Keep timestamps to minute precision
2) Keep 16MB max file size
3) Keep 15-character filenames
However, even this most-compatible option will require new MLI calls for read/write block, and to read directories consistently across both standard and extended-format volumes. In short, there will be changes needed to at least the Disk util apps and possibly to several apps that are reading directories and presenting lists of files.
Yeah, Copy II Plus is gonna have a bad time. :). And I've run across quite a few drivers in the form of a .SYSTEM file that reads the volume directory with block reads and makes assumptions about the sizes of things in order to find the next .SYSTEM file.
Post by John Brooks
So if the most-compatible option will still (likely) require modifying apps, should we just 'go for it', improve all these issues, and make a not-quite-as-compatible, but far-more-capable extended directory format?
It's worth exploring, to see how many things actually break. This seems to be the most risky of endeavors because there's no fallback to "just boot a previous version of ProDOS, as that previous version might not be able to read that particular volume.
Post by John Brooks
I'm interested in what people think here because I'm not sure how much people care about ProDOS's current limits to timestamps, file size, or filename length.
Personally, I am more interested in the "hey look what we did with this!" than anything else. ProDOS's limitations never really bothered me that much. In my youth I made the switch to ProDOS as soon as I had a copy, as it was faster and the MLI was much easier to deal with than DOS 3.3's internals. So I'm more at "how far can it be taken?" It's more the challenge of making it do things that we take for granted today, especially if, (*throws a dart at the board*). 75% of existing software doesn't know that it's on something that much more capable, but just works.

Which reminds me... I recently found a copy of one of my earliest ProDOS works... "Vision Program Launcher" which pretty much does what Bitsy Bye does, only like 100X less efficient in a cringe-worthy mixture of Applesoft and assembly language. And, it's slower than molasses at the North Pole any time of year. But not too bad for a (based on the ProDOS date stamp) 9 or 10 year old kid with no formal training. :-)

MG
MG
2018-01-28 09:26:23 UTC
Reply
Permalink
Raw Message
Post by MG
Post by John Brooks
Post by MG
I assume that the extra 7 slots are for support of some sort of slot arbitration on the IIgs and perhaps for slot 3 of the //e? Plus there's that Mountain Hardware expansion chassis...
Yes, allowing access to slot cards without 'losing' built-in firmware or built-in devices.
That would be rather sweet. As far as I can tell, the GS firmware doesn't use nearly as many screen holes, and with expanded memory
Speaking of expanded memory, my brain buffers emptied and I never finished this thought.

With the expanded memory support, they could simply be saved and restored, this should be pretty straightforward for block devices since the OS is expected to mediate access. The trouble comes in to. play with things like Copy II Plus that just get the unit number from ProDOS and drive me batty because they don't work on AppleShare volumes at all.

One nice thing about the modern Internet is that we can get real-time feedback from our client software. Did a user do something that triggered unexpected behavior? Stack trace collected and sent right back to us.

It'd be interesting to see how many programs used BLOCK_READ and BLOCK_WRITE or made slot calls. Unfortunately there's no easy way to instrument ProDOS or the firmware and have it ship that data right back to something like MixPanel. The same with any programs that attempted an AppleTalk GetInfo call. The former are software that are less likely to play nice with changes to the disk structure, whereas the latter are more likely to because Apple told people not to assume anything about the disk structure because it might be an AppleShare volume.

MG
Oliver Schmidt
2018-01-28 00:31:05 UTC
Reply
Permalink
Raw Message
Hi John,
Post by John Brooks
Oliver Schmidt has created a new Github for ProDOS 8 development (thanks Oliver!).
You're welcome! I'm proud to contribute to the doubtless most relevant
active Apple II project :-)

Regards,
Oliver
b***@gmail.com
2018-01-28 02:00:26 UTC
Reply
Permalink
Raw Message
Post by John Brooks
I've been working on a number of improvements to ProDOS. I'll list them here to give a heads-up to other developers in the community and to foster discussion.
https://github.com/orgs/ProDOS-8
Many thanks to Oliver and you for hosting the changes (perpetually?) on github!
Post by John Brooks
16 lowercase bits stored in the VERSION, MIN_VERSION fields of dir & file entries
Good idea, but will such a disk be readable in ProDOS < 2.5? How would legacy compatibility be maintained, if any?
Post by John Brooks
2) New driver for the no-slot clock
3) /RAM driver is replaced with a /RAM (aux 64k) and /RAM3 (Ramworks) driver
4) xHD 230kbps serial-port drive GS client & cross-platform server
5) Bitsy Bye includes the Bitsy Boot features 'Boot slot #' and 'Exit to GS/OS'
Perhaps these GS-specific changes could go into a seperate fork / version for the 65816... Otherwise, the only worry is that they will increase the size of the PRODOS.SYS file for non-GS users. Could perhaps have a "delete" feature like ProDOS 2.4.2small?
Post by John Brooks
6) The number of user IRQ handlers reduced from 4x to 2x
Likely future improvements (minor compatibility impact)
7) Extended date & time. Year extended to 10 bits, 1900-2923. Time extended to milliseconds via a 'seconds' word (6-bit seconds, 10-bit ms)
Compatibility in < v 2.5?
Post by John Brooks
8) Extended MLI calls to read directories, launch files, and read/write blocks on large volumes
Best idea yet. this, and HD-support for > 32MB are highest of all from both a functionality point, and usability point. This one change makes ProDOS "future-proof" in the sense that even now a 2048 GB drive is quite large...
Post by John Brooks
Optional future improvements (minor compatibility impact)
9) Simple memory API to alloc, free, and copy memory between GS or Ramworks extended memory banks and app main & aux banks
10) Extend 4-bit unit DSSS0000 (7x slots, 2x drives) to 8-bit DSSSsddd (14x slots, 16x drives)
11) Dynamic code loading & relocation for drivers, etc.
Possible future improvements (larger compatibility impact)
12) ProDOS can load into a high GS or Ramworks bank, so main 64k mem use drops to just $BF page and LC bank 1 (4.25KB). Main $D000(bank2)-$FFFF is freed up for app use
13) Large volume support. Max volume size of 2048 GB
HOORAY! Good luck and Godspeed. Can't arrive quickly enough. My hat's off to you if you can accomplish this.
Post by John Brooks
A) 10 bit year with 250ms time precision
B) Max file size extended from 16MB to 4GB
C) File name length extended to 30 characters
Thoughts, requests, concerns?
Only concern is how large PRODOS.SYS might become, for loading on 5.25" drives. How about making a "ProDOS Lite" with as small a filesize as possible, with greatly reduced, but compatilbe to ProDOS <= ProDOS 1.x? Perhaps it can get down to 10 to 12k?
Post by John Brooks
-JB
@JBrooksBSI
Oliver Schmidt
2018-01-28 13:20:51 UTC
Reply
Permalink
Raw Message
Hi John,
Post by John Brooks
3) /RAM driver is replaced with a /RAM (aux 64k) and /RAM3 (Ramworks) driver
Thoughts, requests, concerns?
I know that unfortunatly there are programs which want to temporarily
disable /RAM and just remove the last entry from the global page
device list simply presuming that this entry refers to /RAM. Therefore
it might make sense to make sure that even with /RAM3 present the
entry for /RAM stays the last entry in order to improve the
compatibility with existing programs.

Regards,
Oliver
James Davis
2018-01-28 17:57:42 UTC
Reply
Permalink
Raw Message
How will this, or will this, affect ProSEL users?
m***@gemsi.com
2018-01-31 03:25:34 UTC
Reply
Permalink
Raw Message
I don't know if this counts as it's a basic system modification, but the one enhancement I keep using is the "smart catalog" command from Beagle Bros. Big U. If you type catalog it switches to 80 column mode and then catalogs. After this event cat also does an 80 column catalog.

I ported it to whichever basic system (1.5?) comes with prodos 2.03 many years ago so I could keep using it.

Any improvement to the clock driver to give the correct year would also be good, but there are probably too many clock cards to get them all. Maybe make a directory of clock drivers, and just load the right one at boot, with an option to make a dedicated prodos disk with a selected clock driver? Or pick any two, given the later version of Prodos had two clock drivers in the image anyway (Thunderclock and GS.)

Even just for me, I have a no-slot clock, a Proclock, a timemaster HO, and the GS. The one I don't have is a Thunderclock :-/

Mike
f***@hotmail.com
2018-01-31 05:35:19 UTC
Reply
Permalink
Raw Message
Lots of interesting ideas.

Maybe instead of a separate config tool for the drivers, have a driver subdirectory with every computer and card you want to target. If you want to set up a minimal system you just delete the computer/drivers you don't want. That way you don't have to worry about either code bloat, or maintaining a config utility.

Personally would rather have extended file system size rather than extended filename size and individual file size. Seems like that would be incompatible with mass storage hardware like the CFFAv2 which has fixed hardware partition sizes.

Would a new MLI be able to increase read speeds and double-buffering at all from current?

What file utility would be potentially updated for 32-bit block pointers? Copy II plus?

F
I am Rob
2018-01-31 07:33:18 UTC
Reply
Permalink
Raw Message
Post by f***@hotmail.com
Lots of interesting ideas.
Maybe instead of a separate config tool for the drivers, have a driver subdirectory with every computer and card you want to target. If you want to set up a minimal system you just delete the computer/drivers you don't want. That way you don't have to worry about either code bloat, or maintaining a config utility.
Personally would rather have extended file system size rather than extended filename size and individual file size. Seems like that would be incompatible with mass storage hardware like the CFFAv2 which has fixed hardware partition sizes.
Would a new MLI be able to increase read speeds and double-buffering at all from current?
What file utility would be potentially updated for 32-bit block pointers? Copy II plus?
I think the block pointers for the forward and backward links are going to be a tough nut to crack. It will make just about every program that handles volumes and directories obsolete. But that is pretty much the same with any OS. A lot of older computers don't support the NTFS for PC, or the journaled for Macs.

The CFFA v2 has a lot of built in diversity. It uses a screen hole to advance its internal pointer in the firmware beyond the 65536 block limit. I have programmed a short 50 byte driver that gives me 256 volumes of 32 Mb each for a total of 8 Gb.

I just formatted the first volume without a number, then copy that volume header to the rest, putting a number from 1 to 255 after the filename Now any volume can be accessed with the ,Vv command. There is another I/O byte available for use up to 128 Gb, bit it is not mapped to a screen hole, and I felt that would make the driver too big, and 8 Gb was plenty more than enough space. When I wrote this driver, the largest card at the time was a 16 Gb and was too expensive ($40 for a 16 Gb card).

Each header in each volume keeps track of its own link pointers and bitmap pointers, and the 16-bit pointers are all that are needed within each volume range.

I believe this might be the only way to stay compatible with the multitude of software out there (But I don't mind getting proven wrong). The CFFA v2 card has a control panel that mapped the first 8 volumes (or is it 4, memory failing) to slot and drive for the software that could use it as well.

Another problem I can foresee is programs using the full directory name in its calls. And with the 64 byte limit on full path names and a large volume would likely have a lot of folders to keep all those files sorted and could easily surpass the 64 byte buffer. This might also leave a lot of programs to be incompatible with a 32 bit header.

I am not trying to be negative, just pointing some things out and hope somebody succeeds where I ran into a brick wall.

Rob
Antoine Vignau
2018-01-31 09:09:39 UTC
Reply
Permalink
Raw Message
Apple solved the issue by keeping 16-bit block numbers but increased the size of a block. From 512 bytes initially to 4K IIRC

av
mdj
2018-01-31 12:35:28 UTC
Reply
Permalink
Raw Message
Post by I am Rob
Another problem I can foresee is programs using the full directory name in its calls. And with the 64 byte limit on full path names and a large volume would likely have a lot of folders to keep all those files sorted and could easily surpass the 64 byte buffer. This might also leave a lot of programs to be incompatible with a 32 bit header.
I am not trying to be negative, just pointing some things out and hope somebody succeeds where I ran into a brick wall.
Also not wanting to be a wet blanket, but it seems to me it's tantamount to impossible to implement this in the same memory footprint, so any such extended filesystem layer would need to sit in a parallel memory bank, be it RamWorks, Saturn, or IIgs.

That being the case, creating a bespoke filesystem with all the issues that entails (lack of any existing maintenance tools being but one) would seem at least as tricky as implementing HFS, which already provides ProDOS compatibility, has existing tools, and a fair whack of existing code as well.

Leaving aside of course the fact that 8 ProDOS filesystems provide more space than I've ever needed and there's room for more. Programming challenges are like mountains - there to be scaled for their own sake.

Matt
cb meeks
2018-01-31 14:25:23 UTC
Reply
Permalink
Raw Message
Post by John Brooks
I've been working on a number of improvements to ProDOS. I'll list them here to give a heads-up to other developers in the community and to foster discussion.
-JB
@JBrooksBSI
I'm not sure if this has been mentioned before...but would it be possible to get some small/tiny terminal program included with a future release? I'm certainly not an A2 expert so maybe there is something I'm just missing. But I really like the idea of booting up the latest ProDOS and launching a small terminal program so that I can get online with some BBS's.

Thanks for all that you do!
D Finnigan
2018-01-31 15:50:53 UTC
Reply
Permalink
Raw Message
Post by cb meeks
I'm not sure if this has been mentioned before...but would it be possible
to get some small/tiny terminal program included with a future release?
I'm certainly not an A2 expert so maybe there is something I'm just
missing.
In the Super Serial Card firmware is a dumb terminal emulator.
cb meeks
2018-01-31 15:53:43 UTC
Reply
Permalink
Raw Message
Post by D Finnigan
Post by cb meeks
I'm not sure if this has been mentioned before...but would it be possible
to get some small/tiny terminal program included with a future release?
I'm certainly not an A2 expert so maybe there is something I'm just
missing.
In the Super Serial Card firmware is a dumb terminal emulator.
Uh...I didn't know that. Is that also in the virtual SSC for the IIc?
Any information on it?

Thanks!
D Finnigan
2018-01-31 16:07:20 UTC
Reply
Permalink
Raw Message
Post by cb meeks
Post by D Finnigan
Post by cb meeks
I'm not sure if this has been mentioned before...but would it be possible
to get some small/tiny terminal program included with a future release?
I'm certainly not an A2 expert so maybe there is something I'm just
missing.
In the Super Serial Card firmware is a dumb terminal emulator.
Uh...I didn't know that. Is that also in the virtual SSC for the IIc?
Any information on it?
Read the Super Serial Card manual.
Steve Nickolas
2018-01-31 18:03:12 UTC
Reply
Permalink
Raw Message
Post by cb meeks
Post by D Finnigan
Post by cb meeks
I'm not sure if this has been mentioned before...but would it be possible
to get some small/tiny terminal program included with a future release?
I'm certainly not an A2 expert so maybe there is something I'm just
missing.
In the Super Serial Card firmware is a dumb terminal emulator.
Uh...I didn't know that. Is that also in the virtual SSC for the IIc?
Any information on it?
Thanks!
The //c version of it is the first terminal program I ever used, in fact.

]PR#3
]IN#2
]<Ctrl-A>T

-uso.

Loading...