Update CLRDIR

Update CLRDIR with minor update from the author Max Scane to emphasize the need to type a capital Y to proceed.  Thanks and credit to Max Scane for this application.

Adds CLRDIR to the Applications document.

Source/Doc/Applications.md

@@ -48,8 +48,9 @@ found:
 | RTC         | Yes      | Yes        | Yes      |
 | TIMER       | Yes      | Yes        | Yes      |
 | CPUSPD      | Yes      | Yes        | Yes      |
+| FAT         | Yes      | Yes        | Yes      |
+| CLRDIR      | Yes      | Yes        | Yes      |
 | INTTEST     | No       | Yes        | Yes      |
-| FAT         | No       | Yes        | Yes      |
 | TUNE        | No       | Yes        | Yes      |
 | WDATE       | No       | Yes        | Yes      |
 | HTALK       | No       | Yes        | Yes      |
@@ -545,7 +546,7 @@ distribution in the Doc/Contrib directory.
 The application supports a significant number of EEPROM parts. It
 should automatically detect your part. If it does not recognize your
 chip, make sure that you do not have a write protect jumper set --
-this jumper can prevent the ROM chip from being recognized.
+this jumper will prevent the ROM chip from being recognized.
 
 Reprogramming a ROM chip in-place is inherently dangerous. If anything
 goes wrong, you will be left with a non-functional system and no
@@ -921,6 +922,15 @@ Files written are not verified.
 Wildcard matching in FAT filesystems is a bit unusual as implemented by
 FatFs. See FatFs documentation.
 
+The `FAT FORMAT` command will not perform a physical format on floppy 
+disks.  You must use FDU to do this prior to using `FAT FORMAT`.
+
+Formatting (`FAT FORMAT`) of floppies does not work well.  The    
+underlying FatFs library uses some non-standard fields.  The resulting 
+floppy may or may not be useable on other systems.  It is best to format
+a FAT floppy on a Windows or DOS system.  You should have no problems 
+copying files to/from such a floppy using `FAT`.
+
 ## Etymology
 
 The `FAT` application is an original RomWBW work, but utilizes the
@@ -953,6 +963,60 @@ can corrupt a file if it occurs.  Be careful to avoid this.
 
 `\clearpage`{=latex}
 
+# CLRDIR
+
+`CLRDIR` is used to initialize a CP/M filesystem.  This is frequently
+used to prepare RomWBW disk slices for use.  If there is any data
+on the filesystem, it will be destroyed.  `CLRDIR` works on CP/M
+drive letters.  To initialize a RomWBW slice, the slice must first be
+assigned to a CP/M drive letter.
+
+
+This application is provided by Max Scane.
+
+## Syntax
+
+| `CLRDIR `*`<drive>`*` [options]`
+
+*`<drive>`* is the CP/M drive letter to be cleared (e.g., "A:")
+
+
+Options:
+
+| `-D`: Enable debug output
+| `-Y`: Do not ask for confirmation
+
+## Usage
+
+This application has a command line interface only.  Type an 
+appropriately formatted command at the command prompt at any of the 
+RomWBW CP/M operatings systems (CP/M 2.2, ZSDOS, CP/M 3, etc.).
+
+You will be prompted for confirmation to continue.  You must type a
+**capital** 'Y' to proceed.  The application will confirm that the
+drive has been cleared.
+
+If used under ZSDOS, you should issue a `RELOG` command after using
+`CLRDIR` to ensure that CP/M relogs the cleared drive.
+
+## Notes
+
+This command is inherently dangerous.  It will completely destroy the
+directory area of the target drive.  Be very careful to ensure you do
+not target a drive that contains useful data.
+
+`CLRDIR` understands the directory formats of all of the RomWBW
+CPM-like operating systems and devices including floppy disks, CF/SD
+Cards, etc.
+
+## Etymology
+
+This application was written and provided by Max Scane. He
+provides it in binary format and is included in the RomWBW
+distribution as a binary file.
+
+`\clearpage`{=latex}
+
 # TUNE
 
 If your RomWBW system has a sound card based on either an AY-3-8190 or

Source/Doc/UserGuide.md

@@ -1118,11 +1118,11 @@ system.
 
 The drive letter assignments **do not** change during an OS session 
 unless you use the `ASSIGN` command yourself to do it. Additionally, the
