[Coco] VCC Update

Thu Apr 13 14:31:05 EDT 2017

Luis, I think you are completely misunderstanding the way the MPI works. If you replace the "Cartridge" MPI.dll with a cart, yes it will go away. In essence the same as unplugging an MPI and inserting a cartridge, which is correct.
When the MPI.dll is inserted, it has 4 "slots" in the dropdown menu, just as a real MPI does. You can put up to 4 carts there and select them the MPI Config (here, the MPI does NOT go away). Just as the MPI is supposed to work.
This is how a regular Coco works, and how VCC actually does work.
I do not see any need for change in this behavour as it emulates the way the real Coco and MPI work.

Yes, the "xxxx.ccc" extension was not a standard for carts when Joseph wrote the original VCC and was overlooked in the update. Make sure you start an "issue" on the VCC github site for this, so it will be remembered when someone finally works on it. It would be a minor update and I may just do the change in the near future (no time at the moment).

I think the size difference of the old VCC and the new is most likely caused by the larger library packages used by VS 2015. The original VCC was compile with "Visual C++ 6" which was Win95/Win XP platform. Also, in the download package, there is a VCC PDF manual as well. Most people miss this, even though there's a link installed in the Start menu that opens the manual.

Multiple languages and keymaps would be nice, but in my opinion, adding a multitude major of enhancements to the present code will only complicate the process of making the code "cross-compliable". Just more stuff to have to change. Once the code is cross-compliable, then it should be easy to add new features. I have a ton of them I would like to see in VCC but lack the programming knowledge to do so. Personally, I am happy with just the Windows version and would gladly keep updating this version with new features, but the point of this project was cross-compilability, so I'm trying to stick with that goal.
There is actually a better version of VCC in the github repo (with a few fixes), but the Becker Port DLL didn't work, so it was put on hold until this was fixed. That was about the same time the programmers disappeared. This is actually the "Master" branch. The current VCC is compiled using the "VCC-1.200b" branch, which is stable.

There were people in the beginning who were working on making it cross-compliable for Windows, Linux, Mac, and possibly Android, but they had real life matters and the project slowly came to a halt. All that was really accomplished was moving from the old VS C++ platform to the VS 2015 platform which did make it compatible on modern machines and a little restructuring of the code base in prep for making it cross-compile.

Just so everyone knows, I DO NOT PROGRAM VCC. This was done (originally) by Joseph Forgione, then By 2 other programmers (recently) in the upgrade. I was Joseph's first contact when he came out of the woodwork and made the project "open source", so he made me an administrator (lucky me), then he disappeared again, leaving me holding the snake.
I welcome anyone wanting to work on the project, but prefer they clone the repo in their own github repository, and submit "pulls" to be reviewed. This keeps the current (read working) version intact and doesn't clog up the repo with 20 "experimental" branches going all different directions. If actual progress is shown, then we can start a new branch of experimental stuff to develope and test as a group, but I've yet to see anyone offer anything but "suggestions" of what "should" be done instead of actually doing anything. Suggestions are no good if no one is making them happen.

If James can come up with something that works, I would gladly merge his work into the project. But as it stands, the VCC project is growing stale. We need programmers willing to carry the project into the future.

Bill Pierce
"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
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Luis Fernández <luis46coco at hotmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Thu, Apr 13, 2017 11:04 am
Subject: Re: [Coco] VCC Update

>Hey David ... it can actually take a DLL *OR* a ROM file. If you load a program PAK ROM file directly from the Cartridge | Cartrige drop down menu,  what happens is the MPI functionality goes away and all you have is whatever ROM you loaded booting on power-up. To get the MPI back, you have to load the MPI.DLL from that same drop-down menu.  Then you can load each slot pak the same way ...Yes I knowThe idea is that in any cartridge entry (or NMI) you can choose between * .rom, * .dll, * .pak and * .cccReview what happens from NMII'm just starting to review, and catch up, I do not even know how to handle the project, and I do not want to do anything wrong, or sinpermiso community, but make some changes and ask if this is the way, because as I understood it Bill piece (sometimes I do not understand English well) I think he wants to wait and not make changes until he has a tool to compile cross and so can run VCC on several systems.I think that once put in C or C ++ or C # and can of migrated to several systems, with minimal interface changesBut I just got here and I'm not an expert---------------------------------------------------------------------------------________________________________De: Coco <coco-bounces at maltedmedia.com> en nombre de James Ross <jrosslist at outlook.com>Enviado: jueves, 13 de abril de 2017 02:14 a.m.Para: CoCoList for Color Computer EnthusiastsAsunto: Re: [Coco] VCC UpdateDavid Ladd wrote:> ... VCC only understands DLL's for it's> cart input because of the way the emulator was written.Hey David ... it can actually take a DLL *OR* a ROM file. If you load a program PAK ROM file directly from the Cartridge | Cartrige drop down menu,  what happens is the MPI functionality goes away and all you have is whatever ROM you loaded booting on power-up. To get the MPI back, you have to load the MPI.DLL from that same drop-down menu.  Then you can load each slot pak the same way ...Which, after checking that, I just realized on my current development the MPI slots insert menu item does not bring up the select file dialog.  Will have to look into why.James--Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/cocoCoCoList for Color Computer Enthusiasts - pairlist5.pair.net<https://pairlist5.pair.net/mailman/listinfo/coco>pairlist5.pair.netThis is a list for enthusiasts of the Color Computer in all its forms, its clones, and its software. To see the collection of prior postings to the list ...-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco