| ProDOS - 64K ProDOS-8 on a ///? [message #370452] |
Mon, 09 July 2018 13:09  |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
I've been thinking - and right now it's a little above my head, but with
some musing, it might be doable.
The idea is to create a reorganized implementation of ProDOS-8 that would
contain a modified Apple ][ monitor from F800-FFFF to allow some programs
to run unmodified on an Apple ///, in the so-called "Satan Mode",
bootstrapping ProDOS from the SOS bootloader and thus retaining the
ability to boot on both an Apple ][ and an Apple ///. (I say reorganized
because F800-FFFF is used by ProDOS normally.)
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370461 is a reply to message #370452] |
Mon, 09 July 2018 13:43  |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/9/2018 1:09 PM, Steve Nickolas wrote:
> I've been thinking - and right now it's a little above my head, but with
> some musing, it might be doable.
Retooling ProDOS to run on the /// wouldn't be too bad. The salient
points are as you mention making required ROM entry points available by
loading them in, and retooling how auxiliary memory is managed. Buffers
could be moved out to pages of their own, and so on. From a ProDOS
program's perspective, the OS calls could be safe enough - but any
128k-aware program would fail when it tried to manipulate language card
banking.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370463 is a reply to message #370461] |
Mon, 09 July 2018 14:05 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 9 Jul 2018, David Schmidt wrote:
> On 7/9/2018 1:09 PM, Steve Nickolas wrote:
>> I've been thinking - and right now it's a little above my head, but with
>> some musing, it might be doable.
>
> Retooling ProDOS to run on the /// wouldn't be too bad. The salient points
> are as you mention making required ROM entry points available by loading them
> in, and retooling how auxiliary memory is managed. Buffers could be moved
> out to pages of their own, and so on. From a ProDOS program's perspective,
> the OS calls could be safe enough - but any 128k-aware program would fail
> when it tried to manipulate language card banking.
My idea was to make it report a 64K system - possibly with a separate
status bit to identify ProDOS III (and how much Apple /// RAM there was).
If not for that I felt it necessary to keep a subset of Apple ][ ROM
functionality resident, it would absolutely fit in the ///'s RAM without
banking. It's that extra 2K that'll be a pinch. ;)
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370464 is a reply to message #370463] |
Mon, 09 July 2018 14:12 |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/9/2018 2:05 PM, Steve Nickolas wrote:
> On Mon, 9 Jul 2018, David Schmidt wrote:
>
>> On 7/9/2018 1:09 PM, Steve Nickolas wrote:
>>> I've been thinking - and right now it's a little above my head, but
>>> with some musing, it might be doable.
>>
>> Retooling ProDOS to run on the /// wouldn't be too bad. The salient
>> points are as you mention making required ROM entry points available
>> by loading them in, and retooling how auxiliary memory is managed.
>> Buffers could be moved out to pages of their own, and so on. From a
>> ProDOS program's perspective, the OS calls could be safe enough - but
>> any 128k-aware program would fail when it tried to manipulate language
>> card banking.
>
> My idea was to make it report a 64K system - possibly with a separate
> status bit to identify ProDOS III (and how much Apple /// RAM there was).
>
> If not for that I felt it necessary to keep a subset of Apple ][ ROM
> functionality resident, it would absolutely fit in the ///'s RAM without
> banking. It's that extra 2K that'll be a pinch. ;)
But a 64k ProDOS program could reasonably assume _all_ of the Apple II
ROM was resident. I'm not sure you could/should get away with a subset.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370470 is a reply to message #370464] |
Mon, 09 July 2018 15:50 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 9 Jul 2018, David Schmidt wrote:
> On 7/9/2018 2:05 PM, Steve Nickolas wrote:
>> On Mon, 9 Jul 2018, David Schmidt wrote:
>>
>>> On 7/9/2018 1:09 PM, Steve Nickolas wrote:
>>>> I've been thinking - and right now it's a little above my head, but with
>>>> some musing, it might be doable.
>>>
>>> Retooling ProDOS to run on the /// wouldn't be too bad. The salient
>>> points are as you mention making required ROM entry points available by
>>> loading them in, and retooling how auxiliary memory is managed. Buffers
>>> could be moved out to pages of their own, and so on. From a ProDOS
>>> program's perspective, the OS calls could be safe enough - but any
>>> 128k-aware program would fail when it tried to manipulate language card
>>> banking.
>>
>> My idea was to make it report a 64K system - possibly with a separate
>> status bit to identify ProDOS III (and how much Apple /// RAM there was).
>>
>> If not for that I felt it necessary to keep a subset of Apple ][ ROM
>> functionality resident, it would absolutely fit in the ///'s RAM without
>> banking. It's that extra 2K that'll be a pinch. ;)
>
> But a 64k ProDOS program could reasonably assume _all_ of the Apple II ROM
> was resident. I'm not sure you could/should get away with a subset.
>
As long as it doesn't use BASIC... ;)
If it's written to work on both a ][ and a ][+, then there's a good chance
it doesn't rely on anything particular being resident except for the
monitor (F800-FFFF).
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370608 is a reply to message #370470] |
Wed, 11 July 2018 23:37 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
http://apple3.org/Documents/Magazines/AppleIIIBits.html
I haven't read this in years, so time to refresh my memory. ;)
So apparently setting a certain flag in one of the VIAs (the "6" bit of
FFDF) will give all of C000-CFFF for RAM - which is good, I'd probably use
C800-CFFF to store parts of the ProDOS-3 code which don't need access to
disk hardware, then put the old Selector in memory from C000-C3FF.
I think that for a good amount of software, just having the monitor entry
points (F800-FFFF), and then pointing E000 and E003 back into the monitor,
would suffice, so far as they don't require a specific version of BASIC to
be resident in memory. In this example, most of ProDOS would always be
visible.
The loader would need to set up memory the way my old "Star Emulator" did
- i.e., as close to the ][ as possible, ZP at 00, active memory page at 0
- and would need to be in the proper format of an SOS.KERNEL file. I
might patch the bootloader to want the file to be called PRODOS3 instead -
either way, the disk would be bootable on both an Apple ][ and an Apple
///, just loading the appropriate kernel, depending on which system is
running.
-uso.
|
|
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370625 is a reply to message #370624] |
Thu, 12 July 2018 09:50 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 12 Jul 2018, David Schmidt wrote:
> On 7/11/2018 11:37 PM, Steve Nickolas wrote:
>> http://apple3.org/Documents/Magazines/AppleIIIBits.html
>>
>> I haven't read this in years, so time to refresh my memory. ;)
>
> That's a start. For the next level, check out Arbee's Apple /// work in
> MAME/MESS.
> http://rbelmont.mameworld.info/?p=884
>
I suppose the tested and proven code I wrote back then and also tested
with MESS is helpful too ;)
It looks like most of the time it would be desirable to do what that code
did. tl;dr set FFD0, FFDE and FFEE to 0; set the bank register (FFEF) to
F0 (this is NOT the default state coming in from the OS loader, so I had
to use a trampoline to do it back then); then set the environment register
(FFDF) to F0 (and then to FC when leaving the setup function).
Looking at the apple3.org page, the bit with value $08 is the one that
controls whether high memory is writable, and probably should be off while
in ProDOS, and on while out of ProDOS. The bit with value $40 appears to
control what memory is banked in at Cxxx, and would let ProDOS fit without
having to go beyond a 64K base. Of course ProDOS and BASIC won't fit
together in this scheme! (But there is still room for the Monitor, which
would be enough for a fair amount of software.)
Unfortunately, this *requires* reorganizing ProDOS. Perhaps with a
brute-force method, the monitor and the ProDOS F800-FFFF code could be
both stored in the Cxxx area and "rolled" in and out as needed, and with
that system a regular ProDOS image could be used, but that sounds like an
even more brutal approach than trying to *port* ProDOS as I've suggested.
I'm guessing I'm going to have to go through the ProDOS-8 1.7 code myself
and try to get it all working in CA65, before it'll be possible to write a
new wrapper.
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370643 is a reply to message #370464] |
Thu, 12 July 2018 20:43 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 9 Jul 2018, David Schmidt wrote:
> On 7/9/2018 2:05 PM, Steve Nickolas wrote:
>> On Mon, 9 Jul 2018, David Schmidt wrote:
>>
>>> On 7/9/2018 1:09 PM, Steve Nickolas wrote:
>>>> I've been thinking - and right now it's a little above my head, but with
>>>> some musing, it might be doable.
>>>
>>> Retooling ProDOS to run on the /// wouldn't be too bad. The salient
>>> points are as you mention making required ROM entry points available by
>>> loading them in, and retooling how auxiliary memory is managed. Buffers
>>> could be moved out to pages of their own, and so on. From a ProDOS
>>> program's perspective, the OS calls could be safe enough - but any
>>> 128k-aware program would fail when it tried to manipulate language card
>>> banking.
>>
>> My idea was to make it report a 64K system - possibly with a separate
>> status bit to identify ProDOS III (and how much Apple /// RAM there was).
>>
>> If not for that I felt it necessary to keep a subset of Apple ][ ROM
>> functionality resident, it would absolutely fit in the ///'s RAM without
>> banking. It's that extra 2K that'll be a pinch. ;)
>
> But a 64k ProDOS program could reasonably assume _all_ of the Apple II ROM
> was resident. I'm not sure you could/should get away with a subset.
>
Again that depends. ;)
If I wasn't obvious elsewhere, that *subset* equals the portion that is
shared between the ][ and ][+. AKA F800-FFFF. For a program to work the
same on both the ][ and the ][+, it would have to assume that it couldn't
rely on the contents of D000-F7FF - or alternatively have two sets of code
depending on whether it ran on an Integer machine or one with FPBASIC. I
would think the former is more likely.
If just THAT part is available, it might be enough for something that uses
the monitor ROM, but never touches BASIC.
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370662 is a reply to message #370643] |
Fri, 13 July 2018 10:42 |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/12/2018 8:43 PM, Steve Nickolas wrote:
> On Mon, 9 Jul 2018, David Schmidt wrote:
>
>> On 7/9/2018 2:05 PM, Steve Nickolas wrote:
>>> On Mon, 9 Jul 2018, David Schmidt wrote:
>>>
>>>> On 7/9/2018 1:09 PM, Steve Nickolas wrote:
>>>> > I've been thinking - and right now it's a little above my head, but
>>>> > with some musing, it might be doable.
>>>>
>>>> Retooling ProDOS to run on the /// wouldn't be too bad. The salient
>>>> points are as you mention making required ROM entry points available
>>>> by loading them in, and retooling how auxiliary memory is managed.
>>>> Buffers could be moved out to pages of their own, and so on. From a
>>>> ProDOS program's perspective, the OS calls could be safe enough -
>>>> but any 128k-aware program would fail when it tried to manipulate
>>>> language card banking.
>>>
>>> My idea was to make it report a 64K system - possibly with a separate
>>> status bit to identify ProDOS III (and how much Apple /// RAM there
>>> was).
>>>
>>> If not for that I felt it necessary to keep a subset of Apple ][ ROM
>>> functionality resident, it would absolutely fit in the ///'s RAM
>>> without banking. It's that extra 2K that'll be a pinch. ;)
>>
>> But a 64k ProDOS program could reasonably assume _all_ of the Apple II
>> ROM was resident. I'm not sure you could/should get away with a subset.
>>
>
> Again that depends. ;)
>
> If I wasn't obvious elsewhere, that *subset* equals the portion that is
> shared between the ][ and ][+. AKA F800-FFFF. For a program to work
> the same on both the ][ and the ][+, it would have to assume that it
> couldn't rely on the contents of D000-F7FF - or alternatively have two
> sets of code depending on whether it ran on an Integer machine or one
> with FPBASIC. I would think the former is more likely.
>
> If just THAT part is available, it might be enough for something that
> uses the monitor ROM, but never touches BASIC.
It would cut out a wide swathe of ProDOS software that required 128k
(i.e. IIe/c/gs), but it would still be a fun experiment to see all that
could be enabled.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370982 is a reply to message #370452] |
Thu, 19 July 2018 21:19 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 10 July 2018 03:09:43 UTC+10, Steve Nickolas wrote:
> I've been thinking - and right now it's a little above my head, but with
> some musing, it might be doable.
>
> The idea is to create a reorganized implementation of ProDOS-8 that would
> contain a modified Apple ][ monitor from F800-FFFF to allow some programs
> to run unmodified on an Apple ///, in the so-called "Satan Mode",
> bootstrapping ProDOS from the SOS bootloader and thus retaining the
> ability to boot on both an Apple ][ and an Apple ///. (I say reorganized
> because F800-FFFF is used by ProDOS normally.)
Couldn't you create a thunking layer for SOS by replicating the ProDOS MLI Global page rather than porting the whole of ProDOS over ?
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370983 is a reply to message #370982] |
Thu, 19 July 2018 21:50 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 19 Jul 2018, mdj wrote:
> On Tuesday, 10 July 2018 03:09:43 UTC+10, Steve Nickolas wrote:
>> I've been thinking - and right now it's a little above my head, but with
>> some musing, it might be doable.
>>
>> The idea is to create a reorganized implementation of ProDOS-8 that would
>> contain a modified Apple ][ monitor from F800-FFFF to allow some programs
>> to run unmodified on an Apple ///, in the so-called "Satan Mode",
>> bootstrapping ProDOS from the SOS bootloader and thus retaining the
>> ability to boot on both an Apple ][ and an Apple ///. (I say reorganized
>> because F800-FFFF is used by ProDOS normally.)
>
> Couldn't you create a thunking layer for SOS by replicating the ProDOS MLI Global page rather than porting the whole of ProDOS over ?
>
>
Two problems with that.
First, SOS requires too much memory (it needs a bunch of lower memory plus
it dips *well* below C000), and second, I need F800-FFFF for the monitor
emulation.
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #370984 is a reply to message #370983] |
Thu, 19 July 2018 22:11 |
Rob Justice
Messages: 98
Registered: January 2013
Karma: 0
|
Member |
|
|
On Friday, July 20, 2018 at 11:51:01 AM UTC+10, Steve Nickolas wrote:
> On Thu, 19 Jul 2018, mdj wrote:
>
>> On Tuesday, 10 July 2018 03:09:43 UTC+10, Steve Nickolas wrote:
>>> I've been thinking - and right now it's a little above my head, but with
>>> some musing, it might be doable.
>>>
>>> The idea is to create a reorganized implementation of ProDOS-8 that would
>>> contain a modified Apple ][ monitor from F800-FFFF to allow some programs
>>> to run unmodified on an Apple ///, in the so-called "Satan Mode",
>>> bootstrapping ProDOS from the SOS bootloader and thus retaining the
>>> ability to boot on both an Apple ][ and an Apple ///. (I say reorganized
>>> because F800-FFFF is used by ProDOS normally.)
>>
>> Couldn't you create a thunking layer for SOS by replicating the ProDOS MLI Global page rather than porting the whole of ProDOS over ?
>>
>>
>
> Two problems with that.
>
> First, SOS requires too much memory (it needs a bunch of lower memory plus
> it dips *well* below C000), and second, I need F800-FFFF for the monitor
> emulation.
>
> -uso.
I have pondered squeezing SOS up to try and achieve that. It would need a change of a few things. One thought would be to remove the disk driver from the kernel code and load it in the normal drivers file. It would then need the loader to be be written to load the drivers file directly, rather than use the inbuilt disk driver. Quite a big change.
The other part that could be dropped from the SOS kernel is the inbuilt copy protection software routines. This would mean it would only run 'deprotected' sw and not original protected disks. I don't see this as to big an issue these days.
/Rob
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #371476 is a reply to message #370983] |
Tue, 31 July 2018 22:23 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Earlier today, I wrote an IPL in 256 bytes that will load (if it is the
first file on a disk) a DOS 3.3 file of type S at $2000 and run it.
Basically, that was progress toward THIS goal, even though it might not
seem to be.
I have 512 bytes to do this - and I don't need to reserve space for a
sanity check in case someone tries booting on a ][ - but I haven't yet put
my hands around the ProDOS root directory format yet in order to get the
information for a file of type whatever and name whatever in the root.
(It looks like a ROM function at F479 called "blockio" will be quite
helpful, while I was using a different ROM function, "rwts", at F000, with
the DOS 3.3 IPL.)
(Also, would $FF still be an appropriate filetype, since this IS going to
be ProDOS-compatible, or should I use $0C, or something yet other?)
Initially I'm going to just stick a graft on top of ProDOS-8 1.0.2 (which
supports a 48K mode), since I have yet to figure out how to relocate the
ProDOS code to build the way I want to.
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #371481 is a reply to message #371476] |
Tue, 31 July 2018 23:17 |
|
|
Originally posted by: John Brooks
On Tuesday, July 31, 2018 at 7:23:33 PM UTC-7, Steve Nickolas wrote:
> Earlier today, I wrote an IPL in 256 bytes that will load (if it is the
> first file on a disk) a DOS 3.3 file of type S at $2000 and run it.
> Basically, that was progress toward THIS goal, even though it might not
> seem to be.
>
> I have 512 bytes to do this - and I don't need to reserve space for a
> sanity check in case someone tries booting on a ][ - but I haven't yet put
> my hands around the ProDOS root directory format yet in order to get the
> information for a file of type whatever and name whatever in the root.
>
> (It looks like a ROM function at F479 called "blockio" will be quite
> helpful, while I was using a different ROM function, "rwts", at F000, with
> the DOS 3.3 IPL.)
>
> (Also, would $FF still be an appropriate filetype, since this IS going to
> be ProDOS-compatible, or should I use $0C, or something yet other?)
>
> Initially I'm going to just stick a graft on top of ProDOS-8 1.0.2 (which
> supports a 48K mode), since I have yet to figure out how to relocate the
> ProDOS code to build the way I want to.
>
> -uso.
The standard ProDOS boot block already detects the Apple /// and then jumps to an error message. Instead, you can have it load block 1 when booted on an Apple /// and load ProDOS (this was part of the initial ProDOS design).
The bigger problem is that ProDOS expects to load into the language card and has code that expects to swap LC banks and the ROM in and out. As far as I know, the /// can only swap $2000-$A000.
Making ProDOS running on the Apple /// will require a major rework of the ProDOS MLI and drivers.
-JB
@JBrooksBSI
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #371482 is a reply to message #371481] |
Tue, 31 July 2018 23:56 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 31 Jul 2018, John Brooks wrote:
> On Tuesday, July 31, 2018 at 7:23:33 PM UTC-7, Steve Nickolas wrote:
>> Earlier today, I wrote an IPL in 256 bytes that will load (if it is the
>> first file on a disk) a DOS 3.3 file of type S at $2000 and run it.
>> Basically, that was progress toward THIS goal, even though it might not
>> seem to be.
>>
>> I have 512 bytes to do this - and I don't need to reserve space for a
>> sanity check in case someone tries booting on a ][ - but I haven't yet put
>> my hands around the ProDOS root directory format yet in order to get the
>> information for a file of type whatever and name whatever in the root.
>>
>> (It looks like a ROM function at F479 called "blockio" will be quite
>> helpful, while I was using a different ROM function, "rwts", at F000, with
>> the DOS 3.3 IPL.)
>>
>> (Also, would $FF still be an appropriate filetype, since this IS going to
>> be ProDOS-compatible, or should I use $0C, or something yet other?)
>>
>> Initially I'm going to just stick a graft on top of ProDOS-8 1.0.2 (which
>> supports a 48K mode), since I have yet to figure out how to relocate the
>> ProDOS code to build the way I want to.
>>
>> -uso.
>
> The standard ProDOS boot block already detects the Apple /// and then
> jumps to an error message. Instead, you can have it load block 1 when
> booted on an Apple /// and load ProDOS (this was part of the initial
> ProDOS design).
I'm assuming the latter, since that's what the official bootstrap did, but
I'd be replacing block 1 with a new one.
(I use the same trick to load DOS 3.3 on an Apple /// from a disk which is
capable of loading DOS 3.3 on an Apple ]> The bigger problem is that ProDOS expects to load into the language card [/color]
> and has code that expects to swap LC banks and the ROM in and out. As
> far as I know, the /// can only swap $2000-$A000.
I'm including the Apple ][ ROM but only F800-FFFF of it. That means while
I'll have to move code around, I'll have what I need by setting bits of
FFDF:
* setting the $01 bit enables the boot ROM (which seems to have a pretty
complete RWTS at F000 - hence my 256 byte DOS 3.3 IPL)
* setting the $08 bit locks the C000-FFFF memory, unsetting it makes it
writable, so this would be part of replacing the LC access on the ][
* setting the $40 bit makes the Cxxx area work like on the ]> Making ProDOS running on the Apple /// will require a major rework of [/color]
> the ProDOS MLI and drivers.
I'm not sure it's as major as it looks at first. The only catch is that
one would be limited to software that would run on a 64K ][+ *or* a 64K
*integer* ][, as neither BASIC would be resident.
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #371483 is a reply to message #371482] |
Wed, 01 August 2018 00:13 |
|
|
Originally posted by: John Brooks
On Tuesday, July 31, 2018 at 8:56:55 PM UTC-7, Steve Nickolas wrote:
> On Tue, 31 Jul 2018, John Brooks wrote:
>
>> On Tuesday, July 31, 2018 at 7:23:33 PM UTC-7, Steve Nickolas wrote:
>>> Earlier today, I wrote an IPL in 256 bytes that will load (if it is the
>>> first file on a disk) a DOS 3.3 file of type S at $2000 and run it.
>>> Basically, that was progress toward THIS goal, even though it might not
>>> seem to be.
>>>
>>> I have 512 bytes to do this - and I don't need to reserve space for a
>>> sanity check in case someone tries booting on a ][ - but I haven't yet put
>>> my hands around the ProDOS root directory format yet in order to get the
>>> information for a file of type whatever and name whatever in the root.
>>>
>>> (It looks like a ROM function at F479 called "blockio" will be quite
>>> helpful, while I was using a different ROM function, "rwts", at F000, with
>>> the DOS 3.3 IPL.)
>>>
>>> (Also, would $FF still be an appropriate filetype, since this IS going to
>>> be ProDOS-compatible, or should I use $0C, or something yet other?)
>>>
>>> Initially I'm going to just stick a graft on top of ProDOS-8 1.0.2 (which
>>> supports a 48K mode), since I have yet to figure out how to relocate the
>>> ProDOS code to build the way I want to.
>>>
>>> -uso.
>>
>> The standard ProDOS boot block already detects the Apple /// and then
>> jumps to an error message. Instead, you can have it load block 1 when
>> booted on an Apple /// and load ProDOS (this was part of the initial
>> ProDOS design).
>
> I'm assuming the latter, since that's what the official bootstrap did, but
> I'd be replacing block 1 with a new one.
>
> (I use the same trick to load DOS 3.3 on an Apple /// from a disk which is
> capable of loading DOS 3.3 on an Apple ][. In fact, I based my code on
> the ProDOS bootsector.)
>
>> The bigger problem is that ProDOS expects to load into the language card
>> and has code that expects to swap LC banks and the ROM in and out. As
>> far as I know, the /// can only swap $2000-$A000.
>
> I'm including the Apple ][ ROM but only F800-FFFF of it. That means while
> I'll have to move code around, I'll have what I need by setting bits of
> FFDF:
>
> * setting the $01 bit enables the boot ROM (which seems to have a pretty
> complete RWTS at F000 - hence my 256 byte DOS 3.3 IPL)
> * setting the $08 bit locks the C000-FFFF memory, unsetting it makes it
> writable, so this would be part of replacing the LC access on the ][
> * setting the $40 bit makes the Cxxx area work like on the ][. but
> unsetting it reveals the full 4K of RAM underneath it - which will
> provide the necessary space for anything shoved out by the relocation,
> as well as for the Selector.
>
>> Making ProDOS running on the Apple /// will require a major rework of
>> the ProDOS MLI and drivers.
>
> I'm not sure it's as major as it looks at first. The only catch is that
> one would be limited to software that would run on a 64K ][+ *or* a 64K
> *integer* ][, as neither BASIC would be resident.
>
> -uso.
$F800-$FFFF is heavily used (MLI funcs, helper funcs, lots of vars, smartport handling, drivers) and is touched by code throughout ProDOS.
I'm sure it's possible to move $F800-$FFFF to $C000, but I would expect it to be orders of magnitude more difficult than the DOS 3.3 IPL (and I'm glad it's not me <grin>).
Good luck!
-JB
@JBrooksBSI
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #372085 is a reply to message #371483] |
Sun, 12 August 2018 21:43 |
Rob Justice
Messages: 98
Registered: January 2013
Karma: 0
|
Member |
|
|
On Wednesday, August 1, 2018 at 2:13:29 PM UTC+10, John Brooks wrote:
> On Tuesday, July 31, 2018 at 8:56:55 PM UTC-7, Steve Nickolas wrote:
>> On Tue, 31 Jul 2018, John Brooks wrote:
>>
>>> On Tuesday, July 31, 2018 at 7:23:33 PM UTC-7, Steve Nickolas wrote:
>>>> Earlier today, I wrote an IPL in 256 bytes that will load (if it is the
>>>> first file on a disk) a DOS 3.3 file of type S at $2000 and run it.
>>>> Basically, that was progress toward THIS goal, even though it might not
>>>> seem to be.
>>>>
>>>> I have 512 bytes to do this - and I don't need to reserve space for a
>>>> sanity check in case someone tries booting on a ][ - but I haven't yet put
>>>> my hands around the ProDOS root directory format yet in order to get the
>>>> information for a file of type whatever and name whatever in the root.
>>>>
>>>> (It looks like a ROM function at F479 called "blockio" will be quite
>>>> helpful, while I was using a different ROM function, "rwts", at F000, with
>>>> the DOS 3.3 IPL.)
>>>>
>>>> (Also, would $FF still be an appropriate filetype, since this IS going to
>>>> be ProDOS-compatible, or should I use $0C, or something yet other?)
>>>>
>>>> Initially I'm going to just stick a graft on top of ProDOS-8 1.0.2 (which
>>>> supports a 48K mode), since I have yet to figure out how to relocate the
>>>> ProDOS code to build the way I want to.
>>>>
>>>> -uso.
>>>
>>> The standard ProDOS boot block already detects the Apple /// and then
>>> jumps to an error message. Instead, you can have it load block 1 when
>>> booted on an Apple /// and load ProDOS (this was part of the initial
>>> ProDOS design).
>>
>> I'm assuming the latter, since that's what the official bootstrap did, but
>> I'd be replacing block 1 with a new one.
>>
>> (I use the same trick to load DOS 3.3 on an Apple /// from a disk which is
>> capable of loading DOS 3.3 on an Apple ][. In fact, I based my code on
>> the ProDOS bootsector.)
>>
>>> The bigger problem is that ProDOS expects to load into the language card
>>> and has code that expects to swap LC banks and the ROM in and out. As
>>> far as I know, the /// can only swap $2000-$A000.
>>
>> I'm including the Apple ][ ROM but only F800-FFFF of it. That means while
>> I'll have to move code around, I'll have what I need by setting bits of
>> FFDF:
>>
>> * setting the $01 bit enables the boot ROM (which seems to have a pretty
>> complete RWTS at F000 - hence my 256 byte DOS 3.3 IPL)
>> * setting the $08 bit locks the C000-FFFF memory, unsetting it makes it
>> writable, so this would be part of replacing the LC access on the ][
>> * setting the $40 bit makes the Cxxx area work like on the ][. but
>> unsetting it reveals the full 4K of RAM underneath it - which will
>> provide the necessary space for anything shoved out by the relocation,
>> as well as for the Selector.
>>
>>> Making ProDOS running on the Apple /// will require a major rework of
>>> the ProDOS MLI and drivers.
>>
>> I'm not sure it's as major as it looks at first. The only catch is that
>> one would be limited to software that would run on a 64K ][+ *or* a 64K
>> *integer* ][, as neither BASIC would be resident.
>>
>> -uso.
>
> $F800-$FFFF is heavily used (MLI funcs, helper funcs, lots of vars, smartport handling, drivers) and is touched by code throughout ProDOS.
>
> I'm sure it's possible to move $F800-$FFFF to $C000, but I would expect it to be orders of magnitude more difficult than the DOS 3.3 IPL (and I'm glad it's not me <grin>).
>
> Good luck!
> -JB
> @JBrooksBSI
Is it just the Prodos code that uses the $F800-FFFF, or is it the Programs that run under Prodos using that code? or both?
One other option is the A3 has hardware support for another 4k of rom to be paged in. This would require a rom swap to an 8k rom, but could be a different approach.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #372089 is a reply to message #372085] |
Mon, 13 August 2018 01:34 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 12 Aug 2018, Rob Justice wrote:
> Is it just the Prodos code that uses the $F800-FFFF, or is it the
> Programs that run under Prodos using that code? or both?
ProDOS-8 documentations tells programs, iirc, not to touch the language
card, and that the only officially documented addresses are the BFxx page.
That's why I feel it's safe to relocate the hell out of stuff. ;)
-uso.
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #372148 is a reply to message #372089] |
Mon, 13 August 2018 18:33 |
|
|
Originally posted by: John Brooks
On Sunday, August 12, 2018 at 10:34:56 PM UTC-7, Steve Nickolas wrote:
> On Sun, 12 Aug 2018, Rob Justice wrote:
>
>> Is it just the Prodos code that uses the $F800-FFFF, or is it the
>> Programs that run under Prodos using that code? or both?
>
> ProDOS-8 documentations tells programs, iirc, not to touch the language
> card, and that the only officially documented addresses are the BFxx page.
>
> That's why I feel it's safe to relocate the hell out of stuff. ;)
>
> -uso.
ProDOS uses $F800-$FFFF, and Apple II programs also expect to use the monitor routines at $F800-$FFFF.
Yes, in theory all accesses to ProDOS internals at $F800-$FFFF should be done by the ProDOS loader and other ProDOS internal subsystems which can be relocated.
On the GS, the Finder and GS/OS access fixed ProDOS locations in the $F800-$FFFF range in order to patch the quit handler. They also change the loader/startup sequence when launching P8 under GS/OS in order to run 8-bit apps from the Finder.
-JB
@JBrooksBSI
|
|
|
|
| Re: ProDOS - 64K ProDOS-8 on a ///? [message #372168 is a reply to message #372148] |
Mon, 13 August 2018 21:18 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 13 Aug 2018, John Brooks wrote:
> ProDOS uses $F800-$FFFF, and Apple II programs also expect to use the
> monitor routines at $F800-$FFFF.
>
> Yes, in theory all accesses to ProDOS internals at $F800-$FFFF should be
> done by the ProDOS loader and other ProDOS internal subsystems which can
> be relocated.
>
> On the GS, the Finder and GS/OS access fixed ProDOS locations in the
> $F800-$FFFF range in order to patch the quit handler. They also change
> the loader/startup sequence when launching P8 under GS/OS in order to
> run 8-bit apps from the Finder.
Well, dirty programs and IIgs programs won't be able to work ;)
But well-behaved ones should.
-uso.
|
|
|
|
Members
Search
Help
Register
Login
Home
