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

Groups > comp.sys.apple2.programmer > #3887 > unrolled thread

Query about ProDOS 8

Back to article view | Back to comp.sys.apple2.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#3887 — Query about ProDOS 8

Hi all,

I have a simple query here related to the working of ProDOS 8 kernel on a
slotted Apple 2 and the interface to slot ROM based device drivers.
I am currently using ProDOS 2.4.1 with an old version of ProDOS BI (i.e. BI
1.1).
The Prefix being set to a location in an online volume supported by a device
which ProDOS device driver reside on a slot ROM (entry point $C75F for my
Omnidisc SCSI device in the Virtual 2 emulator (likely to follow the
Smartport protocol itself).
At BI prompt, issue the keyboard sequence below:
]CALL-151
*C007:0
]CAT
=====> Screen cleared + test routine run and the mention IOU appears. The
test routines for the enhanced Apple //e see to be located in âge $C6 and
$C7 of the internal CX ROM.
My query is that, wouldn't it be better to set the SLTCXROM ($C006) from
within ProDOS before calling such device drivers?
Forgive me if this has already been discussed in this newsgroup.
Thank you for any feedback on this point,
Best regards,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [next] | [standalone]

#3888

On Saturday, September 2, 2017 at 8:22:07 AM UTC-7, Benoit0123 wrote:
> Hi all,
> 
> I have a simple query here related to the working of ProDOS 8 kernel on a
> slotted Apple 2 and the interface to slot ROM based device drivers.
> I am currently using ProDOS 2.4.1 with an old version of ProDOS BI (i.e. BI
> 1.1).
> The Prefix being set to a location in an online volume supported by a device
> which ProDOS device driver reside on a slot ROM (entry point $C75F for my
> Omnidisc SCSI device in the Virtual 2 emulator (likely to follow the
> Smartport protocol itself).
> At BI prompt, issue the keyboard sequence below:
> ]CALL-151
> *C007:0
> ]CAT
> =====> Screen cleared + test routine run and the mention IOU appears. The
> test routines for the enhanced Apple //e see to be located in âge $C6 and
> $C7 of the internal CX ROM.
> My query is that, wouldn't it be better to set the SLTCXROM ($C006) from
> within ProDOS before calling such device drivers?
> Forgive me if this has already been discussed in this newsgroup.
> Thank you for any feedback on this point,
> Best regards,
> Benoît
> 
> 
> -- 
> Growing old is mandatory..
> growing up is optional..
> But the other way round is as true.

Hi Benoit

> My query is that, wouldn't it be better to set the SLTCXROM ($C006) from
> within ProDOS before calling such device drivers?

The answer is 'maybe'.  :)

There is quite a lot of bank switch state on the Apple II, and the philosophy Apple used with ProDOS was to only set the minimal amount of state needed for normal operation. IE, 'Keep It Simple"

ProDOS does not set aux mem switches, rom banks, GS ram shadow, Ramworks/Saturn bank or CPU speed/mode.

The only bank switch settings controlled by the ProDOS kernel is language card (which it saves, sets, and restores), and setting IntC3ROM ($C00A) on //e, IIc, and IIGS.

The reason IntC3ROM is forced on (which means that card rom in slot 3 is not accessible), is because the /RAM driver uses the aux mem copy & execute functions in the C3ROM.

One could argue that ProDOS should set all switches in order to provide deterministic OS services, which may be the point of your query.

The two drawbacks of having ProDOS control state more comprehensively are:

  1) Speed & code size penalty for saving, setting, and restoring state each ProDOS call

  2) Restricting the user from controlling the machine state as they desire, such as having multiple 'virtual' Apple II in multiple 64k aux banks, loading data directly into DHGR or SHR buffers banked in at $2000, etc.

I have been considering making the following changes to future ProDOS if time 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?

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3890

Hi Benoit,

K.I.S.S. and NOT "Restricting the user from controlling the machine state as they desire" are the most important part of this.  You should set up your machine specifically as you need/desire it to be in your HELLO/STARTUP program.  Everyone's Apple is not Red!--E.g., Not identically enhanced!

Yours truly,

James Davis

[toc] | [prev] | [next] | [standalone]

#3918

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

[toc] | [prev] | [next] | [standalone]

#3925

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

[toc] | [prev] | [next] | [standalone]

#3926

On Mon, 11 Sep 2017, John Brooks wrote:

> 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.

Well, I got the idea from MS-DOS 2.  You can probably see where I'm going 
with that. ;)

