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

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

Prodos8 2.0.3 info

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

Contents

  Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-07-28 20:17 -0700
    Re: Prodos8 2.0.3 info Michael J. Mahon <mjmahon@aol.com> - 2016-07-31 00:07 -0500
      Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-07-30 22:26 -0700
        Re: Prodos8 2.0.3 info Oliver Schmidt <ol.sc@web.de> - 2016-07-31 09:26 +0000
          Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-07-31 08:25 -0700
            Re: Prodos8 2.0.3 info dempson@actrix.gen.nz (David Empson) - 2016-08-01 09:05 +1200
              Re: Prodos8 2.0.3 info Antoine Vignau <antoine.vignau@laposte.net> - 2016-07-31 22:56 -0700
              Re: Prodos8 2.0.3 info Oliver Schmidt <ol.sc@web.de> - 2016-08-01 12:29 +0000
                Re: Prodos8 2.0.3 info Antoine Vignau <antoine.vignau@laposte.net> - 2016-08-01 08:45 -0700
                Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-09 20:43 -0700
                  Re: Prodos8 2.0.3 info Antoine Vignau <antoine.vignau@laposte.net> - 2016-08-09 22:50 -0700
                  Re: Prodos8 2.0.3 info Oliver Schmidt <ol.sc@web.de> - 2016-08-10 07:12 -0700
                    Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-10 08:52 -0700
                      Re: Prodos8 2.0.3 info D Finnigan <dog_cow@macgui.com> - 2016-08-10 16:12 +0000
                        Re: Prodos8 2.0.3 info gids.rs@sasktel.net - 2016-08-10 22:27 -0700
                      Re: Prodos8 2.0.3 info gids.rs@sasktel.net - 2016-08-10 22:35 -0700
                  Re: Prodos8 2.0.3 info Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 08:31 -0700
                    Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-11 10:32 -0700
                      Re: Prodos8 2.0.3 info Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 12:35 -0700
                        Re: Prodos8 2.0.3 info qkumba <peter.ferrie@gmail.com> - 2016-08-12 09:24 -0700
                          Re: Prodos8 2.0.3 info Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-12 10:08 -0700
    Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-13 21:37 -0700
      Re: Prodos8 2.0.3 info Antoine Vignau <antoine.vignau@laposte.net> - 2016-08-14 15:32 -0700
      Re: Prodos8 2.0.3 info Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-15 09:10 -0700
        Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-15 13:41 -0700
          Re: Prodos8 2.0.3 info Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-16 18:19 -0700
            Re: Prodos8 2.0.3 info geoff body <gbody4@bigpond.com> - 2016-08-17 07:49 -0700
              Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-17 10:04 -0700
      Re: Prodos8 2.0.3 info David Schmidt <schmidtd@my-deja.com> - 2016-08-15 13:45 -0400
        Re: Prodos8 2.0.3 info John Brooks <jbrooks@blueshiftinc.com> - 2016-08-15 13:49 -0700
          Re: Prodos8 2.0.3 info David Schmidt <schmidtd@my-deja.com> - 2016-08-15 17:36 -0400
          Re: Prodos8 2.0.3 info Oliver Schmidt <ol.sc@web.de> - 2016-08-16 09:56 +0000

Page 1 of 2  [1] 2  Next page →

#2851 — Prodos8 2.0.3 info

While looking at ProDOS8 2.0.3 to see how hard it would be to remove the 65c02 opcode dependencies, I made notes and a rough page-by-page memory map.

In case this is useful to other Apple II programmers, here are my notes & memory map:

Prodos8 v2.0.3

0/D000 (LC bank 2)
 Bank 2 ID byte: used to determine which LC bank is active
 <255 unused bytes>

0/D100 - 0/D3FF (LC bank 2)
 Quit code: One of 3 possible quit routines, 40col for II & II+, 80col for //e & //c, or GSOS restore. All 3 quit handlers are loaded at boot and only one of the 3 is moved here. 768 bytes used, 2*768=1.5K discarded at boot.

0/D400 - 0/DFFF (LC bank 2)
 <3072 bytes unused>


0/D000 (LC Bank 1)
 Disk II read/write block. Calls RWTS twice as 1 block = 2 sectors
 Disk II RWTS

0/D100
 Disk II seek
 Disk II 6&2 decode table

0/D200
 Disk II 6&2 encode table

0/D300
 Buffer for 2-bit-per-byte data during encode/decode
 Misc Disk II & RWTS vars
 Step phase timing table
 Millisecond wait routine for spin-up & stepping
 Read sector address

0/D400
 Read sector data
 Set track
 Check drive
 
0/D500
 Write sector

0/D600
 6&2 pre-nibblize
 Reset stepper phases
 Convert block to Trk/Sec
 Smartport status buffer
 Smartport unit numbers buffer

0/D700
 Pathname buffer
 Read clock routine: Thunderclock & IIGS clock driver loaded at boot. One moved here
 <64 bytes unused>

0/D800
 FCB: File Control Block buffer

0/D900
 VCB: Volume Control Block buffer

0/DA00
 Volume bit map block 1st half

0/DB00
 Volume bit map block 2nd half

0/DC00
 Misc block buffer 1st half

0/DD00
 Misc block buffer 2nd half

0/DE00
 Main entry to the P8 MLI
 Clean up and exit MLI back to caller
 Call a specified device driver

0/DF00
 Init IRQ manager
 IRQ received entry point
 Dispatch IRQ to one of 4 user installed handlers
 Misc IRQ-related buffers & vars

0/E000
 MLI Error handler
 System death handler
 Call a device driver or the file manager based on the MLI command number

0/E100
 Set Prefix
 Get Prefix
 Find FCB

0/E200
 Check if device is online

0/E300
 Create a file

