Re: Prodos Woes

["Charlie" <charlied@NOSPAMbboard.com>]

"Bill Garber" <willy46pa@comcast.net> wrote in message
Y-WdnVAXO_WZaEGiRVn-tw@comcast.com">news:Y-WdnVAXO_WZaEGiRVn-tw@comcast.com...
>
> "Charlie" <charlied@NOSPAMbboard.com> wrote in message
> brihfk04vs@enews3.newsguy.com">news:brihfk04vs@enews3.newsguy.com...
> :
> : "Bill Garber" <willy46pa@comcast.net> wrote in message
> : b9OdnYNUcbSxNUGi4p2dnA@comcast.com">news:b9OdnYNUcbSxNUGi4p2dnA@comcast.com...
> : >
> : > Ok, first, I think you need to define your memory location
> : > as A$xxxx as HEX. You should anyway.
> :
> : In ProDOS it doesn't matter, you can use hex or decimal.
>
> Interesting. However, if you are going to program in
> assembler, wouldn't it be wise to continue to think
> in terms of hex?

Yes, in fact I prefer hex, but many people consider us assembly language
programmers strange.

>
> : > Also, on a BLOAD the
> : > file that you have previously BSAVE'd will contain a few
> bytes
> : > header with the location to be BLOAD'd into.
> :
> : In ProDOS the bytes you are talking about are not stored in the
> file (they are
> : in DOS 3.3).
>
> Ok, then how does it know to BLOAD at the same location
> that I assigned when I BSAVE'd the file without specifying
> one?

In ProDOS the directory is actually a special kind of file that holds a list of
"File Descriptive Entries".  Each entry (there is one for each file in the
directory) contains the name of the file, filetype, auxtype, storage type, file
length, access bits, creation and modificaton date and time, etc.  For a binary
file the load address (from the BSAVE) is stored in the auxtype.

>
> : > No need to define this location on a BLOAD.
> :
> : True, unless you want to BLOAD to a different location.
>
> This is also interesting. Now I know I can BSAVE a memory
> block and BLOAD it in another area. Cool!

Yep!

>
> : There is a seldom used "page 2" of text, starting at $800 and
> ending at $BFF. I
> : believe accessing $C055 (49237) turns on page 2.  On a IIgs I
> believe you have
> : to have the "Alternate Display Mode" turned on for this to
> work.
>
> Nice. So I can load up a Page1, show it, and while working in
> Page1
> load up a Page2 and switch, then load a new Page1 and switch
> again?

Yes, if you are loading the memory from machine code.  I've never really used
Page2 text, but I seem to remember that the ROM text routines don't support it
(I maybe wrong here, somebody else may be able to clear that up).  Another
problem is that Applesoft's default load area clobbers the Page2 text.

>
> : It is not always the fault of the emulator when something
> doesn't work, but the
> : image that we are trying to run on it.  Most disk images don't
> contain all the
> : information that the original disk had.
>
> For sure. I've downloaded many a disk image that had missing
> data or program files, or have had files moved into or out of
> folders and hence original systems can't find them.

That is true, but I was thinking more of the images with programs that try to
directly read the data from the disk, by-passing DOS.  Most disk images have
already been decoded and don't have the original information anymore.  The
exception is the ".nib" disk image but they aren't as common.  There are also
several "special" DOSes that read the sectors in a different order or did other
fancy things.  These disks when converted to .DSK type images will usually not
boot but are still readable if you boot a regular DOS 3.3 image first.

> : > I agree wholeheartedly. Apple IIs are fun though.
> :
> : They sure are.
>
> At first they weren't, but the more I know the more I want
> to learn and the more fun I have. ;-)

I've had fun with Apple IIs since 1980.  Since 1997 I've used mostly emulators,
but I still have an Apple IIgs and an Apple //e that I occasionally use.

Charlie