[Coco] VCC configuration discussion
ooogalapasooo at aol.com
Thu Jul 7 20:21:57 EDT 2016
Barry, I like the idea of deactivating the "external rom" unless the "becker.dll" is loaded, but that presents a problem (as you noticed).
In the original Vcc 1.42, the main reason for the presence of that feature was to allow the user to load alternate roms for the disk controller I.E. ADOS, CDOS, MYDOS, etc (HDBDOS nor DW were a thing then). Disabling that feature would kill the chance of using alternate roms. Making just HDBDOS "unseeable" until the becker.dll is loaded would just be overkill... and superide.dll uses hdbdos as well....
The idea we've been toying around with is making it all menu selectable, but that will only happen after we get it cross-compilable. The more we add now, the more we have to convert.
The current "installation" does not have "becker.dll" loaded so DW4 is not needed unless you load it, unlike Vcc 1.43b, which required dw4 to be running (obsolete).
We have actually "played around" with the idea of "named Ini" files, but I really think that would just add more confusion.
As I've stated, the current start configuration just starts as a Coco 3, nothing more. It's up to the user to define what they want. You want this, Nick wants that, they all want something else... pretty soon we have 30 ini files and no one knows what they are for (meaning MORE questions). Also, ini files require certain file paths to be "named" and no one keeps these files in the same spot.
In fact, the "vcc.ini" file is not even in the installation as Vcc will create it as soon as you modify something. Vcc just starts at internal default settings (6809, 89mhz, 128k, no overclock, no mpi, no carts) on first run. The same way Vcc 1.42 started.
I really don't get why "special" setup inis are needed. Once the user sets it like they want it, it stays that way. It couldn't be more special than that. Also, more than one instance of Vcc can be installed to different directories, so you can create a Vcc setup for each "special case" you may need.
Personally, I have several installations...
Vcc 6809 512k hdbdos becker
Vcc 6809 2meg hdbdos becker
Vcc 6309 2meg hdbdos becker
Vcc 6809 512k RSDOS disk
All of the becker setups share VHDs through dw4 and all setups can be running at once if needed. I started doing this in developing MShell. I needed to be able to test MShell on various configurations and I didn't want to stop production to reset Vcc to another setup then come back to my development setup and have to reload everything. I just compile MShell, save the execs to the shared VHD, flip windows to the needed setup and run MShell.
As for the documentation... yes, it needs reworking, but like you, I have too many things going and there's no help. I will eventually get around to writing a better manual as the existing one was "thrown" together quickly so I could get it all uploaded for everyone to use. I usually work on docs when I'm burned out on coding for the day and lately, I've done very little coding and even less doc writing. Real life must go on and "baby needs a new pair of snakeskin boots".
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
My Music from the Tandy/Radio Shack Color Computer 2 & 3
Co-Contributor, Co-Editor for CocoPedia
Global Moderator for TRS-80/Tandy Color Computer Forums
E-Mail: ooogalapasooo at aol.com
From: Barry Nelson <barry.nelson at amobiledevice.com>
To: coco <coco at maltedmedia.com>
Sent: Thu, Jul 7, 2016 7:15 pm
Subject: [Coco] VCC configuration discussion
I would have to say that I found the current state of the VCC documentation confusing as well. I also think that the complexity and number of steps could be reduced. I noticed that there is a selection on the VCC menu for RSDOS, RGBDOS and other. Why not add an entry for DriveWire HDBDOS? Something like:DriveWire HDBDOSThis entry should be disabled until the becker port dll is loaded. When the dll is loaded and the HDBDOS rom is selected, have that activate an option for the disk offset to be entered, and have it patch the rom with the entered disk offset after it loads it. I don't think an option is really needed for the speed poked rom, there are other ways to speed up a VCC emulated CoCo, but if it is needed I guess that could be added. You can still leave the option for "other" so a custom disk rom could be loaded. Another idea would be to have prebuilt ini files already configured with common defaults that could be selected and loaded. In addition to making the configuration more user friendly, updated documentation is needed, both for VCC and DriveWire. I have been meaning to write something myself but other priorities have temporarily gotten in the way. What does everyone here think? Which option or combination of options makes the most sense? Personally I rarely use the DriveWire support in VCC, although I have setup it up and gotten it running, I find it cumbersome to have to start up the DriveWire server whenever I want to run VCC, so I usually use RGBDOS and the local vhd file with VCC. That way I only need to startup one program. I do lose support for the virtual serial port under OS9/NitrOS9 though, but I would rather have a rs232.dll that emulated a rs232 pak with a modem attached. The "modem" could "dial" ip addresses and ports like DriveWire does.-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
More information about the Coco