Adds programming and games disk images

[rprouse]

Resolves #347

Adds the following disk images,

Disk	Description
d_z80asm	Z80ASM by SLR Systems
d_aztecc	Aztec C II compiler v1.06D
d_hitechc	HI-TECH Z80 CP/M C compiler V3.09-17
d_tpascal	Turbo Pascal Compiler v3.01A
d_bascomp	Microsoft Basic-80 Compiler v.5.30a
d_fortran	Microsoft Fortran-80 Compiler v.3.44
d_games	Games, Infocom games, Nemesis and Dungeon Master

Also adds the documentation for these programs to the Docs directory where available.

Finally, I also added a few addtitional utilites and programs to the base OS disks,

BBCBASIC.COM - BBC BASIC CP/M Version 3.00 by R.T.Russell
BBCBASIC.TXT - Help file for BBC BASIC
GENHEX.COM - Generates an Intel Hex file from the input file
LS.COM - An alternative file listing to DIR
LSWEEP.COM - Can extract and view member files of an .LBR archive

These are in a UTILS directory instead of COMMON so that I could add them to the HD images but not the FD images. Most of the FD images are near capacity so I did not add these utilities to them.

TODO

• Remove HLP files
• Remove MSBASIC85
• Research and decide on compression tools specifically UNCR vs USQ
• Decide whether or not to keep DELBR.COM. Does it provide functionality over LBREXT?
• Discuss and decide on the merit of disks vs user areas
• Once the final list of COMMON files is decided, will there be room on the FD images for the files?

[wwarthen]

Thank you Rob. I do want to review the files you are adding to the existing disk images. Probably all fine. I may need a day or two to review.

I failed to mention this, but for future reference, I would like to get all push requests against the dev branch. Since I screwed up, I will go go ahead and do this merge and then propagate the changes to dev.

Thanks,

Wayne

[rprouse]

@wwarthen no worries, take as much time as you need. If there is anything you don't want included let me know and I will update the PR.

I've rebased the PR onto the dev branch. Might I suggest that you switch the default branch to dev in the settings so others don't make the same mistake?

[feilipu]

Just to note that Tony @agn453 maintains Hi-Tech C. Perhaps it would be better to use his repository release?

[rprouse]

Just to note that Tony @agn453 maintains Hi-Tech C. Perhaps it would be better to use his repository release?

I didn't realize it was still being maintained. That is a great idea. @wwarthen any issues with me replacing what I added with the newer release?

[wwarthen]

I've rebased the PR onto the dev branch.

Thank you for doing that!

Might I suggest that you switch the default branch to dev in the settings so others don't make the same mistake?

I tried that a long time ago and it caused horrible confusion for the majority of the people using the repository. Most of the people using RomWBW expect the default branch to be equivalent to the current stable release. I do need to find some way to better communicate that contributions should go into dev.

[wwarthen]

Just to note that Tony @agn453 maintains Hi-Tech C. Perhaps it would be better to use his repository release?

I didn't realize it was still being maintained. That is a great idea. @wwarthen any issues with me replacing what I added with the newer release?

Please do. Thanks.

[wwarthen]

I have a question about the CPM22.HLP file you included. I'm not sure what format it is intended to be. It has a .HLP extension, but is clearly not intended to work with the "HELP" command. It sort of looks like a generic text file, but it has high bits set on many characters (WordStar?) and uses colons in front of the section titles.

Thanks,

Wayne

[rprouse]

I have updated the HI-TECH C compiler to the latest update 17

I have a question about the CPM22.HLP file you included. I'm not sure what format it is intended to be. It has a .HLP extension, but is clearly not intended to work with the "HELP" command. It sort of looks like a generic text file, but it has high bits set on many characters (WordStar?) and uses colons in front of the section titles.

My mistake. it was included in a collection of HLP files that I'd installed on my RC2014 prior to upgrading to RomWBW. I'd never tested it and just carried it along with me. I've removed it.

I tried that a long time ago and it caused horrible confusion for the majority of the people using the repository. Most of the people using RomWBW expect the default branch to be equivalent to the current stable release. I do need to find some way to better communicate that contributions should go into dev.

Understood. Maybe a PR template so it shows up when people submit a PR? If master continues to trail dev as a release branch, then rebasing is easy.

[feilipu]

😄 small typo.
Tony rather than Tory.
Thanks for the update.

[rprouse]

Tony rather than Tory.