0/E400
 Create a file
 Touch date & time on a file

0/E500
 Touch date & time on all parent dirs of a file
 Find a file
 
0/E600
 Find a file

0/E700
 Find a file

0/E800
 Find a file
 Find a VCB
 Mount a new device in a VCB

0/E900
 Test for a duplicate volume
 Found a duplicate volume
 Count free blocks in a volume bit map

0/EA00
 Free up blocks from the volume bit map
 Allocate 1 block in the  volume bit map

0/EB00
 Allocate 1 block in the volume bit map
 Write the volume bit map back to the device

0/EC00
 Set file mark
 Seek into a file, traversing seed, sapling, or tree block lists

0/ED00
 Seek into a file, traversing seed, sapling, or tree block lists
 Seek into a directory

0/EE00
 Read or Write a block from a file
 Update FCB after read/write
 Open file

0/EF00
 Open file
 Open directory
 Read from file

0/F000
 Read from file

0/F100
 Read a partial block from a file
 Read a directory
 Calculate file mark

0/F200
 Reset file EOF after a write error
 Adjust EOF after a write
 Write to a file
 Write to a sapling file
 Write to a tree file

0/F300
 Write a partial block
 Handle allocating blocks to a tree
 Handle allocating blocks to a sapling

0/F400
 Allocate a block for writing
 Test for write protect
 Close file
 Flush file

0/F500
 Flush file
 Update EOF
 Report an error
 Set EOF

0/F600
 Set EOF
 Adjust an FCB

0/F700
 Get EOF
 Newline
 Get Info
 Set Info
 Rename

0/F800
 Rename

0/F900
 Rename
 Delete a file
 Delete a tree file
 Clear a directory file entry
 Update the free block count on the device
 Delete a directory

0/FA00
 Delete a directory
 Remove blocks from a tree
 Free blocks from a seedling
 Free blocks from a sapling
 Free blocks from a tree

0/FB00
 Free blocks from a tree
 Reduce a tree to a sapling, or a sapling to a seedling
 Free 1 block
 Allocate a 1k user buffer

0/FC00
 Allocate a 1k user buffer
 Get 1k user buffer
 Free 1k user buffer
 Allocate 1 page in mem bitmap
 Get file buffer
 Set file buffer
 Copy quit handler from LC bank 2 to 0/1000 and call it

0/FD00
 Remap smartport devices to unuse slot/drive locations
 Smartport remap data
 MLI data & buffers

0/FE00
 MLI data & buffers

0/FF00
 /RAM driver entry point
 /RAM copy & call functions
 IRQ intercept routine
 6502 vectors

1/0200
 /RAM driver
 /RAM command handler
 /RAM format
 /RAM block write
 /RAM block read

1/0300
 /RAM block read
 Clear block for unallocated blocks
 Construct volume bit map from partial /RAM bitmap

-JB
twitter: @JBrooksBSI

[toc] | [next] | [standalone]

#2852

