.
Post by b***@gmail.comPost by John Brooks16 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.comPost by John Brooks5) 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.comPost by John Brooks7) 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.comPost by John Brooks8) 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.comOnly 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.comWill 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.comI 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.comPost by John Brooks6) 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.comI 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.comThough 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.comPost by John Brooks13) 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