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

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

ProBLOAD (a DOS 3.3 tiny extension)

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

Contents

  ProBLOAD (a DOS 3.3 tiny extension) Benoit0123 <bgilon@free.fr> - 2017-07-30 20:26 +0000
    Re: ProBLOAD (a DOS 3.3 tiny extension) Hugh Hood <hughhood@earthlink.net> - 2017-07-30 18:02 -0500
      Re: ProBLOAD (a DOS 3.3 tiny extension) Benoit0123 <bgilon@free.fr> - 2017-07-31 05:49 +0000
        Re: ProBLOAD (a DOS 3.3 tiny extension) Hugh Hood <hughhood@earthlink.net> - 2017-08-01 00:05 -0500
          Re: ProBLOAD (a DOS 3.3 tiny extension) ol.sc@web.de (Oliver Schmidt) - 2017-08-01 08:00 +0000
          Re: ProBLOAD (a DOS 3.3 tiny extension) Michael J. Mahon <mjmahon@aol.com> - 2017-08-01 13:59 -0500
            Re: ProBLOAD (a DOS 3.3 tiny extension) Hugh Hood <hughhood@earthlink.net> - 2017-08-02 01:50 -0500
              Re: ProBLOAD (a DOS 3.3 tiny extension) Michael J. Mahon <mjmahon@aol.com> - 2017-08-02 12:00 -0500
            Re: ProBLOAD (a DOS 3.3 tiny extension) Nick Westgate <nick.westgate@gmail.com> - 2017-08-02 15:22 -0700

#3738 — ProBLOAD (a DOS 3.3 tiny extension)

Hello,

ProBLOAD (internal codename BRR (*)) is an attempt to patch DOS 3.3 for
providing L and B options to the BLOAD and
BRUN commands, thus mimicking those commands behavior under ProDOS BI.
ProBLOAD can be downloaded from the URL below:
http://bgilon.free.fr/apple2/ProBLOAD.zip
Two versions are available:
a) BRRmini: with the minimum version of the patch (do not try to INIT a disk
while this patch is active);
b) BRR: the full pledge with safeguard procedures (see the Merlin source
file header for details).

The zip file quoted above contains a disk image with both the relevant
source and object files (Merlin 8 v2.48) along with
a PDF assembly listing file for the full version.

Including in the .do disk image is an EXEC test file to show you what the
patch does: to use it, just issue a BRUN BRR (or
BRUN BRRMINI) followed by a EXEC TESTBRR command at Applesoft prompt.

The patch is being installed by binary running (i.e. « BRUN ») either the
BRR or the BRRmini binary files.
Obviously BRRMINI is much smaller in size than BRR in case you had to
keyboard enter it from a monitor listing.

Have fun,
Benoît

(*): BRR is a TLA for « Before Release Revision »

For those interested, below is the pseudo code of the patched BLOAD core
mechanism (but you can study the provided
source file if you prefer):

Collect the original file loading address and file length from the 4 first
bytes of the binary file.
Let AVOrg:= Address from file
Let LVOrg:= Length from file
If keyword B present Then
 O:= UserParm(B);
 S:= 4; # Position then read a range of bytes subcode
 If O > LVOrg Then Issue a RANGE ERROR
Else
 S:= 2; # Read a range of bytes subcode
 O:= 0;
EndIf
If A keyword is provided then
  P:= UserParm(A);
Else
 P:= AVOrg + O;
EndIf
If L keyword is provided on command line Then
 L:= UserParm(L);
 If L + O > LVOrg Then Issue a RANGE ERROR
Else
 L:= LVOrg - O;
End If;
If P + L > 65535 Then Issue a RANGE ERROR
Calls the FM for loading the segment of binary file
- using the subcode S (either 2 or 4), the latter involving a POSITION
- from offset(O) # only meaningful where involving a POSITION
- of length (L)
- into memory starting @ address P


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

[toc] | [next] | [standalone]

#3739

Benoît,

I certainly like the assembly listing in .pdf format that you provided, 
particularly since it contains the symbol tables at the end.

May I ask whether this .pdf was something that was converted from a text 
file by capturing Merlin's output following the Merlin 'PRTR' command, 
or rather was it created from a text file generated by the Merlin 
'Printfiler' utility?

If the former, did you do this via an emulator capturing 'printed' 
output, or did you send the 'print' via a serial hookup to another computer?

I generally use Merlin32 these days and create .pdf listings from its 
text file output, but there is still a charm to the actual Merlin 8/16 
formatted listings that I like, including the symbol tables.

Thank you for satisfying my curiosity and for sharing your methodology.





Hugh Hood


On 7/30/2017 3:26 PM, Benoit0123 wrote:
> 
> The zip file quoted above contains a disk image with both the relevant
> source and object files (Merlin 8 v2.48) along with
> a PDF assembly listing file for the full version.
> 

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