John Brooks <jbrooks@blueshiftinc.com> wrote:
> 
> While looking at ProDOS8 2.0.3 to see how hard it would be to remove the
> 65c02 opcode dependencies, I made notes and a rough page-by-page memory map.
> 
> In case this is useful to other Apple II programmers, here are my notes & memory map:
> 
> Prodos8 v2.0.3
> 
> 0/D000 (LC bank 2)
>  Bank 2 ID byte: used to determine which LC bank is active
>  <255 unused bytes>
> 
> 0/D100 - 0/D3FF (LC bank 2)
>  Quit code: One of 3 possible quit routines, 40col for II & II+, 80col
> for //e & //c, or GSOS restore. All 3 quit handlers are loaded at boot
> and only one of the 3 is moved here. 768 bytes used, 2*768=1.5K discarded at boot.
> 
> 0/D400 - 0/DFFF (LC bank 2)
>  <3072 bytes unused>
> 
> 
> 0/D000 (LC Bank 1)
>  Disk II read/write block. Calls RWTS twice as 1 block = 2 sectors
>  Disk II RWTS
> 
> 0/D100
>  Disk II seek
>  Disk II 6&2 decode table
> 
> 0/D200
>  Disk II 6&2 encode table
> 
> 0/D300
>  Buffer for 2-bit-per-byte data during encode/decode
>  Misc Disk II & RWTS vars
>  Step phase timing table
>  Millisecond wait routine for spin-up & stepping
>  Read sector address
> 
> 0/D400
>  Read sector data
>  Set track
>  Check drive
>  
> 0/D500
>  Write sector
> 
> 0/D600
>  6&2 pre-nibblize
>  Reset stepper phases
>  Convert block to Trk/Sec
>  Smartport status buffer
>  Smartport unit numbers buffer
> 
> 0/D700
>  Pathname buffer
>  Read clock routine: Thunderclock & IIGS clock driver loaded at boot. One moved here
>  <64 bytes unused>
> 
> 0/D800
>  FCB: File Control Block buffer
> 
> 0/D900
>  VCB: Volume Control Block buffer
> 
> 0/DA00
>  Volume bit map block 1st half
> 
> 0/DB00
>  Volume bit map block 2nd half
> 
> 0/DC00
>  Misc block buffer 1st half
> 
> 0/DD00
>  Misc block buffer 2nd half
> 
> 0/DE00
>  Main entry to the P8 MLI
>  Clean up and exit MLI back to caller
>  Call a specified device driver
> 
> 0/DF00
>  Init IRQ manager
>  IRQ received entry point
>  Dispatch IRQ to one of 4 user installed handlers
>  Misc IRQ-related buffers & vars
> 
> 0/E000
>  MLI Error handler
>  System death handler
>  Call a device driver or the file manager based on the MLI command number
> 
> 0/E100
>  Set Prefix
>  Get Prefix
>  Find FCB
> 
> 0/E200
>  Check if device is online
> 
> 0/E300
>  Create a file
> 
> 0/E400
>  Create a file
>  Touch date & time on a file
> 
> 0/E500
>  Touch date & time on all parent dirs of a file
>  Find a file
>  
> 0/E600
>  Find a file
> 
> 0/E700
>  Find a file
> 
> 0/E800
>  Find a file
>  Find a VCB
>  Mount a new device in a VCB
> 
> 0/E900
>  Test for a duplicate volume
>  Found a duplicate volume
>  Count free blocks in a volume bit map
> 
> 0/EA00
>  Free up blocks from the volume bit map
>  Allocate 1 block in the  volume bit map
> 
> 0/EB00
>  Allocate 1 block in the volume bit map
>  Write the volume bit map back to the device
> 
> 0/EC00
>  Set file mark
>  Seek into a file, traversing seed, sapling, or tree block lists
> 
> 0/ED00
>  Seek into a file, traversing seed, sapling, or tree block lists
>  Seek into a directory
> 
> 0/EE00
>  Read or Write a block from a file
>  Update FCB after read/write
>  Open file
> 
> 0/EF00
>  Open file
>  Open directory
>  Read from file
> 
> 0/F000
>  Read from file
> 
> 0/F100
>  Read a partial block from a file
>  Read a directory
>  Calculate file mark
> 
> 0/F200
>  Reset file EOF after a write error
>  Adjust EOF after a write
>  Write to a file
>  Write to a sapling file
>  Write to a tree file
> 
> 0/F300
>  Write a partial block
>  Handle allocating blocks to a tree
>  Handle allocating blocks to a sapling
> 
> 0/F400
>  Allocate a block for writing
>  Test for write protect
>  Close file
>  Flush file
> 
> 0/F500
>  Flush file
>  Update EOF
>  Report an error
>  Set EOF
> 
> 0/F600
>  Set EOF
>  Adjust an FCB
> 
> 0/F700
>  Get EOF
>  Newline
>  Get Info
>  Set Info
>  Rename
> 
> 0/F800
>  Rename
> 
> 0/F900
>  Rename
>  Delete a file
>  Delete a tree file
>  Clear a directory file entry
>  Update the free block count on the device
>  Delete a directory
> 
> 0/FA00
>  Delete a directory
>  Remove blocks from a tree
>  Free blocks from a seedling
>  Free blocks from a sapling
>  Free blocks from a tree
> 
> 0/FB00
>  Free blocks from a tree
>  Reduce a tree to a sapling, or a sapling to a seedling
>  Free 1 block
>  Allocate a 1k user buffer
> 
> 0/FC00
>  Allocate a 1k user buffer
>  Get 1k user buffer
>  Free 1k user buffer
>  Allocate 1 page in mem bitmap
>  Get file buffer
>  Set file buffer
>  Copy quit handler from LC bank 2 to 0/1000 and call it
> 
> 0/FD00
>  Remap smartport devices to unuse slot/drive locations
>  Smartport remap data
>  MLI data & buffers
> 
> 0/FE00
>  MLI data & buffers
> 
> 0/FF00
>  /RAM driver entry point
>  /RAM copy & call functions
>  IRQ intercept routine
>  6502 vectors
> 
> 1/0200
>  /RAM driver
>  /RAM command handler
>  /RAM format
>  /RAM block write
>  /RAM block read
> 
> 1/0300
>  /RAM block read
>  Clear block for unallocated blocks
>  Construct volume bit map from partial /RAM bitmap
> 
> -JB
> twitter: @JBrooksBSI
> 

I did a quick sampling of BRA branches, and more than half of them were
trivially replaceable by conditional branches where a testable status bit
is in a known state--as in:
   BNE <foo>
   BEQ <bar>      ; (always)

The rest are following JSRs, so it's not clear whether any condition can be
counted on. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2853