Fixed, thanks.

[wwarthen]

Understood. Maybe a PR template so it shows up when people submit a PR? If master continues to trail dev as a release branch, then rebasing is easy.

I didn't know about pull request templates. I will check that out.

[rprouse]

A PR template will automatically show in the body of any PR, but it must be in the default branch. Information is here, https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates#pull-request-templates. You can also create Issue templates for different issue types.

Here is an example, https://raw.githubusercontent.com/cake-build/cake/develop/.github/PULL_REQUEST_TEMPLATE.md

[wwarthen]

A PR template will automatically show in the body of any PR, but it must be in the default branch. Information is here, https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates#pull-request-templates. You can also create Issue templates for different issue types.

Thank you. I think I have it in place now.

[wwarthen]

Hi Rob,

Thus far, I have focused on the UTILITY programs because they have the most impact on people. I have a few questions about these programs:

ASM2.HLP
MBASIC.HLP

• What format are these intended to be? Some high bits set. Colon in front of titles? They seem useful, but may need to be massaged a bit to be in a generic format.

MBASIC85.COM

• I have seen this variant of MBASIC, but have never been able to determine quite what
  it is. Clearly a newer version than the already included MBASIC-80. The name
  seems to imply it is for the 8085 CPU. However, it seems to run fine on Z80. So, is this
  really just a newer version of MBASIC-80? If it is truly compatible with
  Z80, probably ought to replace MBASIC across the board. Do you know it's history?

USQ.COM

• Is this duplicative with UNCR? Is one superior?

DELBR.COM

• Is this duplicative with LBREXT? Is one superior?

LS.COM

• Is this different from / superior to the other included directory programs?

LSWEEP.COM

• Is this duplicative with NULU? Is one superior?

Sorry for all the questions. Just want to make sure I understand what everything is.

Thanks,

Wayne

[agn453]

MBASIC85.COM

* I have seen this variant of MBASIC, but have never been able to determine quite what
  it is.  Clearly a newer version than the already included MBASIC-80.  The name
  seems to imply it is for the 8085 CPU.  However, it seems to run fine on Z80.  So, is this
  really just a newer version of MBASIC-80?  If it is truly compatible with
  Z80, probably ought to replace MBASIC across the board.  Do you know it's history?

MBASIC85.COM (Rev 5.29) is just MBASIC80.COM (Rev 5.21) with the sign-on message bytes changed.

M>mbasic80
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
36408 Bytes free
Ok
system

M>mbasic85
BASIC-85 Rev. 5.29
[CP/M Version]
Copyright 1985-1986  त  by Microsoft
Created: 28-Jul-85
36408 Bytes free
Ok
system

M>bincom mbasic80.com mbasic85.com
         BINCOM/ICUAP
Universidad Autonoma de Puebla
      September 16, 1983

File 1:  MBASIC80.COM
File 2:  MBASIC85.COM

5EA1  35 30     5EAB  39 31     5ECA  38 37     5ECB  35 37
5ED0  36 31     5ED2  20 28     5ED3  A4 43     5ED4  20 29
5EF5  35 31
Number of bytes compared:   5F00H
Number of mismatches found: 0009H

M>

Tony

[wwarthen]

MBASIC85.COM (Rev 5.29) is just MBASIC80.COM (Rev 5.21) with the sign-on message bytes changed.

That's funny. Sounds like this v5.29 was just some kind of hack. Given this, I suggest we keep the existing version (MBASIC-80 v5.21) in RomWBW and pass on this other thing.

Thanks,

Wayne

[feilipu]

That's funny. Sounds like this v5.29 was just some kind of hack.

I wouldn't discount it being an "in-house" hack to keep their 8080 Basic 5.21 product relevant in a market full of 8085 CPUs.

Even the NASCOM Z80 MSBasic source we have (4.71) had no Z80 code in it, except one NASCOM added function LINES.

5.21 is also pure 8080 code too, and it runs fine on 8085. Would make sense not to change 5.21, being not broken. 😉

[rprouse]

Questions are appreciated, so no worries. I am a old programmer but I didn't use CP/M in my youth, so I am still learning the ins and outs of the ecosystem.