But a 180K floppy with PC DOS 2.1 was enough that you could load a couple 
drivers through CONFIG.SYS if need be - ANSI.SYS, for one, was quite 
popular and useful.  I don't think throwing floppy users under the bus 
would be necessary to implement such a thing.

-uso.

[toc] | [prev] | [next] | [standalone]

#3927

On Tuesday, 12 September 2017 00:51:57 UTC-7, Steve Nickolas  wrote:
> On Mon, 11 Sep 2017, John Brooks wrote:
> 
> > 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.
> 
> Well, I got the idea from MS-DOS 2.  You can probably see where I'm going 
> with that. ;)
> 
> But a 180K floppy with PC DOS 2.1 was enough that you could load a couple 
> drivers through CONFIG.SYS if need be - ANSI.SYS, for one, was quite 
> popular and useful.  I don't think throwing floppy users under the bus 
> would be necessary to implement such a thing.
> 
> -uso.

It doesn't necessarily have to be part of the ProDOS binary proper. Somewhere in the bowels of ProDOS must be the ATINIT handler. If that was co-opted to instead run the device driver loader module that would have all the loader/config parser code (including ATINIT), then HD installs could load up as many drivers as they want, whereas floppy users could forgo the loader module and no harm, no foul (but no additional drivers, either).

Or am I smoking crack?

Dave...

[toc] | [prev] | [next] | [standalone]

#3928

On Mon, 11 Sep 2017 21:53:18 -0700 (PDT), John Brooks
<jbrooks@blueshiftinc.com> wrote:

>Regarding 1): Wouldn't that prohibit to use 80 columns?=20
>
>It would require that ProDOS save C3 rom state, save slot 3 screen holes, a=
>nd disable C3 rom before calling a card driver in slot 3, then restore C3 r=
>om state & holes after so 80 col firmware was unaffected. It would be a pai=
>n and take a chunk of code mem, but would give back a slot.

So a PR#3 would always go into the 80 col firmware. The only thing the
user would loose would be the ability to boot from the device in slot
3. Hard to say if the feature would justify the necessary mem.

>I'm not very confident that anyplace in aux memory is safe. I have found th=
>at 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 scena=
>rio b).

I of course don't know the percentage but there is surely a
considerable amount of software running on 64kB machines - and that
software for sure doesn't use auxmem ;-) The amount of ProDOS software
falling into that category is likely actually increasing given the
recent ProDOS ports of old titles. Adding the fact that every
Applesoft BASIC program falls into the 64kB category too makes me
think that there are (more than) enough use cases for a 64k 'app'
memory variant.

If ProDOS runs in auxmem and an app ignores machid saying there ain't
no auxmem and goes ahead using it then this is surely a suboptimal
user experience. But I don't see the general difference to an app
making direct use of a RAMworks card and trampling over ProDOS sitting
there...

Just my two cents,
Oliver

[toc] | [prev] | [next] | [standalone]

#3930

John Brooks <jbrooks@blueshiftinc.com> wrote:
> 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.

I agree, John, this is the critical "fork in the road".

An HD-based system could, for example, allow command extensions to be
disk-resident, like most other disk OSs.  In fact, many of the BASIC.SYSTEM
commands could be made non-resident, allowing for a reduction in memory
usage (requiring only a "transient command" chunk of memory). 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3889

On Saturday, September 2, 2017 at 10:22:07 AM UTC-5, Benoit0123 wrote:
> At BI prompt, issue the keyboard sequence below:
> ]CALL-151
> *C007:0
> ]CAT
> =====> Screen cleared + test routine run and the mention IOU appears. The
> test routines for the enhanced Apple //e see to be located in âge $C6 and
> $C7 of the internal CX ROM.
> My query is that, wouldn't it be better to set the SLTCXROM ($C006) from
> within ProDOS before calling such device drivers?

No.

The requirements for ProDOS 1.x are for a 64k Apple II. I do not even believe that an auto-start ROM is required. The original Apple II and II+ do not have an alternate $Cxxx space. The ROM 0 //c and later bankswitch the entire ROM space in a different way than the //e.

Use of the alternate $Cxxx space is only useful for people burning their own ROMs. It was never intended to be used directly.

[toc] | [prev] | [next] | [standalone]

#3892

Thank you John, Roger and James for your quick replies.

The point here is that I got a "crash" as a ProDOS device was read from an
interrupt routine while the mini assembler was active. This is on an
Enhanced Apple //e.