On Saturday, July 30, 2016 at 10:07:33 PM UTC-7, mjm...@aol.com wrote:
> John Brooks wrote:
> > 
> > While looking at ProDOS8 2.0.3 to see how hard it would be to remove the
> > 65c02 opcode dependencies, I made notes and a rough page-by-page memory map.
> > 
> > In case this is useful to other Apple II programmers, here are my notes & memory map:
> > 
> > Prodos8 v2.0.3
> > 
> > 0/D000 (LC bank 2)
> >  Bank 2 ID byte: used to determine which LC bank is active
> >  <255 unused bytes>
> > 
> > 0/D100 - 0/D3FF (LC bank 2)
> >  Quit code: One of 3 possible quit routines, 40col for II & II+, 80col
> > for //e & //c, or GSOS restore. All 3 quit handlers are loaded at boot
> > and only one of the 3 is moved here. 768 bytes used, 2*768=1.5K discarded at boot.
> > 
> > 0/D400 - 0/DFFF (LC bank 2)
> >  <3072 bytes unused>
> > 
> > 
> > 0/D000 (LC Bank 1)
> >  Disk II read/write block. Calls RWTS twice as 1 block = 2 sectors
> >  Disk II RWTS
> > 
> > 0/D100
> >  Disk II seek
> >  Disk II 6&2 decode table
> > 
> > 0/D200
> >  Disk II 6&2 encode table
> > 
> > 0/D300
> >  Buffer for 2-bit-per-byte data during encode/decode
> >  Misc Disk II & RWTS vars
> >  Step phase timing table
> >  Millisecond wait routine for spin-up & stepping
> >  Read sector address
> > 
> > 0/D400
> >  Read sector data
> >  Set track
> >  Check drive
> >  
> > 0/D500
> >  Write sector
> > 
> > 0/D600
> >  6&2 pre-nibblize
> >  Reset stepper phases
> >  Convert block to Trk/Sec
> >  Smartport status buffer
> >  Smartport unit numbers buffer
> > 
> > 0/D700
> >  Pathname buffer
> >  Read clock routine: Thunderclock & IIGS clock driver loaded at boot. One moved here
> >  <64 bytes unused>
> > 
> > 0/D800
> >  FCB: File Control Block buffer
> > 
> > 0/D900
> >  VCB: Volume Control Block buffer
> > 
> > 0/DA00
> >  Volume bit map block 1st half
> > 
> > 0/DB00
> >  Volume bit map block 2nd half
> > 
> > 0/DC00
> >  Misc block buffer 1st half
> > 
> > 0/DD00
> >  Misc block buffer 2nd half
> > 
> > 0/DE00
> >  Main entry to the P8 MLI
> >  Clean up and exit MLI back to caller
> >  Call a specified device driver
> > 
> > 0/DF00
> >  Init IRQ manager
> >  IRQ received entry point
> >  Dispatch IRQ to one of 4 user installed handlers
> >  Misc IRQ-related buffers & vars
> > 
> > 0/E000
> >  MLI Error handler
> >  System death handler
> >  Call a device driver or the file manager based on the MLI command number
> > 
> > 0/E100
> >  Set Prefix
> >  Get Prefix
> >  Find FCB
> > 
> > 0/E200
> >  Check if device is online
> > 
> > 0/E300
> >  Create a file
> > 
> > 0/E400
> >  Create a file
> >  Touch date & time on a file
> > 
> > 0/E500
> >  Touch date & time on all parent dirs of a file
> >  Find a file
> >  
> > 0/E600
> >  Find a file
> > 
> > 0/E700
> >  Find a file
> > 
> > 0/E800
> >  Find a file
> >  Find a VCB
> >  Mount a new device in a VCB
> > 
> > 0/E900
> >  Test for a duplicate volume
> >  Found a duplicate volume
> >  Count free blocks in a volume bit map
> > 
> > 0/EA00
> >  Free up blocks from the volume bit map
> >  Allocate 1 block in the  volume bit map
> > 
> > 0/EB00
> >  Allocate 1 block in the volume bit map
> >  Write the volume bit map back to the device
> > 
> > 0/EC00
> >  Set file mark
> >  Seek into a file, traversing seed, sapling, or tree block lists
> > 
> > 0/ED00
> >  Seek into a file, traversing seed, sapling, or tree block lists
> >  Seek into a directory
> > 
> > 0/EE00
> >  Read or Write a block from a file
> >  Update FCB after read/write
> >  Open file
> > 
> > 0/EF00
> >  Open file
> >  Open directory
> >  Read from file
> > 
> > 0/F000
> >  Read from file
> > 
> > 0/F100
> >  Read a partial block from a file
> >  Read a directory
> >  Calculate file mark
> > 
> > 0/F200
> >  Reset file EOF after a write error
> >  Adjust EOF after a write
> >  Write to a file
> >  Write to a sapling file
> >  Write to a tree file
> > 
> > 0/F300
> >  Write a partial block
> >  Handle allocating blocks to a tree
> >  Handle allocating blocks to a sapling
> > 
> > 0/F400
> >  Allocate a block for writing
> >  Test for write protect
> >  Close file
> >  Flush file
> > 
> > 0/F500
> >  Flush file
> >  Update EOF
> >  Report an error
> >  Set EOF
> > 
> > 0/F600
> >  Set EOF
> >  Adjust an FCB
> > 
> > 0/F700
> >  Get EOF
> >  Newline
> >  Get Info
> >  Set Info
> >  Rename
> > 
> > 0/F800
> >  Rename
> > 
> > 0/F900
> >  Rename
> >  Delete a file
> >  Delete a tree file
> >  Clear a directory file entry
> >  Update the free block count on the device
> >  Delete a directory
> > 
> > 0/FA00
> >  Delete a directory
> >  Remove blocks from a tree
> >  Free blocks from a seedling
> >  Free blocks from a sapling
> >  Free blocks from a tree
> > 
> > 0/FB00
> >  Free blocks from a tree
> >  Reduce a tree to a sapling, or a sapling to a seedling
> >  Free 1 block
> >  Allocate a 1k user buffer
> > 
> > 0/FC00
> >  Allocate a 1k user buffer
> >  Get 1k user buffer
> >  Free 1k user buffer
> >  Allocate 1 page in mem bitmap
> >  Get file buffer
> >  Set file buffer
> >  Copy quit handler from LC bank 2 to 0/1000 and call it
> > 
> > 0/FD00
> >  Remap smartport devices to unuse slot/drive locations
> >  Smartport remap data
> >  MLI data & buffers
> > 
> > 0/FE00
> >  MLI data & buffers
> > 
> > 0/FF00
> >  /RAM driver entry point
> >  /RAM copy & call functions
> >  IRQ intercept routine
> >  6502 vectors
> > 
> > 1/0200
> >  /RAM driver
> >  /RAM command handler
> >  /RAM format
> >  /RAM block write
> >  /RAM block read
> > 
> > 1/0300
> >  /RAM block read
> >  Clear block for unallocated blocks
> >  Construct volume bit map from partial /RAM bitmap
> > 
> > -JB
> > twitter: @JBrooksBSI
> > 
> 
> I did a quick sampling of BRA branches, and more than half of them were
> trivially replaceable by conditional branches where a testable status bit
> is in a known state--as in:
>    BNE <foo>
>    BEQ <bar>      ; (always)
> 
> The rest are following JSRs, so it's not clear whether any condition can be
> counted on. 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Good!