- assignments at boot will stay the same on each boot as long as you do 
+assignments at boot will stay the same on each boot as long as you do 
 not make changes to your hardware configuration. Note that the 
 assignments **are** dependent on the media currently inserted in hard 
 disk drives when the operating system is started. So, notice that if you
- insert or remove an SD Card, CF Card or USB Drive, the drive 
+insert or remove an SD Card, CF Card or USB Drive, the drive 
 assignments will change. Since drive letter assignments can change, you 
 must be careful when doing destructive things like using `CLRDIR` to 
 make sure the drive letter you use is referring to the desired media.
@@ -1513,10 +1513,10 @@ B>assign
    H:=IDE0:3
 
 B>clrdir G:
-CLRDIR Version 1.2 April 2020 by Max Scane
+CLRDIR Version 1.2B May 2024 by Max Scane
 
 Warning - this utility will overwrite the directory sectors of Drive: G
-Type Y to proceed, any key other key to exit. Y
+Type CAPITAL Y to proceed, any key other key to exit. Y
 Directory cleared.
 B>
 ```
@@ -1993,10 +1993,12 @@ custom hard disk image file, it will need to be written to the media
 using your modern computer.  Note that you **do not** run `CLRDIR` or 
 `SYSCOPY` on the slices that contain the data.  When using this method, 
 the disk will be partitioned and setup with 1 or more slices containing 
-ready-to-run bootable operating systems.
+ready-to-run bootable operating systems.  You **do** need to run
+`CLRDIR` and optionally `SYSCOPY` on slices that are not part of the
+image (slices beyond the ones included with the image).
 
 To write a hard disk image file onto your actual media (actual hard disk
- or CF/SD/USB Media), you need to use an image writing utility on your 
+or CF/SD/USB Media), you need to use an image writing utility on your 
 modern computer. Your modern computer will need to have an appropriate 
 interface or slot that accepts the media. To actually copy the image, 
 you can use the `dd` command on Linux or MacOS. On Windows, in the 

Source/HBIOS/hbios.asm

@@ -22,27 +22,25 @@
 ;   SYSTEM INITIALIZATION, THE IMAGE OF THE RUNNING ROM BANK IS COPIED TO A RAM BANK
 ;   CREATING A SHADOW COPY IN RAM.  EXECUTION IS THAN TRANSFERRED TO THE RAM SHADOW COPY.
 ;   THIS IS ESSENTIAL BECAUSE THE HBIOS CODE DOES NOT SUPPORT RUNNING IN READ ONLY MEMORY
-;   (EXCEPT FOR THE INITIAL LAUNCHING CODE).  IN THIS MODE, THE HBI OS INITIALIZATION WILL
-;   ALSO COPY THE OS IMAGES BANK IN ROM TO THE USER RAM BANK AND LAUNCH IT AFTER HBIOS
-;   IS INSTALLED.
+;   (EXCEPT FOR THE INITIAL LAUNCHING CODE).
 ;
 ; - APPBOOT: BOOT FROM A CP/M STYLE APPLICATION FILE
 ;
 ;   WHEN APPBOOT IS DEFINED, THE FILE IS ASSEMBLED AS A CP/M APPLICATION ASSUMING
 ;   THAT IT WILL BE LOADED AT 100H BY THE CP/M (OR COMPATIBLE) OS.  NOTE THAT IN
 ;   THIS CASE IT IS ASSUMED THAT AN OS IMAGES FILE IS APPENDED TO THE END OF THE
-;   HBIOS APPLICATION BINARY.  THE APPENDED OS IMAGES ARE COPIED TO THE USER RAM
+;   HBIOS APPLICATION BINARY.  THE APPENDED OS IMAGES ARE COPIED TO THE AUX RAM
 ;   BANK AND LAUNCHED AFTER HBIOS HAS INSTALLED ITSELF.
 ;
-; - IMGBOOT: BOOT FROM AN IMAGE FILE THAT HAS BEEN PLACED IN THE USER BANK
-;
-;   WHEN IMGBOOT IS DEFINED, THE FILE IS ASSEMBLED SUCH THAT IT CAN BE PRELOADED
-;   INTO THE RAM USER BANK BY AN EXTERNAL PROCESS THAT SUBSEQUENTLY LAUNCHES
-;   THE CODE AT ADDRESS 0.  THE MOST COMMON EXAMPLE OF THIS IS THE UNA FSFAT
-;   TOOL WHICH CAN LOAD AN IMAGE FROM A DOS FAT FILESYSTEM PROVIDING A SIMPLE
-;   WAY TO LOAD A TEST COPY OF HBIOS.  AS IS THE CASE WITH APPBOOT, IT IS ASSUMED
-;   THAT AN OS IMAGES FILE IS APPENDED TO THE END OF THE IMAGE AND IS LAUNCHED
-;   AFTER HBIOS IS INSTALLED.
+;;;; - IMGBOOT: BOOT FROM AN IMAGE FILE THAT HAS BEEN PLACED IN THE USER BANK
+;;;;
+;;;;   WHEN IMGBOOT IS DEFINED, THE FILE IS ASSEMBLED SUCH THAT IT CAN BE PRELOADED
+;;;;   INTO THE RAM USER BANK BY AN EXTERNAL PROCESS THAT SUBSEQUENTLY LAUNCHES
+;;;;   THE CODE AT ADDRESS 0.  THE MOST COMMON EXAMPLE OF THIS IS THE UNA FSFAT
+;;;;   TOOL WHICH CAN LOAD AN IMAGE FROM A DOS FAT FILESYSTEM PROVIDING A SIMPLE
+;;;;   WAY TO LOAD A TEST COPY OF HBIOS.  AS IS THE CASE WITH APPBOOT, IT IS ASSUMED
+;;;;   THAT AN OS IMAGES FILE IS APPENDED TO THE END OF THE IMAGE AND IS LAUNCHED
+;;;;   AFTER HBIOS IS INSTALLED.
 ;
 ; INCLUDE FILE NESTING:
 ;
@@ -1423,15 +1421,32 @@ BOOTWAIT:
 ; Z280 BARE METAL INIT
 ;
 #IF (CPUFAM == CPU_Z280)
+	; CLEAR THE MASTER STATUS REGISTER
+	LD	C,Z280_MSR		; MASTER STATUS REGISTER
+	LD	HL,$0000		; SYS MODE, NO INTERRUPTS
+	LDCTL	(C),HL			; DO IT
+;	
 	; SET MAXIMUM I/O WAIT STATES FOR NOW
 	LD	C,Z280_BTCR		; BUS TIMING AND CONTROL REGISTER
 	LD	HL,$0033		; 3 I/O WAIT STATES ADDED
-	LDCTL	(C),HL
+	LDCTL	(C),HL			; DO IT
 ;
-	; START BY SELECTING I/O PAGE $FF
+	; SELECT I/O PAGE $FF FOR INTERNAL SYSTEM REGISTER ACCESS
 	LD	L,$FF			; MMU AND DMA PAGE I/O REG IS $FF
 	LD	C,Z280_IOPR		; REG C POINTS TO I/O PAGE REGISTER
-	LDCTL	(C),HL
+	LDCTL	(C),HL			; DO IT
+;
+	; DISABLE MEMORY REFRESH CYCLES
+	LD	A,$08			; REFRESH DISABLED
+	OUT	(Z280_RRR),A		; DO IT
+;
+	; INITIALIZE CACHE CONTROL REGISTER
+	LD	A,$20			; CACHE INSTRUCTIONS, NOT DATA
+	OUT	(Z280_CCR),A		; DO IT
+;
+	; INITIALIZE TRAP CONTROL REGISTER
+	LD	A,$00			; ALLOW USER I/O, NO EPU, NO STK WARN
+	OUT	(Z280_TCR),A		; DO IT
 ;
   #IF (MEMMGR == MM_Z280)
 ;
@@ -1468,10 +1483,6 @@ BOOTWAIT:
 	LD	C,Z280_MMUMCR		; MMU MASTER CONTROL REGISTER
 	LD	HL,$BBFF		; ENABLE USER & SYSTEM TRANSLATE
 	OUTW	(C),HL
-;
-	; DISABLE MEMORY REFRESH CYCLES
-	LD	A,$08			; DISABLED
-	OUT	(Z280_RRR),A		; SET REFRESH RATE REGISTER
 ;
 	JR	Z280_INITZ		; JUMP TO CODE CONTINUATION
 ;
@@ -1505,7 +1516,7 @@ Z280_INITZ:
 ;
   #ENDIF
 ;
-	; RESTORE I/O PAGE TO $00
+	; RESTORE I/O PAGE TO $00 FOR NORMAL USER I/O SPACE
 	LD	L,$00			; NORMAL I/O REG IS $00
 	LD	C,Z280_IOPR		; REG C POINTS TO I/O PAGE REGISTER
 	LDCTL	(C),HL
@@ -2917,17 +2928,26 @@ HB_Z280BUS1:
 	PRTS("BTCR=$")
 	LD	C,Z280_BTCR		; BUS TIMING AND CONTROL REGISTER
 	LDCTL	HL,(C)
-	CALL	PRTHEXWORDHL
+	LD	A,L
+	CALL	PRTHEXBYTE
 	CALL	PC_SPACE
 	PRTS("BTIR=$")
 	LD	C,Z280_BTIR		; BUS TIMING AND CONTROL REGISTER
 	LDCTL	HL,(C)
-	CALL	PRTHEXWORDHL
+	LD	A,L
+	CALL	PRTHEXBYTE
 	CALL	PC_SPACE
 	PRTS("CCR=$")
 	LD	C,Z280_CCR		; CACHE CONTROL REGISTER
 	LDCTL	HL,(C)
-	CALL	PRTHEXWORDHL
+	LD	A,L
+	CALL	PRTHEXBYTE
+	CALL	PC_SPACE
+	PRTS("TCR=$")
+	LD	C,Z280_TCR		; CACHE CONTROL REGISTER
+	LDCTL	HL,(C)
+	LD	A,L
+	CALL	PRTHEXBYTE
 #ENDIF
 ;
 #IFDEF ROMBOOT
@@ -3326,32 +3346,28 @@ DBG_NOTE:
 ;
 #ENDIF
 ;
+#IFDEF TESTING
+	CALL	SND_BEEP
+#ENDIF
+;
 INITSYS4:
 ;
 #IF (MEMMGR == MM_Z280)
-	; LEAVE SYSTEM MODE STACK POINTING TO AN OK PLACE
-	LD	SP,HB_STACK		; NOW USE REAL SYSTEM STACK LOC
-;
-	HB_DI				; NOT SURE THIS IS NEEDED
+	; LEAVE SYSTEM MODE STACK POINTING TO THE RIGHT PLACE
+	LD	SP,HB_STACK		; DEDICATED HBIOS STACK LOC
 ;
 	; ACTIVATE THE CORRECT USER MODE BANK
 	LD	A,(HB_CURBNK)		; GET CURRENT BANK
-	CALL	HBX_BNKSEL
+	CALL	HBX_BNKSEL		; DO IT
 ;
 	; PRESET THE USER MODE STACK
-	LD	HL,HBX_LOC
-	LDCTL	USP,HL
-;
-	HB_EI				; NOT SURE THIS IS NEEDED
+	LD	HL,HBX_LOC		; USER STACK JUST BELOW PROXY
+	LDCTL	USP,HL			; DO IT
 ;
 	; SWITCH TO USER MODE NOW
-	LD	C,Z280_MSR
-	LD	HL,$407F
-	LDCTL	(C),HL
-#ENDIF
-;
-#IFDEF TESTING
-	CALL	SND_BEEP
+	LD	C,Z280_MSR		; MASTER STATUS REGISTER
+	LD	HL,$4000 | $0B		; USER MODE W/ NORMAL INT MASK
+	LDCTL	(C),HL			; DO IT
 #ENDIF
 ;
 	DIAG(0)				; CLEAR BOOT DIAG LED(S)
@@ -5911,23 +5927,31 @@ Z280_PRIVINST:
 	EX	(SP),HL			; GET ADR, SAVE HL
 ;
 	PUSH	AF
-	PUSH	BC
-	PUSH	DE
+	PUSH	BC			; NEEDED?
+	PUSH	DE			; NEEDED?
 ;
 	LDUP	A,(HL)			; BYTE FROM USER SPACE
 ;
-	; HANDLE DI
+	; HANDLE USER MODE Z80 DI
 	CP	$F3			; DI?
 	JR	NZ,Z280_PRIVINST2
-	HB_DI				; DO THE DI
+
+	;;;HB_DI			; DO THE DI
+	XOR	A			; NO INTERRUPTS
+	LD	(HB_MSRSAV),A		; UPDATE SAVED MSR LSB
+	
 	INC	HL			; BUMP PAST IT
 	JR	Z280_PRIVINSTX
 ;
 Z280_PRIVINST2:
-	; HANDLE EI
+	; HANDLE USER MODE Z80 EI
 	CP	$FB			; EI?
 	JR	NZ,Z280_PRIVINST3
-	HB_EI				; DO THE EI
+
+	;;;HB_EI			; DO THE EI
+	LD	A,$0B			; NORMAL INTERRUPTS
+	LD	(HB_MSRSAV),A		; UPDATE SAVED MSR LSB
+
 	INC	HL			; BUMP PAST IT
 	JR	Z280_PRIVINSTX
 ;
@@ -5954,8 +5978,8 @@ Z280_PRIVINST4:
 ;
 Z280_PRIVINSTX:
 	; RESTORE REGISTERS
-	POP	DE
-	POP	BC
+	POP	DE			; NEEDED?
+	POP	BC			; NEEDED?
 	POP	AF
 ;
 	; RECOVER HL AND MSR, THEN RETURN VIA RETIL

Source/RomDsk/ReadMe.txt

@@ -9,10 +9,15 @@
 This is the parent directory for all files to be included in the ROM
 Disk when a ROM is built.
 
-When constructing the ROM disk as part of a build, the build process
+When constructing the ROM Disk as part of a build, the build process
 first grabs all of the "standard" files for the size of ROM being
-built.  So, if you are building a normal 512KB ROM, all of the files
-in ROM_512KB directory will be pulled in.
+built.  Note the table at the bottom of this file which indicates
+the size of the ROM Disk that will be created depending on
+the size of your ROM chip and the boot type of your system.  The
+size of your ROM Disk determines which sub-folder will be used to
+pull in your files.  For example, if you are using a typical 512KB
+ROM chip and a normal ROM Boot process, you will have a 384KB ROM
+Disk and the files will come from the ROM_384KB sub-folder.
 
 You may freely add/delete/update the files in these directories to
 change the contents of the ROM Disk of your ROM firmware.
@@ -27,16 +32,22 @@ BuildROM script:
 The resulting ROM Disk is still OK to use, but will not contain the
 file(s) that did not fit.
 
-RomWBW also supports the concept of a "ROMless" system in which an
-external bootstrap pre-loads the RAM.  The RAM_xxxKB directories
-contain the files to be used for such systems.  Note the size of the
-RAM disk on a 512KB ROMless system is not the same as the RAM disk
-on a normal system.  This is due to different bank layout and overhead.
+The table below indicates the size of the ROM Disk that you will
+have based on your ROM chip size and boot type.  The common boot
+type is a ROM Boot where your system boots from code on the ROM.
+Alternatively, some systems provide a ROMless boot where the
+code is loaded from somewhere else (typically a disk or CF/SD Card).
+In this case, you actually have no ROM disk, but instead you get
+a pre-loaded RAM disk.
 
-System		ROM Disk Image		RAM Disk Image
-------		--------------		--------------
-128KB		n/a			n/a
-256KB		128KB ROM Disk		n/a
-512KB		384KB ROM Disk		256KB RAM Disk
-1024KB		896KB ROM Disk		768KB RAM Disk ???
-2048KB		n/a			1792KB RAM Disk ???
+A normal ROM Boot system will have a ROM Disk that is 128KB less
+than the size of the ROM chip.  A ROMless Boot system will have a
+ROM Disk that is 256KB less than the size of the ROM chip.
+
+ROM Chip	ROM Boot	ROMless Boot
+--------------	--------------	--------------
+128KB		n/a		n/a
+256KB		128KB ROM Disk	n/a
+512KB		384KB ROM Disk	256KB RAM Disk
+1024KB		896KB ROM Disk	768KB RAM Disk
+2048KB		n/a		1792KB RAM Disk

Source/ver.inc

@@ -2,7 +2,7 @@
 #DEFINE	RMN	5
 #DEFINE	RUP	0
 #DEFINE	RTP	0
-#DEFINE BIOSVER	"3.5.0-dev.34"
+#DEFINE BIOSVER	"3.5.0-dev.35"
 #define rmj	RMJ
 #define rmn	RMN
 #define rup	RUP

Source/ver.lib

@@ -3,5 +3,5 @@ rmn	equ	5
 rup	equ	0
 rtp	equ	0
 biosver	macro
-	db	"3.5.0-dev.34"
+	db	"3.5.0-dev.35"
 	endm