• I've already removed all of the HLP files. I downloaded them with an included HELP.COM (not included) and didn't realize that it supported a newer/different format because it just worked for me. Not worth it.
• I'd always assumed MBASIC85 was a newer version with bug fixes. It looks like I am wrong. I will remove it.
• LS is superior to the built in DIR with file sizes and sorting. I noticed after I added it that you included ZXD? another DIR replacement. To me, LS is only superior in that it is well named and easy to use. Happy to remove it if you want.
• Let me do some more research on the decompression programs. I included USQ to decompress Squeezed files vs UNCR which is for Crunched files but maybe it supports both formats? This is an area where I don't have the history with the file formats or programs. LSWEEP does do the same as NULU but in different ways, it is down to preference. I figured that the HD images have room so I wanted to give people the tools they are familiar with. Happy to not include them though.
• I think BBC Basic is important to include for our British and European friends. It could also be a disk image rather than included on the boot disks. It is distributed with sample files that I could include on a disk image. Would you prefer that?

Hope all this isn't too much work for you 😉

[wwarthen]

Questions are appreciated, so no worries. I am a old programmer but I didn't use CP/M in my youth, so I am still learning the ins and outs of the ecosystem.

Glad you don't mind!

• I've already removed all of the HLP files. I downloaded them with an included HELP.COM (not included) and didn't realize that it supported a newer/different format because it just worked for me. Not worth it.

Fine, thanks.

• I'd always assumed MBASIC85 was a newer version with bug fixes. It looks like I am wrong. I will remove it.

Seems like it is redundant, so I agree with removing it. Thanks.

• LS is superior to the built in DIR with file sizes and sorting. I noticed after I added it that you included ZXD? another DIR replacement. To me, LS is only superior in that it is well named and easy to use. Happy to remove it if you want.

I have seen LS used frequently by others, so probably worth having it as a common directory listing alternative. Let's keep it.

• Let me do some more research on the decompression programs. I included USQ to decompress Squeezed files vs UNCR which is for Crunched files but maybe it supports both formats? This is an area where I don't have the history with the file formats or programs.

I am not that well versed in the compression tools either. I had the impression that UNCR was a more recent tool and was somewhat more comprehensive that USQ. With that said, I welcome your research and we can adjust depending on what you find.

• LSWEEP does do the same as NULU but in different ways, it is down to preference. I figured that the HD images have room so I wanted to give people the tools they are familiar with. Happy to not include them though.

OK, keep it.

• I think BBC Basic is important to include for our British and European friends. It could also be a disk image rather than included on the boot disks. It is distributed with sample files that I could include on a disk image. Would you prefer that?

Yes, I see the rationale for including BBC BASIC. It is fine to include generically -- seems too small for an entire disk image.

You just caused me to wonder about something. The 6 new language disk images are all relatively small. You could literally put all 6 on one disk image (with 75% space leftover) and segregate them using user areas. This has pros and cons. It will be easier for someone to just concatenate a single additional slice and get quick access to all of the language tools. However, user areas are not quite as obvious. I would like your thoughts. As an example, the "ws" disk image has the full WordStar distribution in user area 0 and the entire ZDE distribution in user area 1. I am going to rename that disk image to something like "wp" for the word processor disk image and add some other WordStar equivalents (and maybe even SuperCalc).

Hope all this isn't too much work for you 😉

Pretty sure you are doing all the work! I am very happy to have more disk images added. That was always a goal.

Thanks,

Wayne

[rprouse]

I added a checklist to the initial PR description above so that we don't lose track of any of the threads.

User Areas

You just caused me to wonder about something. The 6 new language disk images are all relatively small. You could literally put all 6 on one disk image (with 75% space leftover) and segregate them using user areas. This has pros and cons. It will be easier for someone to just concatenate a single additional slice and get quick access to all of the language tools. However, user areas are not quite as obvious. I would like your thoughts. As an example, the "ws" disk image has the full WordStar distribution in user area 0 and the entire ZDE distribution in user area 1. I am going to rename that disk image to something like "wp" for the word processor disk image and add some other WordStar equivalents (and maybe even SuperCalc).

User areas are something that I find very frustrating, but maybe it is my inexperience with CP/M. Using the OS with the least features, CP/M 2.2 I find that user areas are nearly unusable. Maybe it can be set up properly, but my experience is,

• You cannot run programs in another user area, you need to copy them in
• You cannot DIR programs in another user area, you need to switch to the user area first

The documentation that I've read makes me believe that you need to set up each user area as a stand-alone system in CP/M 2.2.