I'm looking into gathering up all the smartport routines and variables around $FD00 and moving them to LC bank 2. That should free up about 100 bytes. I'll still need to find another 100 bytes or so to make enough space to revert all the 65c02 changes and get us to a universal Prodos8.

Fingers crossed.

-JB

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

#2854

Hi John,

> I'm looking into gathering up all the smartport routines and variables
> around $FD00 and moving them to LC bank 2.

I presume you're talking about the first page of LC bank 2 (before the quit
code) - correct?

The 3k behind the quit code tend to be used by programs.

There are even programs saving the quit code (i.e. to disk) and using the
whole LC bank 2 for own purposes - and loading the quit code back just
before calling MLI quit...

Regards,
Oliver

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

#2855

On Sunday, July 31, 2016 at 2:26:04 AM UTC-7, Oliver Schmidt wrote:
> Hi John,
> 
> > I'm looking into gathering up all the smartport routines and variables
> > around $FD00 and moving them to LC bank 2.
> 
> I presume you're talking about the first page of LC bank 2 (before the quit
> code) - correct?
> 
> The 3k behind the quit code tend to be used by programs.
> 
> There are even programs saving the quit code (i.e. to disk) and using the
> whole LC bank 2 for own purposes - and loading the quit code back just
> before calling MLI quit...
> 
> Regards,
> Oliver

Yes I'm currently targeting moving code to LC bank 2 $D001-D0FF which I hope will free enough space in the main LC.

I'd be very interested in a list of programs which use LC bank 2 $D400-$DFFF as there may be better ways to have drivers and other P8 add-ons use memory more effectively than what we have now.

-JB
twitter: @JBrooksBSI

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

#2856

John Brooks <jbrooks@blueshiftinc.com> wrote:

> On Sunday, July 31, 2016 at 2:26:04 AM UTC-7, Oliver Schmidt wrote:
> > Hi John,
> > 
> > > I'm looking into gathering up all the smartport routines and variables
> > > around $FD00 and moving them to LC bank 2.
> > 
> > I presume you're talking about the first page of LC bank 2 (before the quit
> > code) - correct?
> > 
> > The 3k behind the quit code tend to be used by programs.
> > 
> > There are even programs saving the quit code (i.e. to disk) and using the
> > whole LC bank 2 for own purposes - and loading the quit code back just
> > before calling MLI quit...
> > 
> > Regards,
> > Oliver
> 
> Yes I'm currently targeting moving code to LC bank 2 $D001-D0FF which I
> hope will free enough space in the main LC.

The $D000-$D0FF page in the same bank as the quit code is listed in the
ProDOS-8 Technical Reference as free for application use, so ProDOS
cannot use it itself. Any SYS file is allowed to use it at any time
without considering what might be there, and has been able to do so
since ProDOS was introduced.

> I'd be very interested in a list of programs which use LC bank 2
> $D400-$DFFF as there may be better ways to have drivers and other P8
> add-ons use memory more effectively than what we have now.

That area is reserved for "other" use (not application, not ProDOS). It
isn't clearly explained why this reservation exists.

Speculation: it may have been originally reserved so Apple could expand
ProDOS as required, but because some applications broke the rules and
used it, this became impossible without breaking too much software. It
might have still been used by the system in some situations (e.g. for
temporary storage which was saved, modified and restored while
interrupts were locked out).

-- 
David Empson
dempson@actrix.gen.nz

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

#2857

GS/OS usage maybe ;-)

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

#2858

Hi,

>>>> I'm looking into gathering up all the smartport routines and variables
>>>> around $FD00 and moving them to LC bank 2.

>>> The 3k behind the quit code tend to be used by programs.

>> Yes I'm currently targeting moving code to LC bank 2 $D001-D0FF which I
>> hope will free enough space in the main LC.

> The $D000-$D0FF page in the same bank as the quit code is listed in the
> ProDOS-8 Technical Reference as free for application use, so ProDOS
> cannot use it itself. 

Maybe two things worth to add here:

- From all I know ProDOS saves $D000 before using it to detect language
card settings and restores it afterwards. So at least from "outside of
ProDOS" there's no reason to treat this byte differently from the next 255
bytes.

- The official ProDOS docs seem to imply that ProDOS may only be called
with "default" memory mappings. However it is very well possible to
successfully call into MLI with LC bank 2 active. ProDOS even reactivates
it before returning. So it's like an "invitation" to make use of LC bank 2
from a SYS program.

>> I'd be very interested in a list of programs which use LC bank 2
>> $D400-$DFFF as there may be better ways to have drivers and other P8
>> add-ons use memory more effectively than what we have now.

> That area is reserved for "other" use (not application, not ProDOS). It
> isn't clearly explained why this reservation exists.
> 
> Speculation: it may have been originally reserved so Apple could expand
> ProDOS as required, but because some applications broke the rules and
> used it, this became impossible without breaking too much software. It
> might have still been used by the system in some situations (e.g. for
> temporary storage which was saved, modified and restored while
> interrupts were locked out).

Programs written with cc65 "brake those rules" by default, i.e. Contiki. A
plain vanilla ProDOS 8 for sure never makes use of those 3kB.

You may know of the virtual serial drive which replaces the Disk II driver
at $D000 in LC bank 1. I'm considering to implement a different type of
virtual drive and was wondering if that can be done with keeping the Disk
II driver intact. So I played with different memory areas - obviously
including LC bank 1. I don't remember the details anymore but the result
for me was that there's no area not used by SYS programs (LC bank 1, page
3, AUX, ...). Expanding ProDOS memory usage in any way is the ticket to
break things.

I might be wrong but I seem to remember that the ProDOS sysutils are pretty
agressively using LC bank 1...

