Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3925

Re: Query about ProDOS 8

Show all headers | View raw

On Friday, September 8, 2017 at 3:53:40 AM UTC-7, Oliver Schmidt wrote:
> Hi John,
> 
> >I have been considering making the following changes to future ProDOS if ti=
> >me and space allows:
> >
> >1) Replace /RAM with a new driver and disable IntC3ROM so slot 3 cards can =
> >be used
> >
> >2) Possibly save/restore/set GS speed register so ProDOS calls will always =
> >run fast
> >
> >3) Possibly have ProDOS set the Ramworks bank to move ProDOS out of LC and =
> >up to Aux memory
> >
> >
> >Thoughts?
> 
> 
> Regarding 1): Wouldn't that prohibit to use 80 columns?
> 
> Regarding 2): I personally would like that. But I _like_ improvements.
> I only set my GS to slow for games. I'm however pretty sure that there
> are authenticity hardliners who don't like that. But I guess those
> aren't into ProDOS 2.5 anyway - or ProDOS in general - or the IIgs in
> the first place ;-)
> 
> I guess one would end up asking for this to be configurable. But I
> presume that some kind of configuration will be necessary for ProDOS
> 2.5 anyway (i.e. for setting a Ramworks RAM disk split).
> 
> Regarding 3): I likely misunderstand you but here are my thoughts
> anyway...
> 
> I see two viable scenarios for modifying the PrODOS memory layout:
> 
> a) On a 128k machine programs that only use 64k (apart from
> 80col/DHGR) benefit from ProDOS moving into aux mem. The main LC
> becomes free again for its original purposes. The BASIC.SYSTEM takes
> the place of DOS 3.3. /RAM isn't present and machid fakes a 64k
> machine. The additional space in aux mem may be used for new ProDOS
> drivers and/or a small (write-through) disk cache. Maybe it would be
> feasable to move BASIC.SYSTEM to aux mem too leaving only $BE00-$BFFF
> occupied in main mem.
> 
> b) On a 128k machine with Ramworks programs that only use 128k benefit
> from ProDOS moving into a Ramworks bank.
> 
> I personally consider both scenarios interesting but as soon as new
> ProDOS 2.5 features (large volumes, new drivers, ...) makes a) or b)
> _obligatory_ I personally think it's necessary to support a) because
> it's just not good to cut off all the 128k machines from the new
> ProDOS 2.5 features. This is especially true for the //c that on the
> one hand always has 128k but on the other hand isn't exactly easy to
> extend with Ramworks-style memory.
> 
> Maybe I'm naive but I'd hope that a) and b) share most of their code
> so that supporting a) beside b) shouldn't be much additional effort.
> 
> Just my two cents,
> Oliver


Regarding 1): Wouldn't that prohibit to use 80 columns? 

It would require that ProDOS save C3 rom state, save slot 3 screen holes, and disable C3 rom before calling a card driver in slot 3, then restore C3 rom state & holes after so 80 col firmware was unaffected. It would be a pain and take a chunk of code mem, but would give back a slot.

> a) On a 128k machine programs that only use 64k (apart from
> 80col/DHGR) benefit from ProDOS moving into aux mem. 

I'm not very confident that anyplace in aux memory is safe. I have found that many apps expect to use aux memory themselves.

My current thinking is that the low 128k is 'app' memory with ProDOS either in main LC, or up in a high bank via ramworks or GS memory (ie, your scenario b).


> My own opinion would be, a text configuration file in the root of the boot 
drive could be used to set boot-time parameters, à la MS-DOS 2.0+ and 
CONFIG.SYS, but maybe that's a little overkill for a poor yickle 
8-bitter... 

uso, I think this is do-able if we assume a large-storage device rather than a 5.25 floppy to hold config file(s) and boot-time parse routines. I guess the question is whether evolving ProDOS toward a 'HD-baed' paradigm instead of ram-based, is a good idea.



> I'd actually like to see installable device drivers along with a configuration file. It starts to look a little like SOS at some point.

