The VCC code base is currently made up of a hybrid of C files and C++ files. The compiler decides which it is by checking the extension: ".c" gets compiled using the C compiler, ".cpp" gets the C++ compiler.

Currently VS 2015 does not completely support modern C and this causes some minor hand holding to be required. Changing all of the .c extensions to .cpp will cause the C++ compiler to be invoked, giving access to modern code features of C++11/14, as well as the use of the common subset of modern C.

It should be as simple as changing the extensions and submitting it, but there's always possible issues. I plan to do this shortly. (If there are any concerns please discuss soon)

Currently, the code is split into many plugins. Given that the system is now open source, having an external API is likely unnecessary. I would like to propose condensing the plugins into the main codebase. This would allow the compiler/linker greater insight into the code for optimization purposes, as well as reducing the system to a single exe rather than a bunch of dlls and an exe.
Thoughts/Ideas/Objections?

Add multiple switchable ROMs on SuperIDE, more like the real hardware. Allow selection of up to 4 ROMs and a switch to choose which is active.

In the "Configuration/Joysticks" tab, there are check boxes for the :
"Standard"
"Tandy HiRes"
"CC-Max"
hires interfaces. These were added by Joe, but never completed. At the moment, the functions are disabled. It would be nice to see these joystick hires interfaces implemented.
B.P.

If you use “.wav” files, if the “.wav” file is not recorded in “8-bit, 44,100 khz”, VCC will mangle the file just by loading it, you don’t even have to “play” it. Most “standard” wave files are in 16-bit, 44,199 khz. These will not work in VCC and even if you just browse to them and select them into the tape interface, VCC will try to convert them to 8-bit and ruin the file. This applies ONLY to the wav format. The "cas" files are not wave formatted files and are not affected.

Just thought I would make a issue post about the DIVQ / OpCode 118E 6309 not being emulated in the sources yet.

I went through hd6309.c and found that the case statement is there for it, but hasn't been implemented to actually work yet.

The .pak cartridges have a header and a foot with information, which can easily be recognized and accepted, they are no longer used much, but it is easy to make them not block and run well, less problems for the new coco initiates.

.pak only serve for emulators in ms-dos, but it's easy to accept them.

Some time ago I made a converter

PRINT "Program for convert Color Computer Cartridge V.1.00 01/2011"
PRINT "By Luis Fernandez [email protected]"
PRINT "MS-DOS convert filenames to 8.3 and uppercase"
PRINT
PRINT "Use COCOPAK *.PAK *.CCC"
PRINT " or COCOPAK *.CCC *.PAK"
PRINT
PRINT "CCC to PAK"
PRINT " Add at first, 2 Bytes int len(arch) and 2 Bytes int &hC000"
PRINT " and at end, 33 bytes 0 (cero) and 2 Bytes int &hC000"
PRINT
PRINT "PAK to CCC"
PRINT " delete 4 bytes at first and 35 bytes at end"
END

My VCC now has this error message every time I launch it, "Creating Back Buffer in System RAM! This will be slower" This started after David Ladd showed me how to connect VCC to DriveWire 4.

I thought I could undo the settings, but no good. I tried to remove the program, and even install in a different directory, still same issue.

The main problem with this error message is that I can't run VCC on my 2nd display, which is to the left of the primary, it freezes up on that display, which is a problem for me since I have a special set up for recording my youtube videos.

Anyway, my recording issues aren't as important as understanding what's causing this and hopefully fixing it, as it may affect someone else in the future.

Thanks!

I was informed today that the compiled version I have of VCC 2.0.1 will not run on a WinXP 32 bit system.
I have a feeling it was compiled for a 64 bit system only. Since I have yet to update my Win Vista 64 bit system to something Win 7 or beyond, I cannot yet recompile VCC to see if I can resolve the issue.

So Joseph, Gary or David, if you see this, could you compile a copy of the 1.200b branch, making sure it's 32 bit compatible and send me a copy?