a) On the Enhanced //e, interrupts are not disabled (i.e. no SEI
instruction) while the internal ROM is selected see code at $FFB4 (GOTOCX),
unlike what happens on the "unenhanced //e";

b) When a "!" is issued by the user at the monitor prompt, control is passed
to a vector in $CX space (thru the code above) (Y value $0D) to lead in fine
to the mini assembler. Unlike other vectors (usually 80col. firmware
related), there is no immediate return (chronologically speaking) to the
proper "ending" function for deactivating of the internal ROM.
c) The final ML code that is finally called is at address $FCF0:
 LDA #A1 "!" prompt...
 STA PROMPT
 *JSR GETLNZ*
 *STA C006*
 JMP CF9C (DOINST)
Here we see that C006 is updated but only after a GETLNZ call, that is, if
an IRQ appears while the program is in GETLNZ processing and that IRQ calls
a MLI ProDOS function, chances are high that that the problem rises again.
So from now on, I would personally insert a STA C006 before a ProDOS MLI
call within interrupt routines just to avoid this state.

Best regards,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3897

On Saturday, September 2, 2017 at 3:39:13 PM UTC-5, Benoit0123 wrote:
> I got a "crash" as a ProDOS device was read from an
> interrupt routine while the mini assembler was active. This is on an
> Enhanced Apple //e.

Short answer: Try saving and restoring $44 in your interrupt handling routine.

Long story:

Making a ProDOS call in an interrupt routine makes my brain hurt. But anyway....

I walked through the enhanced //e interrupt code, which uses many cycles but looks to do the right thing.

Since most of an Apple II's time is spent in one GETLN, I looked at the mini-assembler.

Both the enhanced //e interrupt handler and the mini-assembler use $44. It's vital for the enhanced //e interrupt handler: it contains the memory banks in use when the interrupt occurred.

There is also the possibility that the ProDOS call changes $44. (This type of thing has been reported before; John Brooks will know.)

So I think the easiest thing to try is to immediately save $44 in the interrupt routine then restore just before the return.

[toc] | [prev] | [next] | [standalone]

#3898

On Saturday, September 2, 2017 at 8:35:39 PM UTC-7, roger....@gmail.com wrote:
> On Saturday, September 2, 2017 at 3:39:13 PM UTC-5, Benoit0123 wrote:
> > I got a "crash" as a ProDOS device was read from an
> > interrupt routine while the mini assembler was active. This is on an
> > Enhanced Apple //e.
> 
> Short answer: Try saving and restoring $44 in your interrupt handling routine.
> 
> Long story:
> 
> Making a ProDOS call in an interrupt routine makes my brain hurt. But anyway....
> 
> I walked through the enhanced //e interrupt code, which uses many cycles but looks to do the right thing.
> 
> Since most of an Apple II's time is spent in one GETLN, I looked at the mini-assembler.
> 
> Both the enhanced //e interrupt handler and the mini-assembler use $44. It's vital for the enhanced //e interrupt handler: it contains the memory banks in use when the interrupt occurred.
> 
> There is also the possibility that the ProDOS call changes $44. (This type of thing has been reported before; John Brooks will know.)
> 
> So I think the easiest thing to try is to immediately save $44 in the interrupt routine then restore just before the return.

Yes, ProDOS uses $40-$4E and drivers use $3A-$3F. ProDOS 1.x would save & restore zero page locations. ProDOS 2.x clobbers them, but assumes they are also clobbered in turn by other users (ie, no zp is 'owned' by ProDOS).

The ProDOS interrupt manager saves $45 on entry & restores it on exit since the Apple ][ & ][+ ROMs place the acc-at-IRQ at $45 and ProDOS would clobber it if it were not saved.

> The point here is that I got a "crash" as a ProDOS device was read from an 
> interrupt routine while the mini assembler was active. This is on an 
> Enhanced Apple //e

The IRQ handler which is making the ProDOS call should make sure the system is in an appropriate state before calling ProDOS. In particular, that will mean saving/setting/restoring ROM-banking and aux-mem-banking switches for //e, IIc, IIGS.

Out of curiosity, what ProDOS calls are being made in the IRQ handler and why? It sounds like a pretty unusual use-case.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3900

Thank you John and Roger for the advice which I am already following (cf.
previous csap post on the subject).


John Brooks wrote:
> Out of curiosity, what ProDOS calls are being made in the IRQ handler and
> why? It sounds like a pretty unusual use-case.
> 
> -JB
> @JBrooksBSI
>
John for your curiosity:
I am using the SET_MARK/READ and SET_MARK/WRITE MLI calls to read/write an
already opened ProDOS file on a big proDOS device (Omnidisc in my dev env.
but this likely a RAMFactor RAM memory card or other slinky Apple //e memory
card) in the "end user" environment).
This is for getting a detailed (ie. per module beginPC, endPC) ) gathering
of application performance and being able to gather data that would be
analyzed afterwards in an "offline" mode. Two external commands one for
creating and pre sizing the big data file, looking up an interrupt source
(preferably 1millisecond but defaulting to mousecard  VBL (50/60ms)) and
finally (second BI external command duties) inhibiting the source,
deallocating the interrupt service routine from ProDOS chain and closing the
file. I presume this to be run on a slotted Apple //e (enhanced ROM), a
memory expanded ROM Apple //c or a 2GS.