If I were to remove 65C02 dependency from 2.0.3 and would need some room
I'd rather sacrifice some (as seldomly used as possible) functionality than
increase the memory footprint. Things coming into my mind:
- Support for sparse files
- Support for shrinking trees to saplings and/or saplings to seedlings

Regards,
Oliver

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

#2859

I'd rather add features. Those with a 6502 should use 1.9 and the others 2.x.

From my point of view, breaking something that works fine is a bad idea!

Antoine

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

#2900

On Monday, August 1, 2016 at 5:29:18 AM UTC-7, Oliver Schmidt wrote:
> Hi,
> 
> >>>> I'm looking into gathering up all the smartport routines and variables
> >>>> around $FD00 and moving them to LC bank 2.
> 
> >>> The 3k behind the quit code tend to be used by programs.
> 
> >> Yes I'm currently targeting moving code to LC bank 2 $D001-D0FF which I
> >> hope will free enough space in the main LC.
> 
> > The $D000-$D0FF page in the same bank as the quit code is listed in the
> > ProDOS-8 Technical Reference as free for application use, so ProDOS
> > cannot use it itself. 
> 
> Maybe two things worth to add here:
> 
> - From all I know ProDOS saves $D000 before using it to detect language
> card settings and restores it afterwards. So at least from "outside of
> ProDOS" there's no reason to treat this byte differently from the next 255
> bytes.
> 
> - The official ProDOS docs seem to imply that ProDOS may only be called
> with "default" memory mappings. However it is very well possible to
> successfully call into MLI with LC bank 2 active. ProDOS even reactivates
> it before returning. So it's like an "invitation" to make use of LC bank 2
> from a SYS program.
> 
> >> I'd be very interested in a list of programs which use LC bank 2
> >> $D400-$DFFF as there may be better ways to have drivers and other P8
> >> add-ons use memory more effectively than what we have now.
> 
> > That area is reserved for "other" use (not application, not ProDOS). It
> > isn't clearly explained why this reservation exists.
> > 
> > Speculation: it may have been originally reserved so Apple could expand
> > ProDOS as required, but because some applications broke the rules and
> > used it, this became impossible without breaking too much software. It
> > might have still been used by the system in some situations (e.g. for
> > temporary storage which was saved, modified and restored while
> > interrupts were locked out).
> 
> Programs written with cc65 "brake those rules" by default, i.e. Contiki. A
> plain vanilla ProDOS 8 for sure never makes use of those 3kB.
> 
> You may know of the virtual serial drive which replaces the Disk II driver
> at $D000 in LC bank 1. I'm considering to implement a different type of
> virtual drive and was wondering if that can be done with keeping the Disk
> II driver intact. So I played with different memory areas - obviously
> including LC bank 1. I don't remember the details anymore but the result
> for me was that there's no area not used by SYS programs (LC bank 1, page
> 3, AUX, ...). Expanding ProDOS memory usage in any way is the ticket to
> break things.
> 
> I might be wrong but I seem to remember that the ProDOS sysutils are pretty
> agressively using LC bank 1...
> 
> If I were to remove 65C02 dependency from 2.0.3 and would need some room
> I'd rather sacrifice some (as seldomly used as possible) functionality than
> increase the memory footprint. Things coming into my mind:
> - Support for sparse files
> - Support for shrinking trees to saplings and/or saplings to seedlings
> 
> Regards,
> Oliver

P8 2.0.3 expects the first byte of LC bank 1 to be $C8 (CLD), and writes an $EE to the first byte of LC bank 2. It uses these ID bytes to determine which LC banks are active and restoring them on exit.

While I'm sure any change to P8 will break some program somewhere, as the A2 community moves forward, what do we want out of ProDOS? To me, it seems like having one P8 version which can run on all A2 machines makes sense, as does allowing the creation of new drivers for things like extended RAM cards, new SSD/HD drivers, etc.

Apple's tech notes clearly show that they were considering removing /RAM and using aux memory for future P8 functionality, so I don't think we should necessarily give up on any ProDOS feature/improvement just because it's not 100% compatible with all previously written A2 software out there.

Thoughts?

-JB
Twitter: @JBrooksBSI

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

#2902

Hi John,

So 2.0.3 would be the universal 6502 version? and anove become updates?
I've never used the /RAM expected when I needed to remove it from the list of devices, its life is not important to me but if there is some free space elsewhere, I'd rather use it.

Antoine

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

#2903

Hi John,

> Apple's tech notes clearly show that they were considering removing /RAM and using aux memory for future P8 functionality, so I don't think we should necessarily give up on any ProDOS feature/improvement just because it's not 100% compatible with all previously written A2 software out there.
> 
> Thoughts?

Maybe I do misunderstand you but if one would change P8 to make own use of AUX
than that would both make it incompatible with all programs making use of AUX
as well as make it incompatible with 64kB machines. So from my perspective that
would be the worst choice to make.

However removing the /RAM feature from P8 might seem plausible at first sight.
But 'ProDOS 8 Technical Note #26: Polite Use of Auxiliary Memory' says:

"System software use of this area should be denoted by the absence of /RAM.
This means that if ProDOS 8 were to ever expand to run only on 128K machines
and require auxiliary language card memory, that no /RAM device would be
installed by default. Although this seems unlikely, it is nonetheless another
indicator that your application should not depend on /RAM to operate.

Similarly, if /RAM is not present when your application is launched, you may
not reenable it. If it is present, you may remove it to use the memory if you
reinstall it when you're done."

So removing the /RAM feature from P8 would cause a "correctly" written program
to presume that AUX is already in use by the system. So this would again cause
incompatibility with programs making use of AUX.

But what would be possible is to have an empty read-only /RAM. Then a "correct"
program could detect its presence, check that it's empty, remove it, make use of
AUX and reinstall it on exit.