I've been surprised at how much SOS follows the OS design of the UCSD OS used in Apple Pascal. Also the 65816 opcodes target a combination of Apple /// (24-bit zp indirect) & UCSD p-system functionality (MVN, MVP, stack args & ptrs).

For ProDOS evolution, I think the challenge is deciding what baseline features need to be present for floppy-booted ProDOS, and how those features coexist or can be extended for larger-RAM or hd-based scenarios.

-JB
@JBrooksBSI

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-02 15:17 +0000
  Re: Query about ProDOS 8 John Brooks <jbrooks@blueshiftinc.com> - 2017-09-02 09:35 -0700
    Re: Query about ProDOS 8 James Davis <JPD.Enterprises@outlook.com> - 2017-09-02 12:20 -0700
    Re: Query about ProDOS 8 ol.sc@web.de (Oliver Schmidt) - 2017-09-08 10:53 +0000
      Re: Query about ProDOS 8 John Brooks <jbrooks@blueshiftinc.com> - 2017-09-11 21:53 -0700
        Re: Query about ProDOS 8 Steve Nickolas <usotsuki@buric.co> - 2017-09-12 03:51 -0400
          Re: Query about ProDOS 8 David Schmenk <dschmenk@gmail.com> - 2017-09-12 06:59 -0700
        Re: Query about ProDOS 8 ol.sc@web.de (Oliver Schmidt) - 2017-09-12 14:41 +0000
        Re: Query about ProDOS 8 Michael J. Mahon <mjmahon@aol.com> - 2017-09-12 11:18 -0500
  Re: Query about ProDOS 8 roger.shimada@gmail.com - 2017-09-02 10:48 -0700
  Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-02 20:34 +0000
    Re: Query about ProDOS 8 roger.shimada@gmail.com - 2017-09-02 20:35 -0700
      Re: Query about ProDOS 8 John Brooks <jbrooks@blueshiftinc.com> - 2017-09-02 21:47 -0700
        Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-03 09:34 +0000
          Re: Query about ProDOS 8 David Schmenk <dschmenk@gmail.com> - 2017-09-03 07:15 -0700
            Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-03 16:12 +0000
          Re: Query about ProDOS 8 John Brooks <jbrooks@blueshiftinc.com> - 2017-09-04 22:00 -0700
            Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-05 09:13 +0000
            Re: Query about ProDOS 8 James Davis <JPD.Enterprises@outlook.com> - 2017-09-06 17:56 -0700
              Re: Query about ProDOS 8 John Brooks <jbrooks@blueshiftinc.com> - 2017-09-07 00:00 -0700
            Re: Query about ProDOS 8 Steve Nickolas <usotsuki@buric.co> - 2017-09-10 23:30 -0400
              Re: Query about ProDOS 8 David Schmenk <dschmenk@gmail.com> - 2017-09-11 06:52 -0700
      Re: Query about ProDOS 8 roger.shimada@gmail.com - 2017-09-03 07:05 -0700
  Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-02 20:37 +0000
    Re: Query about ProDOS 8 Antoine Vignau <antoine.vignau@laposte.net> - 2017-09-02 14:07 -0700
  Re: Query about ProDOS 8 Benoit0123 <bgilon@free.fr> - 2017-09-02 21:36 +0000
  Re: Query about ProDOS 8 James Davis <JPD.Enterprises@outlook.com> - 2017-09-03 18:45 -0700
    Re: Query about ProDOS 8 Antoine Vignau <antoine.vignau@laposte.net> - 2017-09-03 23:52 -0700
  Re: Query about ProDOS 8 Jorge <jorge@jorgechamorro.com> - 2017-09-12 13:42 -0700
    Re: Query about ProDOS 8 ol.sc@web.de (Oliver Schmidt) - 2017-09-13 10:30 +0000
      Re: Query about ProDOS 8 Steven Hirsch <snhirsch@gmail.com> - 2017-09-13 08:00 -0400
      Re: Query about ProDOS 8 Jorge <jorge@jorgechamorro.com> - 2017-09-14 07:30 -0700

csiph-web