John, as you're quoting the /RAM[3] device driver you're designing for next
ProDOS kernel version, please would you setup a way for such driver to not
take over the whole set of memory banks (configuration option) and this let
part of the RAM works compatible card usable by other third party utilities
(like a memory storage for Applesoft arrays, a spooler for "old" printers,
and other "exotic" ways of using it (I'm sure the community at large will
make creative use of this available space in the future ;-) ).

Best regards,
Benoît



-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3902

On Sunday, 3 September 2017 02:39:00 UTC-7, Benoit0123  wrote:
> Thank you John and Roger for the advice which I am already following (cf.
> previous csap post on the subject).
> 
> 
> John Brooks wrote:
> > Out of curiosity, what ProDOS calls are being made in the IRQ handler and
> > why? It sounds like a pretty unusual use-case.
> > 
> > -JB
> > @JBrooksBSI
> >
> John for your curiosity:
> I am using the SET_MARK/READ and SET_MARK/WRITE MLI calls to read/write an
> already opened ProDOS file on a big proDOS device (Omnidisc in my dev env.
> but this likely a RAMFactor RAM memory card or other slinky Apple //e memory
> card) in the "end user" environment).
> This is for getting a detailed (ie. per module beginPC, endPC) ) gathering
> of application performance and being able to gather data that would be
> analyzed afterwards in an "offline" mode. Two external commands one for
> creating and pre sizing the big data file, looking up an interrupt source
> (preferably 1millisecond but defaulting to mousecard  VBL (50/60ms)) and
> finally (second BI external command duties) inhibiting the source,
> deallocating the interrupt service routine from ProDOS chain and closing the
> file. I presume this to be run on a slotted Apple //e (enhanced ROM), a
> memory expanded ROM Apple //c or a 2GS.
> 
> John, as you're quoting the /RAM[3] device driver you're designing for next
> ProDOS kernel version, please would you setup a way for such driver to not
> take over the whole set of memory banks (configuration option) and this let
> part of the RAM works compatible card usable by other third party utilities
> (like a memory storage for Applesoft arrays, a spooler for "old" printers,
> and other "exotic" ways of using it (I'm sure the community at large will
> make creative use of this available space in the future ;-) ).
> 
> Best regards,
> Benoît
> 
> 
> 
> -- 
> Growing old is mandatory..
> growing up is optional..
> But the other way round is as true.

There are lots of reasons not to call ProDOS in an interrupt routine, but you are following all these procedures? http://www.easy68k.com/paulrsm/6502/PDOS8TRM.HTM#6.2.1

And you you are checking that you aren't already in a previous ISR call when the next VBL interrupt comes in? Its quite possible that the call to ProDOS will take more than the ~16 ms before the next interrupt comes in. IIRC, the mouse interrupts are funny about being immediately re-triggered.

Dave...

[toc] | [prev] | [next] | [standalone]

#3903

Hello David,