Moving up to ZDOS v1.1, the experience gets a bit better. Programs in A0: run in any user area and you can use DIR A2: to list files in another user area and many newer programs support the disk/user format, but some do not. LS.COM doesn't support it, so we may want to remove it?

I tested several existing programs and some that I added. HI-TECH works fine, but AZTEC C fails at the link stage unless you copy C.LIB into your user space. Many other programs work fine if the program is in another user and the data file is in the current user but not the other way around.

I'm curious, how do you use users and do you experience the same friction? It seems okay in the newer operating systems, but nearly unworkable in CP/M 2.2.

Decompression utilities

Everything I know about CP/M archive and compression formats I learned from Lawrence Woodman's blog posts Compression and Archiving on CP/M and Working with .LBR files on CP/M.

In the first post, he states,

The first compression formats on CP/M only compressed single files and would change the middle letter of the file extension to signify that the file had been compressed.

.?Q?
Squeeze was an early compression format that used Huffman encoding to compress files. These can be squeezed (compressed) with sq and unsqueezed (decompressed) with usq.
.?Z?
Crunch brought LZW compression to CP/M and these files can be handled with crunch.
.?Y?
These files, using LHA compression, were relatively uncommon. They can be handled with crlzh or my favourite for just decompressing is uncr.

He mentions here that UNCR works for LHA files so I tested it on a Squeezed file and it works. I will remove USQ.COM since it is redundant.

[wwarthen]

I added a checklist to the initial PR description above so that we don't lose track of any of the threads.

Good idea, thanks.

User Areas

User areas are something that I find very frustrating, but maybe it is my inexperience with CP/M. Using the OS with the least features, CP/M 2.2 I find that user areas are nearly unusable. Maybe it can be set up properly, but my experience is,

• You cannot run programs in another user area, you need to copy them in
• You cannot DIR programs in another user area, you need to switch to the user area first

The documentation that I've read makes me believe that you need to set up each user area as a stand-alone system in CP/M 2.2.

You are right with respect to CP/M 2.2. The user area concept morphed over time from being a per-user thing to a poor version of subdirectories.

Moving up to ZDOS v1.1, the experience gets a bit better. Programs in A0: run in any user area and you can use DIR A2: to list files in another user area and many newer programs support the disk/user format, but some do not. LS.COM doesn't support it, so we may want to remove it?

Yup, ZSDOS and ZCPR embraced the idea of using user areas for file organization instead of actual different users. I am OK either way on LS. It would not be the only program that is not user area aware. Your call.

I tested several existing programs and some that I added. HI-TECH works fine, but AZTEC C fails at the link stage unless you copy C.LIB into your user space. Many other programs work fine if the program is in another user and the data file is in the current user but not the other way around.

You have done more in this area than me. I suspect that it will depend on which OS you use and way you set up search paths. Your comments are certainly applicable to CP/M 2.2.

I'm curious, how do you use users and do you experience the same friction? It seems okay in the newer operating systems, but nearly unworkable in CP/M 2.2.

Personally, I made the mental switch to thinking about user areas as a way to organize files a long time ago. However, as a result, I rarely use CP/M 2.2. It is definitely not my intent for RomWBW to leave CP/M 2.2 behind, so I do care about the difficulty of working with user areas in CP/M 2.2.

In the end, you are the one putting the disk images together. As such, I leave this decision to you and your preferences since you can easily argue one way or the other. I brought it up only to be sure you are aware of the option. 😀

Decompression utilities

Everything I know about CP/M archive and compression formats I learned from Lawrence Woodman's blog posts Compression and Archiving on CP/M and Working with .LBR files on CP/M.

These are excellent descriptions and summaries of the formats. I had not seen these before. Very nice.

In the first post, he states,

The first compression formats on CP/M only compressed single files and would change the middle letter of the file extension to signify that the file had been compressed.

.?Q? Squeeze was an early compression format that used Huffman encoding to compress files. These can be squeezed (compressed) with sq and unsqueezed (decompressed) with usq. .?Z? Crunch brought LZW compression to CP/M and these files can be handled with crunch. .?Y? These files, using LHA compression, were relatively uncommon. They can be handled with crlzh or my favourite for just decompressing is uncr.

He mentions here that UNCR works for LHA files so I tested it on a Squeezed file and it works. I will remove USQ.COM since it is redundant.

Thanks for checking this. Yes, since UNCR handles LHA files, I agree with removing USQ.COM.