#3740

Hugh Hood wrote:
> Benoît,
> 
> I certainly like the assembly listing in .pdf format that you provided, 
> particularly since it contains the symbol tables at the end.
> 
> May I ask whether this .pdf was something that was converted from a text 
> file by capturing Merlin's output following the Merlin 'PRTR' command, 
> or rather was it created from a text file generated by the Merlin 
> 'Printfiler' utility?
My current development environment for 8bit and DOS 3.3 programs is a MacOS
X node and an "Apple //e enhanced"
emulator (Virtual 2 by Gerard Putter), it offers a printer emulation by
capturing slot #1 (configurable
output) as a real printer (either a Epson MX or an Apple Imagewriter) will
do. This include the noise made by the dot printing and the paper feed, a
sound that I like to hear nowadays - no exact emulation for the noise
hélas).
The other "advanced" feature I like much about Virtual 2 (beyond its debug
facilities) is that it can emulate a volume (either DOS 3.3 or ProDOS) in a
native Mac OS X folder which is something that I appreciate a lot (but not
in this
context of 8bits GP utility dev.).
The listing was generated by an assembly just after a PRTR 1 command @ the
Merlin 8 editor prompt.
I do not use Merlin 32 because I do not think that it will
generate DOS 3.3 executables (cf. the first 4 bytes).
> If the former, did you do this via an emulator capturing 'printed' 
> output, or did you send the 'print' via a serial hookup to another
> computer?
> 
> I generally use Merlin32 these days and create .pdf listings from its 
> text file output, but there is still a charm to the actual Merlin 8/16 
> formatted listings that I like, including the symbol tables.
> 
> Thank you for satisfying my curiosity and for sharing your methodology.
You're welcome
> 
> 
> 
> 
> Hugh Hood
Benoît

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

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

#3745

On 7/31/2017 12:49 AM, Benoit0123 wrote:

> 
> The listing was generated by an assembly just after a PRTR 1 command
> @ the Merlin 8 editor prompt.
> 

Thank you for prompting me with that explanation and idea.

I just tried something similar on a real machine with a serial hookup to 
the Unix command line. By printing from the Apple II to 'standard input' 
on the Unix machine, I was able to capture the Merlin assembly listing 
and then send it on to the command line pdf creator pcl2pdf. I'm not 
completely happy with my first attempt (page breaks and CPI need to be 
changed), but I think a few adjustments to the Merlin 'PARMS' file will 
give me something acceptable. Using PRTR seems simpler than using 
Printfiler, but maybe I'm being lazy here.


> 
> The other "advanced" feature I like much about Virtual 2 (beyond its 
> debug facilities) is that it can emulate a volume (either DOS 3.3 or 
> ProDOS) in a native Mac OS X folder which is something that I 
> appreciate a lot.
>

I agree. That is a great feature as it allows one to 'escape' from 
having to use disk images when doing Apple II work. I suppose this is 
easier to implement on a Mac since the Apple II ProDOS attributes can be 
preserved in the Mac Creator and File Type fields in the HFS+ file system.

To preserve those ProDOS attributes on Windows, I imagine that someone 
would need to do something like AppleDouble, which would complicate 
coding. Ciderpress modifies the file names to preserve attributes, but 
that is really just a work-around. Too bad Windows doesn't support XATTR 
(yet).

But, I digress.

Thanks again.




Hugh Hood

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

#3746

Hi Hugh,

>To preserve those ProDOS attributes on Windows, I imagine that someone 
>would need to do something like AppleDouble, which would complicate 
>coding. Ciderpress modifies the file names to preserve attributes, but 
>that is really just a work-around. Too bad Windows doesn't support XATTR 
>(yet).


On NTFS you have Alternate Data Streams which can be used - and are
actually used
(https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29)
- to hold extended attributes.

Regards,
Oliver

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

#3748

