Anyhow, the public demand to understand how a new directory is created in the Cyborg/HM*Mod of C*Base running on c64 Original ChipSet is quite high (that is, Harzilein and Dr.Doom asked). Thus, before I likely migrate the Boar's Head Tavern to the Larry*Mod of C*Base and run it on an Ultimate64 (Gideon Zweijtzer), I was asked to document it. The reason for that expected migration is mainly because the soon 45 year old chips are getting increasingly unstable running 24/7 (firsthand especially from temperature/seasonal changes), and because of the daily time consuming labour of managing uploads due to the "clusters interpreted as blocks on SD2IEC"-issue in the old C*Base. That manual work of zen routine could have be explained elsewhere (but might probably be deduced from what is written a few paragraphs further down).
One needs to understand that when the user reads the directory in C*base ("$") they are not shown the actual files in the partition/folder, but rather a file that is created by C*Base which does not include certain hidden things. That file, UD-#, is regenerated* after each upload. The SysOp (and CoSysOp) can venture behind the scenes though, and access the real directory with the actual files, going into Exchange Mode. Totally doable on a 1MHz and 64K of RAM machine, also at 2400 baud if necessary.
The bigger and longer that UD-#-file becomes, the clumsier the system gets. For that reason, since I launched the bulletin board and resurrected the Boar's Head Tavern, I have needed to clear the directory for fresh stuff every 9-12 months or so. This time dir#1 (called Young Malts) had reached 617 files since July last year, and the daily zen routine was getting very slow. Consequently Young Malts needed to become "emptied into" dir#9 (Hormuz):
First the entire system gets a backup and then a new partition is created. Back in C*Base a few lines in STATS need to have their parameters rewritten and pointers to the new directory added. As I have had the old c64 system crashing numerous times (ofttimes with the need for rehacking) I now know STATS by heart, but otherwise I would suggest the C*Base v3.1 Holy Moses Mod Guide for SysOps. Files can easily be moved from the Young Malts- to the Hormuz-folder, and protocol-files copied from the other partitions, but the HM*Mod will not accept that the UD-#-file just gets renamed (i.e. UD-1 to UD-9), at least not under SD2IEC (and likely because of a similar interpretational error - fixed in Larry*Mod I am told). One needs to regenerate a new directory-file (both in dir#1 and in this case, in dir#9) with the correct command. Where dir#1 is empty as it should be, and ready for fresh and hot warez, dir#9 also seems empty for the common user. That is because UD-9 has not been populated.
Alas, now this old beauty really does show its turpitude. 617 files via Exchange Mode to UD-9, and experience has told me that more than 60 files at a time causes the system to crash. Initially the process goes quite fast, a few seconds per file, but soon 15 and 30 and 45 seconds per file. When the final batches of 60 files/sizes are added to the UD-file, they usually take an hour or so each.
Meanwhile, this one-node SoMe is of course down and no carrier is available. Plentiful eager nerds (including Cjam) do not fret though, they will have a few pints and try again later.
The Boar's Head Tavern is now invigorated and ready for another summer of 64.
*Update 230526: Larry informed me that if a person uploads a file to any of the BBS directories, information about that file is written (added!) to the corresponding sequential file called UD-#. Thus it is not rebuilt each time a new file is added. Any 3.x C*BASE version adds the following info to the file per new upload: call number, current date, filename, filetype (PRG or SEQ), file size in blocks. Some versions also add an optional file description to be written by the user uploading.
Fun fact: The amount of disk blocks for a file is calculated in the BBS by subtracting free blocks after successful upload from free disk blocks before upload (stored in a variable). For this reason it will not work on media which does not report free blocks. This is changed in his modification to what CoSysOp and myself currently perform by hand as the zen routine.





