However I'm wondering if reducing the /RAM feature to a "dummy /RAM" as just
described would free up enough memory to allow to remove the 65C02 dependency.

Regards,
Oliver

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

#2904

On Wednesday, August 10, 2016 at 7:12:21 AM UTC-7, Oliver Schmidt wrote:
> Hi John,
> 
> > Apple's tech notes clearly show that they were considering removing /RAM and using aux memory for future P8 functionality, so I don't think we should necessarily give up on any ProDOS feature/improvement just because it's not 100% compatible with all previously written A2 software out there.
> > 
> > Thoughts?
> 
> Maybe I do misunderstand you but if one would change P8 to make own use of AUX
> than that would both make it incompatible with all programs making use of AUX
> as well as make it incompatible with 64kB machines. So from my perspective that
> would be the worst choice to make.
> 
> However removing the /RAM feature from P8 might seem plausible at first sight.
> But 'ProDOS 8 Technical Note #26: Polite Use of Auxiliary Memory' says:
> 
> "System software use of this area should be denoted by the absence of /RAM.
> This means that if ProDOS 8 were to ever expand to run only on 128K machines
> and require auxiliary language card memory, that no /RAM device would be
> installed by default. Although this seems unlikely, it is nonetheless another
> indicator that your application should not depend on /RAM to operate.
> 
> Similarly, if /RAM is not present when your application is launched, you may
> not reenable it. If it is present, you may remove it to use the memory if you
> reinstall it when you're done."
> 
> So removing the /RAM feature from P8 would cause a "correctly" written program
> to presume that AUX is already in use by the system. So this would again cause
> incompatibility with programs making use of AUX.
> 
> But what would be possible is to have an empty read-only /RAM. Then a "correct"
> program could detect its presence, check that it's empty, remove it, make use of
> AUX and reinstall it on exit.
> 
> However I'm wondering if reducing the /RAM feature to a "dummy /RAM" as just
> described would free up enough memory to allow to remove the 65C02 dependency.
> 
> Regards,
> Oliver

There are several ProDOS design decisions which were good for their time, but I'm not sure are ideal going forward:

1) All ProDOS functionality must load entirely into memory at boot (ie, no post-boot drivers or features loaded from HD)

2) ProDOS only uses the 16K language card, with no support for Ramworks or GS memory and minimal use of the 64k aux memory as /RAM.

3) By placing ProDOS in the LC, it could be made 'safe' by write protecting the LC & ProDOS, but we lost the ability to use the Language Card as Woz originally intended: copying the ROM to LC RAM and being able to switch between Integer Basic and Applesoft, or patching the ROM or Basic to add functionality.

> But what would be possible is to have an empty read-only /RAM. Then a "correct" 
> program could detect its presence, check that it's empty, remove it, make use of 
> AUX and reinstall it on exit. 

Yes, P8 reserves 01/0000-01/0800 of aux memory, so having a 'dummy' /RAM would free up this 2K of aux memory, plus about 100 bytes at 00/FF00.

> However I'm wondering if reducing the /RAM feature to a "dummy /RAM" as just 
> described would free up enough memory to allow to remove the 65C02 dependency. 

Yes, it certainly would as we only need about 200 bytes. I'm hopeful that these bytes can be found without resorting to major changes to P8 though.

-JB
Twitter: @JBrooksBSI

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

#2905

John Brooks wrote:
> 
> There are several ProDOS design decisions which were good for their time,
> but I'm not sure are ideal going forward:
> 

And 15-character file names, anyone?

Would nice to see a backwards-compatible change to the directory structure
to allow a couple more chars.

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

#2908

On Wednesday, August 10, 2016 at 10:12:59 AM UTC-6, D Finnigan wrote:
> John Brooks wrote:
> > 
> > There are several ProDOS design decisions which were good for their time,
> > but I'm not sure are ideal going forward:
> > 
> 
> And 15-character file names, anyone?
> 
> Would nice to see a backwards-compatible change to the directory structure
> to allow a couple more chars.


This wouldn't be too hard.  Just do to the directory what Macintosh did.  It uses a flag character to signify that the filename is longer than 15 characters.

The 39 bytes that describe a file structure would have to stay the same.
And GSOS uses the Prodos version byte to signify that the filename has lowercase letters.

Where this fails is when any program that navigates the directory structure assumes exactly 39 bytes to the next entry.  Although, I think a have a solution for this as well.  The first byte of the extended filename would have to be a zero, which would be taken as a deleted file and ignored.

So 38 bytes can be used as the extended filename, plus 15 bytes from the original entry would give a filename with 53 bytes.

This should work with any Basic.system commands and would need a driver to recognize the flag that indicates there is an extended filename.

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

#2909