Hugh Hood <hughhood@earthlink.net> wrote:
> On 7/31/2017 12:49 AM, Benoit0123 wrote:
> 
>> 
>> The listing was generated by an assembly just after a PRTR 1 command
>> @ the Merlin 8 editor prompt.
>> 
> 
> Thank you for prompting me with that explanation and idea.
> 
> I just tried something similar on a real machine with a serial hookup to 
> the Unix command line. By printing from the Apple II to 'standard input' 
> on the Unix machine, I was able to capture the Merlin assembly listing 
> and then send it on to the command line pdf creator pcl2pdf. I'm not 
> completely happy with my first attempt (page breaks and CPI need to be 
> changed), but I think a few adjustments to the Merlin 'PARMS' file will 
> give me something acceptable. Using PRTR seems simpler than using 
> Printfiler, but maybe I'm being lazy here.
> 
> 
>> 
>> The other "advanced" feature I like much about Virtual 2 (beyond its 
>> debug facilities) is that it can emulate a volume (either DOS 3.3 or 
>> ProDOS) in a native Mac OS X folder which is something that I 
>> appreciate a lot.
>> 
> 
> I agree. That is a great feature as it allows one to 'escape' from 
> having to use disk images when doing Apple II work. I suppose this is 
> easier to implement on a Mac since the Apple II ProDOS attributes can be 
> preserved in the Mac Creator and File Type fields in the HFS+ file system.
> 
> To preserve those ProDOS attributes on Windows, I imagine that someone 
> would need to do something like AppleDouble, which would complicate 
> coding. Ciderpress modifies the file names to preserve attributes, but 
> that is really just a work-around. Too bad Windows doesn't support XATTR 
> (yet).
> 
> But, I digress.
> 
> Thanks again.
> 
> 
> 
> 
> Hugh Hood
> 

My usual method of handling Merlin 8 listings is to do my assemblies using
AppleWin, issuing a PRTR 1 prior to ASM. 

AppleWin produces a "printer.txt" file (I give it some time to close the
file) which I open in Word, select all, and change the (Courier) font size
to 9 points (so the lines don't wrap). Word correctly interprets the Form
Feeds as page breaks, so when I "print" the file to a PDF, everything looks
right. 

Since many of my programs are 50-100 page listings, I usually print the PDF
two "pages" to a page, double-sided. 

The result is a neat, readable hard copy that prints pretty quickly. As you
can imagine, I seldom printed listings when I was assembling on my //e. ;-)

And the PDF file is very convenient to browse on the computer, and easy to
share. 

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

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

#3750

On 8/1/2017 1:59 PM, Michael J. Mahon wrote:
> 
> My usual method of handling Merlin 8 listings is to do my assemblies using
> AppleWin, issuing a PRTR 1 prior to ASM.
> 
> AppleWin produces a "printer.txt" file (I give it some time to close the
> file) which I open in Word, select all, and change the (Courier) font size
> to 9 points (so the lines don't wrap). Word correctly interprets the Form
> Feeds as page breaks, so when I "print" the file to a PDF, everything looks
> right.
> 


Michael,

That is another excellent method, and one which I will try since I use 
AppleWin on occasion. Thanks for sharing it.

Do you know off hand what a 9-point Courier font's equivalent CPI is? I 
suppose that it is more than 12 CPI but somewhat less than 16 CPI, so we 
get a little more than 110 characters on a standard 8-inch wide page, if 
I've got this right.




Hugh Hood

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

#3751

Hugh Hood <hughhood@earthlink.net> wrote:
> On 8/1/2017 1:59 PM, Michael J. Mahon wrote:
>> 
>> My usual method of handling Merlin 8 listings is to do my assemblies using
>> AppleWin, issuing a PRTR 1 prior to ASM.
>> 
>> AppleWin produces a "printer.txt" file (I give it some time to close the
>> file) which I open in Word, select all, and change the (Courier) font size
>> to 9 points (so the lines don't wrap). Word correctly interprets the Form
>> Feeds as page breaks, so when I "print" the file to a PDF, everything looks
>> right.
>> 
> 
> 
> Michael,
> 
> That is another excellent method, and one which I will try since I use 
> AppleWin on occasion. Thanks for sharing it.
> 
> Do you know off hand what a 9-point Courier font's equivalent CPI is? I 
> suppose that it is more than 12 CPI but somewhat less than 16 CPI, so we 
> get a little more than 110 characters on a standard 8-inch wide page, if 
> I've got this right.
> 
> 
> 
> 
> Hugh Hood

Courier New 9-point is about 13cpi, compared to 10-point's 11.5cpi. 

Another advantage of the smaller font is that there are more lines per
page. 

If margins are narrowed and less than 60 lines per page are satisfactory,
10-point is fine. 

I set Merlin to 66 lines per page, so I need 9-point. 

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

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

#3753

On Wednesday, 2 August 2017 07:00:04 UTC+12, mjm...@aol.com  wrote:
> AppleWin produces a "printer.txt" file (I give it some time to close the
> file) which I open in Word, select all, and change the (Courier) font size
> to 9 points (so the lines don't wrap). Word correctly interprets the Form
> Feeds as page breaks, so when I "print" the file to a PDF, everything looks
> right. 

That's a nice workflow.

I'm working on something which might help ... one day.

Another way to do it would be to process the file with a script into HTML. Mostly an empty HTML page to wrap around it, but also processing the Form Feeds and other control characters.

Then this could convert it to PDF:
https://wkhtmltopdf.org/

Cheers,
Nick.

[toc] | [prev] | [standalone]

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

csiph-web