| |
tlr
Registered: Sep 2003
Posts: 1787 |
VICEplus v1.1 released!
The VICEplus team is proud to announce the release of VICEplus v1.1!
(based on VICE 1.22.8)
VICEplus is the Versatile Commodore Emulator Plus. Its most important extension over VICE is support for the C64DTV as well as a few general bug fixes and improvements.
Binaries available for:
* Win32 (Windows 9x/ME/NT4/2K/XP/2K3/Vista)
* MacOSX
* MSDOS
* BeOS
* QNX
* Solaris
* Minix
* OpenServer
* Unixware
* HPUX
* SkyOS
* Amiga based and derived systems
More information and downloads:
http://viceplus.sourceforge.net/ |
|
... 18 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
strangely, the new pal emu only seems to have major speed problems on windows, and it works fine on linux ... also the soundbuffer size can easily be 1ms here without jerky sound. can't say i care =)
ES: the colors should really be ok though, you might have to play with the settings, maybe the defaults are a bit off. (and always remember, colors will never look like on your c64) |
| |
1570
Account closed
Registered: Jul 2007
Posts: 7 |
Quote: wow thumbs up guys. minor bugreport: disk image & tape image / prg view filter is missing from the autostart requester.
the new pal emulation is really a cpu killer :) my machine runs even debris/fr faster than dtv+new palemu :D
edit: btw someone with the urge to write about DTV coding into codebase64? Jeri's docs are really cryptic ;) frantic will you open a section for it?
http://picobay.com/dtv_wiki/index.php?title=DTV_Programming is an extended version of Jeri's original docs and should explain the basics quite well. If anything there is still cryptic, just ask here :-). |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: The new pal emulation is horrible, it sucks the juice out of the machine like nothing I have seen before. Also the colours are way of the chart in my version. rendering the test I made some 7 years ago will not result in proper colours.
A fast pal emulation will give unusual colours. Have not figured out why...
Also there are some other stuff that I could complain about, but will leave out here. I think the point is well taken considering some reactions. There are stuff to be made. Lets hope 1.2 will feature upgrades.
Quote:A fast pal emulation will give unusual colours. Have not figured out why...
I'm not sure if you mean x64 or x64dtv...
Fast PAL emulation does not work correctly with x64dtv.
This is due to that codebase not supporting 256 colors.
That optimization probably doesn't make sense for that many colors anyway.
It is mentioned in Readme.x64dtv.
It should be made impossible to activate it though.
EDIT: ...and if you run your color tests in x64dtv (without patched kernal) instead of x64 you'll get colors that are off.
The colors are slightly off even with a patched kernal, but pretty close. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: For those wanting a better dtvrom.bin
hxxp://iancoog.altervista.org/vice/dtvrom_12.rar
Dtvboot/dtvmon 1.2 by TLR, alternate kernal by Peiselulli and better palette.
The one provided with VicePLUS 1.1 has nothing apart the nice intropic ;)
There's a patched ROM available separately at the download page as well:
http://viceplus.wiki.sourceforge.net/binary_downloads
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: strangely, the new pal emu only seems to have major speed problems on windows, and it works fine on linux ... also the soundbuffer size can easily be 1ms here without jerky sound. can't say i care =)
ES: the colors should really be ok though, you might have to play with the settings, maybe the defaults are a bit off. (and always remember, colors will never look like on your c64)
I don't know what kind of sound interface VICE uses on Linux so I'm not sure my comment is applicable. Anyways, I've used the OSS interface quite alot and requesting a 1ms fragment size using SNDCTL_DSP_SETBLKSIZE will most probably not give you that small buffer. One must always double check by using SNDCTL_DSP_GETBLKSIZE to be certain how big the sound buffer really is. It's really up to the OSS-driver. So, is it possible that you just think you have 1ms and that the sound really is out of sync anyway?
And regarding the PAL emulation, it's just number crunching right? It sounds really weird this is slow on windows only. Could it be different compiler optimization settings in the Makefiles? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Since Vice has to emulate a frame before it can display it, there is atleast a 20 ms delay on the display. It's best to choose the same delay ("buffer size") for sound.
|
| |
WVL
Registered: Mar 2002
Posts: 899 |
The new PAL emu is really hellish slow on my pc :) I wonder if even the newest cpu's can emulate with the new PAL emulator on full speed.. (windoze running x64.exe)..
Example : on my Core duo 1.66GHz I get about 31% speed with 2fps! :D (OMG!) |
| |
Spinball
Registered: Sep 2002
Posts: 88 |
on my WindowsPC new Palemulation is only slow if "Double size" and "Double scan" are aktivated at the same time.
if one of those settings is deaktivated i get full speed+50fps . (windows xp on 1.8ghz CoreDuo)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
Quote:
It's really up to the OSS-driver. So, is it possible that you just think you have 1ms and that the sound really is out of sync anyway?
yes, the real fragment size will always be ~20ms (as you could see in the console output on any sane os =P)
however, its still a LOT better this way than with the 100ms deeeeelaaaaaaaaaaay =)
Quote:
The new PAL emu is really hellish slow on my pc :) I wonder if even the newest cpu's can emulate with the new PAL emulator on full speed.. (windoze running x64.exe)..
Example : on my Core duo 1.66GHz I get about 31% speed with 2fps! :D (OMG!)
i have good oldish amd64 2.2ghz, which runs the new pal emu at full speed *easily*.
we already wondered about this during our first tests... its really windows related appearently (maybe the win32 rendering code in vice is even more retarded than the rest =P)
Quote:
on my WindowsPC new Palemulation is only slow if "Double size" and "Double scan" are aktivated at the same time.
yes, since there is no renderer for new pal emu at all in singlesize mode :=) (i think it just falls back to the old one) |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
I just noticed a strange behaviour compiling by myself viceplus 1.1 with mingw/msys (gcc 3.4.5).
No matter what I try, action replay 4.0 does not work, memory at $8000-9fff remains $aa and 30719 btytes free displayed, like in any case of unsupported cart.
The distributed exe works nicely instead.
I swear I tried with the official sources, no single file edited before configure/make. Vice 1.22.8 builds and works fine.
I hoped it was like this because i did
./configure --enable-memmap
to use the extended monitor commands, but even a simple configure/make clean/make does not make this fecking ar4.0 work.
Also, to add insult to injury ;) I tried to build it with Visual Studio 2003/ VC7.1... the supplied project files are not even updated for viceplus and gives 10 build fatal errors, mostly for new sources not included. O well, will have a look later but just to let you know =) |
| Previous - 1 | 2 | 3 - Next |