David Schmenk wrote:
> There are lots of reasons not to call ProDOS in an interrupt routine, but
> you are following all these procedures?
> http://www.easy68k.com/paulrsm/6502/PDOS8TRM.HTM#6.2.1
Thank you for the link to the ProDOS TRM.
I’ve already taken care that whenever the sampled application is itself
progressing thru a ProDOS MLI call (MLIActv byte set within GP), then my own
routine is compliant to the behavior recommended in this manual.
Also, whenever an interrupt is raised by the source I am interested in, and
my previous interrupt handling routine has not completed, then I am
implementing an in memory only update and leave the relevant updates for
later stages (foreground processing by second BI external command before
closing the file).
> 
> And you you are checking that you aren't already in a previous ISR call
> when the next VBL interrupt comes in? Its quite possible that the call to
> ProDOS will take more than the ~16 ms before the next interrupt comes in.
> IIRC, the mouse interrupts are funny about being immediately re-triggered.
> 
> Dave...
Related to « strange »  mouse firmware behavior, back to early 2015, here
was a discussion in cea2 newsgroup about mouse handling (post created as I
worked on a previous utility dealing with mouse interrupts (but not within
ProDOS).
https://groups.google.com/forum/#!topic/comp.emulators.apple2/CkaBF4BBFKE

Best regards,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3909

On Sunday, September 3, 2017 at 2:39:00 AM UTC-7, Benoit0123 wrote:
> Thank you John and Roger for the advice which I am already following (cf.
> previous csap post on the subject).
> 
> 
> John Brooks wrote:
> > Out of curiosity, what ProDOS calls are being made in the IRQ handler and
> > why? It sounds like a pretty unusual use-case.
> > 
> > -JB
> > @JBrooksBSI
> >
> John for your curiosity:
> I am using the SET_MARK/READ and SET_MARK/WRITE MLI calls to read/write an
> already opened ProDOS file on a big proDOS device (Omnidisc in my dev env.
> but this likely a RAMFactor RAM memory card or other slinky Apple //e memory
> card) in the "end user" environment).
> This is for getting a detailed (ie. per module beginPC, endPC) ) gathering
> of application performance and being able to gather data that would be
> analyzed afterwards in an "offline" mode. Two external commands one for
> creating and pre sizing the big data file, looking up an interrupt source
> (preferably 1millisecond but defaulting to mousecard  VBL (50/60ms)) and
> finally (second BI external command duties) inhibiting the source,
> deallocating the interrupt service routine from ProDOS chain and closing the
> file. I presume this to be run on a slotted Apple //e (enhanced ROM), a
> memory expanded ROM Apple //c or a 2GS.
> 
> John, as you're quoting the /RAM[3] device driver you're designing for next
> ProDOS kernel version, please would you setup a way for such driver to not
> take over the whole set of memory banks (configuration option) and this let
> part of the RAM works compatible card usable by other third party utilities
> (like a memory storage for Applesoft arrays, a spooler for "old" printers,
> and other "exotic" ways of using it (I'm sure the community at large will
> make creative use of this available space in the future ;-) ).
> 
> Best regards,
> Benoît
> 
> 
> 
> -- 
> Growing old is mandatory..
> growing up is optional..
> But the other way round is as true.

Hi Benoit. That sounds like a pretty cool chunk of Apple II tech.

So is it a sampling profiler? IE, recording the PC every IRQ and streaming it to a big file? If so, what are the set_mark & read in IRQ used for?

For high-speed interrupts, you might consider running your code on the IIGS. The GS provides great IRQ control either through scan-line interrupts, or by using the Ensoniq for up to 32x general-purpose timers, each with IRQ enable/disable control.

Your instrumented code can still run at 1MHz 6502 on the GS, and can also rely on the /RAM5 ram disk for fast block I/O.

Is this instrumentation intended to run on a real Apple II machine in the future? If emulation is good enough for your use-case, you could also instrument GSplus, etc to log data faster than an IRQ-sampler could manage (every CPU insn if you wanted).


> John, as you're quoting the /RAM[3] device driver you're designing for next 
ProDOS kernel version, please would you setup a way for such driver to not 
take over the whole set of memory banks (configuration option)

Yes, my current in-progress driver has both a min-bank and max-bank parameter which is used at boot to set up the size of the /RAM3 drive. These values are currently set to 1 and the max bank found by scanning the Ramworks banks, but my intent is to allow them to be adjusted for Appleworks and other 'big aux mem' applications.

However, since bank assignment is a boot-time decision, I do not have a good idea on the API/approach to use to allow these parameters to be adjusted. Any ideas on how you'd like to see aux-mem banks reserved?

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3910

John Brooks wrote:
(small snip)
> Hi Benoit. That sounds like a pretty cool chunk of Apple II tech.
Thanks John.
> So is it a sampling profiler? IE, recording the PC every IRQ and streaming
> it to a big file? If so, what are the set_mark & read in IRQ used for?
My current design is to store a sequence of frequency counters (indexed by
PC) into this file.
So a part of the ISR duty currently would be to:
* Gather the foreground PC and memory state (LC bank switching and Main/Aux
mem state) from the pz0/stack that the ROM firmware (IRQ handler) put there;
* Compute a hash value (hash function being worked on currently) based on
those raw data;
* Use the result value as the offset within the data file. Every reachable
storage cell will be three bytes wide (for a counter/frequency value in the
range 0..16777215, initially 0).
* Read this counter from file by a SET_MARK, READ sequence
* Increment the counter by one (using *saturated* unsigned arithmetic)
* Write back this counter value to the file @ at the same offset therefore a
second SET_MARK call to rewind the file position by the cell size amount
before issuing the WRITE.
To sum things up, it is not my intent currently to write the raw details in
a pure sequencial form into a potentially infinite size file.