On Wednesday, August 10, 2016 at 9:53:00 AM UTC-6, John Brooks wrote:
> On Wednesday, August 10, 2016 at 7:12:21 AM UTC-7, Oliver Schmidt wrote:
> > Hi John,
> > 
> > > Apple's tech notes clearly show that they were considering removing /RAM and using aux memory for future P8 functionality, so I don't think we should necessarily give up on any ProDOS feature/improvement just because it's not 100% compatible with all previously written A2 software out there.
> > > 
> > > Thoughts?
> > 
> > Maybe I do misunderstand you but if one would change P8 to make own use of AUX
> > than that would both make it incompatible with all programs making use of AUX
> > as well as make it incompatible with 64kB machines. So from my perspective that
> > would be the worst choice to make.
> > 
> > However removing the /RAM feature from P8 might seem plausible at first sight.
> > But 'ProDOS 8 Technical Note #26: Polite Use of Auxiliary Memory' says:
> > 
> > "System software use of this area should be denoted by the absence of /RAM.
> > This means that if ProDOS 8 were to ever expand to run only on 128K machines
> > and require auxiliary language card memory, that no /RAM device would be
> > installed by default. Although this seems unlikely, it is nonetheless another
> > indicator that your application should not depend on /RAM to operate.
> > 
> > Similarly, if /RAM is not present when your application is launched, you may
> > not reenable it. If it is present, you may remove it to use the memory if you
> > reinstall it when you're done."
> > 
> > So removing the /RAM feature from P8 would cause a "correctly" written program
> > to presume that AUX is already in use by the system. So this would again cause
> > incompatibility with programs making use of AUX.
> > 
> > But what would be possible is to have an empty read-only /RAM. Then a "correct"
> > program could detect its presence, check that it's empty, remove it, make use of
> > AUX and reinstall it on exit.
> > 
> > However I'm wondering if reducing the /RAM feature to a "dummy /RAM" as just
> > described would free up enough memory to allow to remove the 65C02 dependency.
> > 
> > Regards,
> > Oliver
> 
> There are several ProDOS design decisions which were good for their time, but I'm not sure are ideal going forward:
> 
> 1) All ProDOS functionality must load entirely into memory at boot (ie, no post-boot drivers or features loaded from HD)
> 
> 2) ProDOS only uses the 16K language card, with no support for Ramworks or GS memory and minimal use of the 64k aux memory as /RAM.
> 
> 3) By placing ProDOS in the LC, it could be made 'safe' by write protecting the LC & ProDOS, but we lost the ability to use the Language Card as Woz originally intended: copying the ROM to LC RAM and being able to switch between Integer Basic and Applesoft, or patching the ROM or Basic to add functionality.
> 
> > But what would be possible is to have an empty read-only /RAM. Then a "correct" 
> > program could detect its presence, check that it's empty, remove it, make use of 
> > AUX and reinstall it on exit. 
> 
> Yes, P8 reserves 01/0000-01/0800 of aux memory, so having a 'dummy' /RAM would free up this 2K of aux memory, plus about 100 bytes at 00/FF00.
> 
> > However I'm wondering if reducing the /RAM feature to a "dummy /RAM" as just 
> > described would free up enough memory to allow to remove the 65C02 dependency. 
> 
> Yes, it certainly would as we only need about 200 bytes. I'm hopeful that these bytes can be found without resorting to major changes to P8 though.
> 
> -JB
> Twitter: @JBrooksBSI


The driver I was attempting to write for the Ramworks card would have resolved some of these.

It would have disabled and removed the Ramdrive in Aux bank#0 and moved it into the extended memory beyond 128 kb.

This way Aux Ram would be totally free for Prodos.  And if Prodos were to require 128 kb, would it then not be reasonable to set a requirement for the computer to have 256 kb or above, to allow for the smallest Ram drive of 128 kb?

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

#2910

On Tuesday, August 9, 2016 at 8:43:37 PM UTC-7, John Brooks wrote:
> P8 2.0.3 expects the first byte of LC bank 1 to be $C8 (CLD), and writes an $EE to the first byte of LC bank 2. It uses these ID bytes to determine which LC banks are active and restoring them on exit.

I see on page 220, file PROLDR, just after "see rev note #38" it does:
    lda #$ee
    sta $d000
    jsr lc1in

Where is $C8 set ? I see this comment in REVISIONS

* 1. In the language card area, the $D000 areas overlay. To *
* determine which bank is in requires that the main bank *
* has a CLD instruction ($D8) at location $D000 and the *
* alternate bank must not.

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

#2911

On Thursday, August 11, 2016 at 8:31:45 AM UTC-7, Michael Pohoreski wrote:
> On Tuesday, August 9, 2016 at 8:43:37 PM UTC-7, John Brooks wrote:
> > P8 2.0.3 expects the first byte of LC bank 1 to be $C8 (CLD), and writes an $EE to the first byte of LC bank 2. It uses these ID bytes to determine which LC banks are active and restoring them on exit.
> 
> I see on page 220, file PROLDR, just after "see rev note #38" it does:
>     lda #$ee
>     sta $d000
>     jsr lc1in
> 
> Where is $C8 set ? I see this comment in REVISIONS
> 
> * 1. In the language card area, the $D000 areas overlay. To *
> * determine which bank is in requires that the main bank *
> * has a CLD instruction ($D8) at location $D000 and the *
> * alternate bank must not.

The first instruction of the 5.25 RWTS at $D000 LC1 contains a CLD. See source in XrwTot.n.

-JB
Twitter: @JBrooksBSI

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

#2913

On Thursday, August 11, 2016 at 10:32:56 AM UTC-7, John Brooks wrote:
> On Thursday, August 11, 2016 at 8:31:45 AM UTC-7, Michael Pohoreski wrote:
> > On Tuesday, August 9, 2016 at 8:43:37 PM UTC-7, John Brooks wrote:
> The first instruction of the 5.25 RWTS at $D000 LC1 contains a CLD. See source in XrwTot.n.
> 
> -JB
> Twitter: @JBrooksBSI

Ah, File: XRW1, Page 280
blockio cld ; this must be first as it is an id value

Thanks John!
Michael

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

#2928

> Ah, File: XRW1, Page 280
> blockio cld ; this must be first as it is an id value

I always wondered why they didn't read the softswitches instead?
Something like:

 LDA $C012
 STA lcstate
 LDA $C011
 PHA ;save bank and LC state
 LDA $C08B
 LDA $C08B ;enable bank 1
 JSR $D000 ;call driver
 PLA
 LSR
 LSR
 LSR
 LSR
 ASL lcstate
 ADC #0
 TAX
 STA $C082,X ;restore bank and LC state

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web