VCC displays a "line" at the bottom of the emulator "screen" (above the statusbar). When in Full Scrren mode, this line sometimes "flickers" very brightly and on a dark color screen (black background: can be very distracting. Also, somtimes, and it seems to be when full screen is entered during certain elulation "cycles" the top and bottom borders of the screen will flicker and sometimes even display (during the flicker) the actual Windows desktop in the background.
I remember Joe stating on one of the forums back when he was working on either 1.42 or 1.41, that the line below the screen was a solution to a graphics problem he was having. I think the two issues are related and that if the line is eliminated, the flicker problem will go away. I think Joes comment on the line was on coco3.com, but it could have been on the bitlist server as he posted quite a bit there as well.

In Vcc v2.01, I have noticed that the "Overclock Disk Drive" checkbox under the "FD-502 Config" is not persisting from one run to the next. I find I have to check this box each time I run Vcc.
I've checked the "vcc.ini" file and the value for this feature is being written to the vcc.ini properly. All other featurs under this menu persist to the next run. This feature did in older versions.
This isn't anything major... just annoying if you use this feature as regularly as I do :-)

Being an avid user of the Orchestra-90, I decided to test it in the Vcc 2.00 build only to be brought to the "Extended Basic" prompt after setting the MPI switch to Orch90 and resetting the emulator.
Being curious, I viewed the orch90 source and saw the rom had been removed, but no provision made for loading the rom as there is with the FD-502 controller.

The Orch-90 pak still works as a stereo Coco sound source, just not as a "rompak" since there is no rom.

Solution? Add a rom loader to the Orch90.dll and store the rom in the Vcc install folder like all other system roms. The rom is readilly available in all the archives.

By the way... I have full permission (in email form) from Jon Bokleman (orch90 author) and Bryan Eggars (owner Software Affair) to use their Orch-90 code in any way I please, though I think the copyrights still belong to Tandy.

In the cassette inerface tab, when you have a cas or wav file loaded and exit VCC, the emulator will not reload this file when run again. This is not consistant with the disk and hard drive interfaces which remember the file if it was loaded on exit.

On the latest build (01/09/2016), when VCC is in full screen mode, if you hit the "Windows" key (start menu), VCC will crash. It should go back to default size OR just minimize. It tries to stay on screen with the windows startbar and start menu....

VCC has always needed a debug function. Again, a good example is the Mess debugger.
When turned on, a separate window opens showing the current address being accessed (scrolling) and a representation of the asm ascii and hex code... kind of like ZBug.
You should be able to set breakpoints, single step etc...

Like this:

Since I run VCC quite often (read A LOT!), I find I use the increased CPU speed ("Configuration/CPU") set to the max most of the time. This setting not only speeds the CPU, but also increases screen refreshes and graphics speed. To change this setting, you open the conifg menu.
It would be nice to use F4 (unused) to set "max speed" on first press, then "minimum speed" on 2nd press.
OR.. use F3 (also unused) to slow down the CPU by 10% on each press until bottomed out, and F4 to increase the CPU by 10% on each press until maxed out. This would allow people with slower computers that cannot handle "max speed" to at least take advantage of increased speed without opening the config menu.
Any thoughts on this one?
B.P.

Add user interface to disable the RTC in the HardDisk module.

I have taken the liberty of releasing the compiled version of "VCC 2.0.1". I have been running it for a little over a month now and only a couple of things have cropped up which are all (so far) listed in the "Issues" as "bugs". The release is packeged in an "Inno" installer package along with a newly revised manual. I also included all needed roms. The "Tandy" roms were compiled from the "ToolShed" repository and therefore are NOT copies of the Tandy roms.
The HDBDOS and RGBDOS roms were released into Open source, so they are legit.
I have aquired permission from Jon Bokelman & Brian Eggars to use the Orchestra-90 rom

I also have started a "Documentation" wiki which basically reflects the new manual. If you have any changes or suggestions, let me know and we'll get them in there and in the new manual as well.

Seems there is an incompatibility between Vcc and MAME/MESS for 32KB ROM images.

MAME/MESS want a naturally-ordered ($8000-$FFFF) 32KB block whereas Vcc requires that the top and bottom 16KB blocks are switched ($C000-$FFFF,$8000-$BFFF).

Whilst archives on the net tend to be in the swapped format (Vcc) and therefore incompatible with MAME/MESS, it's worth noting that this swapped format is also unsuitable for burning to FLASH/EPROM.

I would argue that the naturally-ordered format is easier to produce for developers, compatible with MAME/MESS and FLASH/EPROM burners. Should we also change Vcc to use this format?

In the current release (from vcc-1.200b, not the master), I've found that the "SuperIDE.dll" does not function. Everything seems to work up until it goes to read the drive on restart after making the proper setting in all the configs. I get the hdblba error "LBA Hard Drive Not Found", when there is a CF card image mounted.
I have tested these settings on both VCC 1.42 and VCC 1.43beta and the SuperIDE.dll works properly.
This may not be an issue once the latest commint is finally made as I know quite a few things are being rerranged.

In running Vcc in full screen mode, F10 is supposed to toggle the status bar. I have notice that while in full screen mode in Vcc v2.01, this does not happen. F10 seems to do nothing.

Something that was brought to my attention was the way VCC's menu system works.
In Mess (and other emulators including XRoar), when a system menu is open, the emulation "pauses" and waits for you to exit the menu.
In VCC, the emulation continues to run while any menu is open. I have found this to be both an advantage as well as a hinderance.
Any thoughts on this?
B.P.

It has come to my attention that there are some 6309 instructions missing from the 6309 emulation in VCC. It would be nice to have the full 6309 implementation in VCC.
I haven't actually seen problems with this that I know of, but I know some adventurous programmer will catch it.

I have seen that it is difficult to load cartridges because it does not contemplate the extension * .ccc nor * .pak

I think and if you agree to put this in the window filter on pakinterface.c (int LoadCart(void))

Ofn.lpstrFilter = "Program Packs (.rom; . dll)\0.ROM;.DLL\0Cartridges (.ccc; .pak)\0.ccc;.pak\0All Files (.)\0*.*\0"; // filter string

instead of this
Ofn.lpstrFilter = "Program Packs \ 0 * .ROM; *. DLL \ 0 \ 0"; // filter string

So we can choose 3 options and also see the extensions you are currently looking for

(How do I put labels here?)

In working in "Vcc v2.01" on my NitrOS9 C projects, which are almost all GUI (mouse) based, I noticed that when I use "Full Screen" mode, the "coco mouse" does not travel full screen left/right and up/down. The mouse will only travel about 2 thirds of the screen from the left and top edges. It will not go all the way to the far right nor bottom of the screen.
This works fine in "Windowed" mode even when the Vcc window is "Maximized". In Full Screen, the real windows mouse cursor disappears (as it should) leaving only the NitrOS9 mouse cursor, but the cursor only reaches 2/3rds of the full screen. I know this was not a problem in old versions
This is probably a scaling bug and I imagine, easily fixed.

One thing I have always been jealous of between VCC and Mess is Mess's ability to 'paste' into the Coco screen. You can select and copy text from a PC document, then paste it into the Coco's memory. This makes inputing Basic programs from listings in other documents a breeze. You can edit files on your PC using your favorite editor, then copy and paste it into the Coco.
This action would react just as if you input via the keyboard.

Which version(s) of Visual Studio are required to build VCC?

For now, this needs to be either disabled or removed. (I would suggest disabled, since we should get this working at some point)

I had a VCC 201 user report that the keyboard modes "Basic" and "OS9" are not functioning properly. It seems that no matter what the setting, the keyboard mode stays in OS9 mode.
I tried this on my system (Win Vista Home Premium 64bit) and found the same problem.
This seems to fall along with a previously reported bug (by me) that the "Overclock Disk Drives" is not being persistant from one run to the next.

I'm wondering if there any other buttons, pull downs or check boxes not functionng properly.
I will start running some checks and see what I find.

Bill P.

Does anyone know if the "ramdisk.dll" actually works? I have never tried this module. I think it is supposed to be an emulation of Disto's Ram cart. If it actually works, I would like to document it's use and include it in the release.
I will look into this a little more.

Currently, VCC maintains 1 single filepath. When you open a file dialog of any kind to mount a dsk, vhd, or rom, etc, VCC remembers that path, Then when you go to load/mount something different it comes up in the last path used.
As a habit, I have different folders on my PC for Dsk images, VHD images, and Rom images, etc. It would be nice if we could set 'default' folders for various filetypes. The needed ;default pathlists are:

CCC, ROM, DLL - Rom cart images. Loaded through the Cart port & MPI.
ROM - System roms. Loaded by the various DLLs and VCC itself. Also used in "FD502 Config" for external roms
DSK, VDK, DMK - Disk images. Used by fd502.dll
VHD - Virtual Hard Drive images. Used by harddisk.dll
IMG - SD card images. Used by SuperIDE.dll
Cas, WAV - Cassette image files. Used in "Config/Tape"
TXT - Printer text files. Created when using VCC's virtual printer in "Config/Bitbanger"

I think that about covers all the various file types VCC uses. Each should retain it's own filepath and be saved with the vcc.ini file.
B.P.

I believe that the declaration of FlagEmuStop should be changed to

static volatile unsigned char FlagEmuStop=TH_RUNNING;
because as it is, a compiler is free to change the loop

 FlagEmuStop=TH_WAITING; //Signal Main thread we are waiting
 while(FlagEmuStop==TH_WAITING)
      Sleep(1);

in EmuLoop() to

FlagEmuStop = TH_WAITING;
for (;;)
    Sleep(1);

since FlagEmuStop is static and its address is never passed outside Vcc.c.

I've been running Vcc on Linux using WINE, and I find that selecting exit doesn't close the Vcc window. I can't swear that this is the cause of the problem, but it could be. I don't use Windows (save under duress), and Visual Studio is in the "garbage" category at winehq, so I can't make the change locally and rebuild to test; sorry about that.

 ```

CoCo 3 Keyboard
+-----------------------------------------------------------------------------+
| [1!][2"][3#][4$][5%][6&][7'][8(][9)][0][:*][_:] [esc/Break] |
| [Alt][Qq][Ww][Ee][Rr][Tt][Yy][Uu][Ii][Oo][Pp][ @ ][Clear] [ Up-A ] |
| [Cntrl][Aa][Ss][Dd][Ff][Gg][Hh][Jj][Kk][Ll][;+][Enter] [Left-A][Right-A] |
| [Shift][Zz][Xx][Cc][Vv][Bb][Nn][Mm][,<][.>][/?][RShift] [ Down-A ] |
| [ Space ] [ F1 ][ F2 ] |
+-----------------------------------------------------------------------------+

    Rows and columns
    +-----------------------------------------------------*
    |      0-----1-----2-----3-----4-----5-----6-----7    |
|  0-[ @ ]-[ A ]-[ B ]-[ C ]-[ D ]-[ E ]-[ F ]-[ G ]  |
|  1-[ H ]-[ I ]-[ J ]-[ K ]-[ L ]-[ M ]-[ N ]-[ O ]  |
|  2-[ P ]-[ Q ]-[ R ]-[ S ]-[ T ]-[ U ]-[ V ]-[ W ]  |
|  3-[ X ]-[ Y ]-[ Z ]-[UpA]-[DnA]-[LfA]-[RgA]-[spc]  |
|  4-[ 0 ]-[1 !]-[2 "]-[3 #]-[4 $]-[5 %]-[6 &]-[7 ']  |
|  5-[8 (]-[9 )]-[: *]-[; +]-[, <]-[_ =]-[. >]-[/ ?]  |
|  6-[ENT]-[CLR]-[BRK]-[F1 ]-[F2 ]-[F3 ]-[F4 ]-[Shf]  |
    +-----------------------------------------------------+

	   
	TODO: explain and add link or reference to CoCo 'scan codes' for each key

C ++ writing format and user display formats

I think we should have a common site to share, discuss and reach agreements on internal and external formats, for example

I do not know if it is better (* .bin, * .dll) or with ";" Instead of "," and if you always add a space later or not, or use uppercase or lowercase letters

So far the format seems to be, lowercase and space after ","
I do not know if it's better, ";"

With respect to the c ++ format it seems a little long
command
{
      Break;
}

I prefer

Command {
      Break;
}

Or for a single instruction inside, use:

Command
     Break;

I have tried various DW ROM images and also just using "becker.dll", and I'm unable to access any DW mounted disks. It is possible I am just doing something wrong, but I have tried the most trivial use case I can think of:

1. Configure DW4 for TCP/IP, Becker Port instance.
2. Mount a simple 156K Coco .dsk image file in DW4,
3. Insert "becker.dll" directly into the cartridge slot.
4. Ensure DriveWire settings in Vcc are set to 127.0.0.1/65004.
5. Hard reset the emulator and type "DIR1", "DRIVE1", etc. commands.

All I ever get is syntax errors. It seems like there is no ROM image loaded that know how to access DriveWire, BUT I DO see a client connection gets established to the DW4 server.

I have also tried many other configurations using DW compatible ROM images, but to no avail. I have no way of configuring the server address/port when using the ROM images, but I do also see client connections being established to my DW4 server. With the ROM images, I never get a prompt. Vcc just hangs after displaying the HDB-DOS banner.

Please advise...

It would be really nice to have an RS232 pak emulation that would connect to an IP and port address. That way I could use VCC to run terminal software or accept incoming connections without using a DriveWire server. DriveWire becker port support is nice, but having to run a server process just to get this ability is a pain.

Add support for second VHD in harddisk.dll.

I would like to see the old Rs232 pack and some folks are showing more interested with running a bbs system. Using the same functions and features of the old Rs232 Pack would save from having to write several hundred lines of codes if it support the same memory address to receive, send and carrier detect. The incoming data control can be controlled using timer evens which most programing languages support to slow down the data to 9600 baud. So lets bring back the old bbs system because calling a bbs is not a real coco bbs unless its running on the Trs-80.

I suggest that you use a PC dir as a hard disk or as a floppy disk
As floppy disk would not have limitations, I do not know if it would work well but you can study

As HD would be better, there would be no need to create an HD file and we could also pass directly without conversions .bas or .bin files as is done in other emulators like winUae for friend

Occassionally, when working on a program, a syntax error, especially involving loading data arrays or storing values to memory locations, when run, data seems to overwrite something and crash VCC. In reality, a real Coco would just "run wild" displaying a static graphics or text screen and a reset resolves the issue.
In VCC, this sometimes crashes the emulator and requiring a restart. VCC should not be doing this. It should emulate the Coco crashing just as a real Coco would.
Something is overwriting something... I have no clue as to what. This has been a problem in VCC since the beginning as far as I know.

I do not know if it is a good idea to have inside the code the distribution tables of the keyboard, I know that for convenience there are no external files, but that makes many things impossible.

The added languages are not a problem since there are helpers in VS2015 that allow in addition to translate, use even different sizes for fields in the dialogs and buttons, being able to change its size to adapt it to other languages.

But in PC,MAC or ... keyboard layout, no

I propose to change this to a file that can be modified even by the user, thinking about how difficult it is for German users with double accents, this way we can go out versions of keyboard designs or each one sends us one and we go Collecting

For this you need an external file, if it's okay with you, I get to work on that

In the "Configuration/Display" tab, there is an option for "Force Aspect" which is disabled. This was originally supposed to implement keeping the screen aspect correct when entering "Full Screen" mode i.e. "square".
Currently, when you enter full screen mode on a wide screen monitor, the emulation "stretches" to fit the wide screen. Instead, with "Force Aspect" selected, it should retain a "square" in the center of the screen. Mess has this same feature and it makes the full screen Coco look "real".

It would be nice to see this working as it has been non-functional since the early days of VCC.
B.P.

After building the latest incarnation of Vcc (2.00), I find it works basically the same as the old 1.42 build with one exception...

It seems Vcc only keeps up with one "master directory" for all file types... meaning; if you go to load a VHD into the system and navigate to a different folder, when you hit "F9" twice to "cold start" the emulation, Vcc will then try to reload the system roms from that location instead of the install dir (Missing file: coco3.rom). I find I have to shut Vcc down and restart it for the system rom directory to reset to the default.

A solution to this may be to setup multiple folder locations for various file types, all user changable. I have seen many applications with multiple folder settings, so it should not be too hard to do.
Example:

Disk Images: C:/xxx/xxx/xxx.dsk/os9
VHD Images: C:/xxx/xxx/xxx.vhd/img (img for using the SuperIDE.dll and SD images)
Cassette Images: C:/xxx/xxx/xxx.cas/wav
Cart Images: C:/xxx/xxx/xxx.ccc/rom
System Rom Images: C:/xxx/xxx/xxx.rom
System Cart (DLL) Images: C:/xxx/xxx/xxx.dll

These would all be changable through the "Config" interface (new tab, "Default Folders") as well as the "vcc.ini" directly
This would allow the user to specify their default directories for these file types, and on startup (or restart), these folders would be where Vcc looks. Of course, the "Persistant Disk Images" option in the FD-502 Controller settings would still look in the last used dir, but not affecting where Vcc looks for "system rom" images.

I'm not sure what part of the code this would be done in. I do know that when you load a new VHD image, then go to the cassette menu (or any other load menu), it will automatically take you to the last place you loaded from, which in this case would be where you loaded the VHD.
I assume this is what is happening in the system rom routines on a restart (hitting F9 F9). The rom routines are looking in the last used location.

This has really been an issue since VCC was started. In a hardware text screen, when issuing a "BlnkOn(stdout);" (in OS9), the following text should "blink" on and off. This is a function of the GIME chip as it only works on a 'hardware' text screen (40x24 & 80x24) and not on graphic text screens.
This would have to be implemented in the GIME emulation. I'm not sure is this is implemented in Mess or not. I think it is.

I downloaded the 2.01b today on my main Windows 10 Home (1511) system and found that I am getting garbage on the Disk Eject where it should be saying Empty. Not sure if this is because of Windows 10 or possibly another issue.

I have had many people tell me that the artifact colors in composite mode on the Mess Coco emulator are much truer than the artifact colors in VCC's composite mode.
Since we are basically rewriting this stuff, maybe we could take a look at the Mess sources and see how they implement the artifact colors to get an idea on how to impove VCC's artifact colors.
The "Gamers" would love it.
Any thoughts?
B.P.

Something I have forgotten until today, as I was creating a series of disk images with VCC, I had to type the ".dsk" extension for every disk image I created. It would be nice if VCC would default to adding the ".dsk" extension if I forget it. Currently, is you forget it, it creates a file with no extension and you have to manually rename it to use it.

Also, it would be nice if the "harddrive.dll" would create a VHD image if the name doesn't exist (just like the floppies). Of course, there would have to be pop-up dialog for number of sectors and such.

edit: also, while in the create disk file dialog, make "JVC" disk format the default selection as that's what's used the most.

VCC allows you to try to resize the window, but it does not work correctly. Resize should be disabled or scaling implemented.

This will be where we can start listing the things we would like to see in upcoming revisions of VCC.
Not to say it's the "Coco 4" wish list where everyone wants 1024x728 display or 2 million colors, but instead listing simple things.... things more involved with the emulator's appearence and menus and not the Coco's enhancements.
I will start a list, then everyone can chime in with things they would like to see as well. You never know, some of it may come about and be part of the new VCCX !
B.P.