> For high-speed interrupts, you might consider running your code on the
> IIGS. The GS provides great IRQ control either through scan-line
> interrupts, or by using the Ensoniq for up to 32x general-purpose timers,
> each with IRQ enable/disable control.
> 
> Your instrumented code can still run at 1MHz 6502 on the GS, and can also
> rely on the /RAM5 ram disk for fast block I/O.
At the early stage of design, I would rather be using dev environments which
I am confortable with. Therefore I am limiting myself to the Apple //e
(enhanced) for the time being.
As soon as I think the application/utility is be ready to be released (at
least for the capture/collect/gather step), I’ll do it and the complete
source will be included.
> Is this instrumentation intended to run on a real Apple II machine in the
> future? If emulation is good enough for your use-case, you could also
> instrument GSplus, etc to log data faster than an IRQ-sampler could manage
> (every CPU insn if you wanted).
Thank you John, I’ll get a look at GSPort and GSPlus.
> Yes, my current in-progress driver has both a min-bank and max-bank
> parameter which is used at boot to set up the size of the /RAM3 drive.
> These values are currently set to 1 and the max bank found by scanning the
> Ramworks banks, but my intent is to allow them to be adjusted for
> Appleworks and other 'big aux mem' applications.
> 
> However, since bank assignment is a boot-time decision, I do not have a
> good idea on the API/approach to use to allow these parameters to be
> adjusted. Any ideas on how you'd like to see aux-mem banks reserved?
I think that the only medium for communicating to a booting process would be
to use the keyboard (including the open/close apple keys) or the game
paddles/joystick buttons on the 2 and 2+).
However, there might be peripheral cards (e.g. the Transwarp original
accelerator in one of my Apple //e) which test for some keys to be pressed
upon powering up the Apple 2. So an idea I have would be to have a delayed
keyboard scan routine in the ProDOS Loader which, for say for 1 or 2 seconds
waits for a user key press and reacts accordingly with an adequate prompt
displayed on screen. On the absence of any user keypress within this delay,
then a default configuration will be activated, one « non default »
configuration could also dictates to postpone the RAM driver install to
sometime in the future.
The allowable configurations could be stored in some bytes within the first
blocks of the boot volume if space allows (which I hope). Those
configurations could contain directives for acceleration status, RAM drive
driver installation and amount of disk space allocated. There could even
could be some extra bits available for third party extensions (e.g. network
settings). The system disc could also include a utility to import/export
such configurations from/to text files.. but I disgress…
> 
> -JB
> @JBrooksBSI
>


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3912

On Monday, September 4, 2017 at 10:00:32 PM UTC-7, John Brooks wrote:
> Any ideas on how you'd like to see aux-mem banks reserved?

Just an idea: Why wouldn't you use a byte/bit-map for all the banks/sub-banks/sections (1 byte per each subsection) containing slot numbers for who owns them--kind of like that thing for the 14 Apple IIgs slots that was never implemented; or, like a VTOC or MBR, or something to that effect?

[toc] | [prev] | [next] | [standalone]

#3913

On Wednesday, September 6, 2017 at 5:56:13 PM UTC-7, James Davis wrote:
> On Monday, September 4, 2017 at 10:00:32 PM UTC-7, John Brooks wrote:
> > Any ideas on how you'd like to see aux-mem banks reserved?
> 
> Just an idea: Why wouldn't you use a byte/bit-map for all the banks/sub-banks/sections (1 byte per each subsection) containing slot numbers for who owns them--kind of like that thing for the 14 Apple IIgs slots that was never implemented; or, like a VTOC or MBR, or something to that effect?

A byte/bit-map works well for random-access tracking, but the use-case here is boot-time reservation.

How should the reserve banks be requested from ProDOS and what happens if the same ProDOS volume is then booted on a machine with fewer aux ram banks?

The /RAM3 driver requires it's banks to be contiguous, so it just uses a min & max bank, but those parameters depend on the ramworks size and the reserved banks, however that is specified.

As usual the devil is in the details.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web