I feel that the questions related to user areas and common files have been discussed adequately. Go ahead as you see fit. It is not hard to adjust things later if there are issues.

Thanks!

Wayne

[wwarthen]

Regarding adding some of the new common files to the floppy disk images, I think that will be problematic. I have previously had to hand tune some of the floppy files to make things fit.

I note that there are some floppy images that have lots of extra room and some that are near capacity. If you want, you could add new common files to those floppy images where they would fit. Just understand I may need to tweak them in the future.

Thanks,

Wayne

[rprouse]

Personally, I made the mental switch to thinking about user areas as a way to organize files a long time ago. However, as a result, I rarely use CP/M 2.2. It is definitely not my intent for RomWBW to leave CP/M 2.2 behind, so I do care about the difficulty of working with user areas in CP/M 2.2.

I am also moving away from CP/M 2.2 but it was where I was comfortable when I first moved from a standard RC2014 computer, so it is important to me to maintain compatibility for people like me. I think we can have our cake and eat it too though. What if I continue to create individual disks for people that want to work that way. Then people can just mount the tools they are interested in using or create individual floppies.

I can then build another d_devtools disk with each of the tools in a user area for non-CP/M users so they just need to mount one disk to get all the tools. Before I commit to this, I will test how each tool works outside of user area 0. I know Aztec has issues, so I can drop it in 0, but there may be others.

Regarding adding some of the new common files to the floppy disk images, I think that will be problematic. I have previously had to hand tune some of the floppy files to make things fit.

I tried just adding BBC Basic and it was too large for several of the floppies. I'll abandon that idea 😄

[wwarthen]

I am also moving away from CP/M 2.2 but it was where I was comfortable when I first moved from a standard RC2014 computer, so it is important to me to maintain compatibility for people like me. I think we can have our cake and eat it too though. What if I continue to create individual disks for people that want to work that way. Then people can just mount the tools they are interested in using or create individual floppies.

I can then build another d_devtools disk with each of the tools in a user area for non-CP/M users so they just need to mount one disk to get all the tools. Before I commit to this, I will test how each tool works outside of user area 0. I know Aztec has issues, so I can drop it in 0, but there may be others.

Honestly, I think having both variations is going to cause more confusion than it is worth. Just go with the approach you prefer.

I tried just adding BBC Basic and it was too large for several of the floppies. I'll abandon that idea 😄

Yeah, not surprised. Someday, I may need to rethink my approach to the floppies. For now, it is what it is.

Thanks,

Wayne

[rprouse]

Honestly, I think having both variations is going to cause more confusion than it is worth. Just go with the approach you prefer.

In that case, I think we should go for a disk per tool so that it is available to the most people with the least confusion. With that, all outstanding questions have been answered and this PR is ready for a final review.

[feilipu]

I am also moving away from CP/M 2.2 but it was where I was comfortable when I first moved from a standard RC2014 computer, so it is important to me to maintain compatibility for people like me.

Since I'm listening, I'd like to add my 2 cents for CP/M 2.2.

There's so much "free" disk capacity available these days, there's really no valid trade off between sparse disks and usability.

So imho just keep one slice / disk per theme or topic in 0: user area for CP/M 2.2. Common files can be repeated as desired. This costs nothing to do.

FWIW, I tend to use a slice / disk per project, much like a directory.

[wwarthen]

I am also moving away from CP/M 2.2 but it was where I was comfortable when I first moved from a standard RC2014 computer, so it is important to me to maintain compatibility for people like me.

Since I'm listening, I'd like to add my 2 cents for CP/M 2.2.

There's so much "free" disk capacity available these days, there's really no valid trade off between sparse disks and usability.

So imho just keep one slice / disk per theme or topic in 0: user area for CP/M 2.2. Common files can be repeated as desired. This costs nothing to do.

FWIW, I tend to use a slice / disk per project, much like a directory.

Thanks for the input Phillip. I think your preferences are where we have wound up. 😀

[wwarthen]

Honestly, I think having both variations is going to cause more confusion than it is worth. Just go with the approach you prefer.

In that case, I think we should go for a disk per tool so that it is available to the most people with the least confusion. With that, all outstanding questions have been answered and this PR is ready for a final review.

All good. Merging now.

Thank you for all the work on this!

-Wayne

[rprouse]

Happy to do it. If there is other work or other packages that you want to see, I'm always happy to help. Just open an issue and tag me.