[CSDb] - User Forums - Release id #185343 : VICE 3.4

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #185343 : VICE 3.4

2020-01-03 13:35

Jammer

Registered: Nov 2002
Posts: 1289

Release id #185343 : VICE 3.4

Since 3.4 Mr Wegi's loader stopped working - it seems to init drive and go idle. Any solution to that? Tweaking settings gives no results.

... 28 posts hidden. Click here to view all posts....

2020-01-04 09:11

Jammer

Registered: Nov 2002
Posts: 1289

Quoting Hein

Been using 3.3, SID emulation sounds more accurate than reSID fp, which I used before and didn't reveal the low filter clickers for 8580.

True, given SID filter has burnt a little xD That said - direction was right only slightly overdone.

2020-01-04 10:47

Radiant

Registered: Sep 2004
Posts: 639

Re: SID filters — the problem lies/lied in the formula used for replicating the analogue filter in the 8580 not accurately reproducing the filter curve as measured from a real C64, when fed the constants used in the ReSID sources. I submitted a tentative patch that made the filter sound more correct to my delicate ears, though the curve was still way off. Not sure if that patch ended up being used, if a proper fix was made, or if the new filters were simply redisabled for the 8580 until they could be made right. More info may be available among the bug reports in the Sourceforge project.

Re: Windows builds — why even bother supporting MSVC if MSYS/MinGW works? The difference in the resulting binaries is likely completely negligable, and building using one is in no way harder than building using the other.

2020-01-06 09:11

Stone

Registered: Oct 2006
Posts: 168

Quoting Radiant

Re: Windows builds — why even bother supporting MSVC if MSYS/MinGW works? The difference in the resulting binaries is likely completely negligable, and building using one is in no way harder than building using the other.

It's not just about spitting out an executable. I hear VICE team is still looking for maintainers on Windows and Mac and in order to contribute, most people will probably want a development experience they are comfortable with. Why not use a platform independent build system (or build system generator) like cmake, which seems to be becoming an industry standard for C/C++ based projects these days?

I only have a single VICE patch to my name (a crash bugfix related to midi), but to make it happen I had to jump through some hoops to create Visual Studio project files so I could debug it. Having up-to-date build files for other OSes would greatly lower the bar for contributing. BTW: I don't love cmake. I just hate it a little less as time passes by.

2020-01-06 13:32

iAN CooG

Registered: May 2002
Posts: 3136

> Why not use (etc)

because they don't want to do it themselves, you have to jump in and volunteer on doing it.

2020-01-06 14:42

Krill

Registered: Apr 2002
Posts: 2852

> Why not use a platform independent build system (or build system generator) like cmake, which seems to be becoming an industry standard for C/C++ based projects these days?

> because they don't want to do it themselves, you have to jump in and volunteer on doing it.

In my experience, because all of them are shit. If done right, plain makefiles can be just as platform-independent and remain highly flexible and well-documented.

2020-01-06 18:52

Compyx

Registered: Jan 2005
Posts: 631

Plain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler. Command line things like an assembler can be done with plain Makefile's and perhaps a bunch of #ifdef's to handle platform-dependent code.

I prefer plain Makefile's too, when feasible, I'm not a fan of autotools, but so far it's the most logical thing to use for us, seeing the amount of OSes, libraries and compilers we need to support.

I've tried a lot of build systems, one even suggested cat'ing .c files together to speed up compilation =)

We dumped MVSC support because it was a pain in the arse to maintain: basically a whole lot of brittle scripts going through the source to create MVSC crap and nobody used it.

I'm not saying I'll never consider another build system, but in the end it comes down to people actually willing to put in the work to show buildsystem X, Y or Z is better. And then maintain it.

2020-02-29 13:15

Zirias

Registered: Jan 2014
Posts: 48

Quoting hedning

Quoting Compyx
VICE's build system hasn't supported MSVC for quite a while now. If you want to build VICE on Windows from source you'll need msys2, unless Visual Studio supports autotools projects.
How can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users.

So what gives you the idea this has anything to do with supporting MSVC? Vice is written in C, and Microsoft's compilers don't support newer C standards at all -- they seem to only care about C++. Nowadays, it makes no sense at all to support building a C project with MSVC. You use either GCC or LLVM/clang, both are available in MSYS2 for Windows :)

I have no idea whether the VICE code base actually uses any C99 and newer language features, but that's generally #1 reason for kicking out MSVC support. #2 is probably the burden to maintain multiple build systems.

As for performance issues of recent VICE versions built for Windows, I never really noticed them myself, but I don't use it a lot on Windows and the Windows machine I use has a pretty fast CPU ...

Any idea whether these issues are more likely in VICE's code or in other libs / build settings / etc? I could maybe try to create a build using my MXE toolchain and see whether it uses less CPU ;)

2020-02-29 13:22

Zirias

Registered: Jan 2014
Posts: 48

Quoting Compyx

Plain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler.

Well, you *can* do more complex stuff, especially if you don't restrict yourself to "portable make" but require a specific flavour like e.g. GNU make.

Because I don't like the huge complexity of GNU autotools, I started developing my own system using only GNU make "metaprogramming" here: https://github.com/Zirias/zimk :)

Don't get me wrong, I would never suggest a complex project like VICE adopting this, of course it doesn't have all the features GNU autotools provide, and it totally lacks in documentation -- but I *do* use it myself, so just mentioning it here as an example what can be done with "plain make". E.g. it handles dependencies with pkg-config :)

2020-02-29 18:49

Compyx

Registered: Jan 2005
Posts: 631

VICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:

size_t x = 42;
printf("%zu\n", x);

I have to revert to the old C89 'trick' to print a size_t:

size_t x = 69;
printf("%lu\n", (unsigned long)x);

Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.

We have a way of generating a CMake project from trunk, which should be importable into VS, I'm not sure how useful that would be seeing the abominable state of MS's C support.
I tried the CMake route with VS, but I got a lot of missing .lib files for Gtk3 etc. There's supposed to be a tool 'vcpkg' to install those libs for use in VS, but on my box VS didn't see the libs, leading to manually adding a lot of libs using a horrific UI, so I deleted VS.

2020-02-29 21:22

Zirias

Registered: Jan 2014
Posts: 48

Quoting Compyx

VICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:

size_t x = 42; printf("%zu\n", x);

I have to revert to the old C89 'trick' to print a size_t:

size_t x = 69; printf("%lu\n", (unsigned long)x);

Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.

There are two ways around this when using MinGW to link to MSVCRT.DLL.

1. Do something like this:

#include <inttypes.h>
#include <stdio.h>

#ifdef _WIN32
#  ifdef _WIN64
#    define PRI_SIZET PRIu64
#  else
#    define PRI_SIZET PRIu32
#  endif
#else
#  define PRI_SIZET "zu"
#endif

int main(void)
{
    size_t mySize = 24;

    printf("%" PRI_SIZET "\n", mySize);
}

2. Let MinGW link some code to your executable working around this by adding

#define __USE_MINGW_ANSI_STDIO 1

I'd assume %lu could break on 64bit windows, as a size_t is probably 64 bits wide, but a "long int" still has only 32bit (Windows 64bit uses the LLP64 data model, unlike most Unixes that use LP64)

Quoting Compyx

so I deleted VS.

Unless you want to create .NET code, best course of action ;)

Previous - 1 | 2 | 3 | 4 | 5 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

Sixx
Airwolf/F4CG
icon/The Silents, Sp..
Guests online: 86

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)

Top Groups

1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Swappers

1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.8)
4 Acidchild  (9.7)
5 Starlight  (9.6)

Page generated in: 0.047 sec.