You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for
.COM files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (
.EXE usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with
DEVICE instead of
DEVICEHIGH, and without
LOADHIGH for TSRs). If your upper memory is split into multiple blocks, you can tell
LOADHIGH which block to use with the
/L parameter (
/L:1,10240 will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than
CONFIG.SYS — this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use
MEMMAKER to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like
SHSUCD instead of
NNANSI instead of
ANSI.SYS. Using 4DOS instead of
COMMAND.COM will provide better control over upper memory use, and allow you to drop
DOSKEY (along with all the nice command-line features of 4DOS).