| |
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/ |
|
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
Thanks, it will take an entire weekend to test all the new features =) |
| |
Burglar
Registered: Dec 2004
Posts: 1085 |
nice, been using viceplus practically exclusively the last months, will test out 1.1 soon. keep it up!
and for the impatient, a direct link to the readme:
http://viceplus.svn.sourceforge.net/viewvc/viceplus/trunk/vicep..
|
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
initbreak and backtrace made my day! Thanks!
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: initbreak and backtrace made my day! Thanks!
backtrace as in JSR/IRQ stack backtrace? \o/ |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
A couple of notes
- parameter -soundbufsize 1 makes the sound very jerky here. No wonder it was set to be at least 100
- new PAL emulation is not usable for watching demos, it's a CPU hog.
- after reduilding with --enable-memmap i've tried mmsh and mmsave. Why saving in bmp? I think a text dump like this could be more useful
(memmap.txt generatd by hacked sidplay2/w)
4800-sid.sid #1 0:00-0:06
;0000 ++xxxx.. ........ ....xxxx ........ ........ ........ ........ ........
;0040 ........ ........ ........ ........ ........ ........ ........ ........
;0080 ........ ........ .w...... ........ ??!..... .....xxx ........ ....xx..
;00c0 w....w.. ...x?... ........ ........ ........ ........ ........ ..xxxxxx
;0100 wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww
;0140 wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww
;0180 wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww
;01c0 wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwwwwwww wwww++++ ++++++++ ++++++xx
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
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? |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
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 ;) |
| |
Ed
Registered: May 2004
Posts: 173 |
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.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11351 |
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: 896 |
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: 11351 |
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: 3186 |
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 =) |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
Found the problem: a missing prototype in actionreplay4.h causes an undefinable beahviour
extern BYTE REGPARM1 actionreplay4_roml_read(WORD addr);
the compiler assumed it returns an int and depending on the returned value shit happens =)
stardos.h has the same problem, probably more.
Already mailed about this at the developers address. |
| |
Wisdom
Registered: Dec 2001
Posts: 90 |
For the last couple of days, I have been trying out VICEplus for the first time. Apart from some nice features such as 8580 digi boost and backtracking in the monitor, I have seen several raster bugs (flickering etc) so far. At first I did not suspect the VICEplus to be blamed, so I did not care to compare with the original VICE release. But after seeing it many times here and there, I just did a comparison on the last thing I have viewed: Channel 4 (There is a flicker between the TV graphic and the scroller.)
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: For the last couple of days, I have been trying out VICEplus for the first time. Apart from some nice features such as 8580 digi boost and backtracking in the monitor, I have seen several raster bugs (flickering etc) so far. At first I did not suspect the VICEplus to be blamed, so I did not care to compare with the original VICE release. But after seeing it many times here and there, I just did a comparison on the last thing I have viewed: Channel 4 (There is a flicker between the TV graphic and the scroller.)
Confirmed.
Although the bulk of the release is based on 1.22.8 there are actually a few cherry picked parts from 1.22.9 in it.
This particular regression is due to a "bad" merge of 1.22.9 into raster/raster.h.
It slipped by us because of very limited testing of x64.
It has been fixed in the repository.
Snapshot build (r628) for win32 here: http://www.kahlin.net/~tlr/dtv/x64-x64dtv-628-win32.zip
Thanks for reporting this Wisdom!
BTW, this means that it is now a "REAL MACHINE, OMG!" in WVL's test prog...
(thanks to Rubi's improvements) |
| |
iAN CooG
Registered: May 2002
Posts: 3186 |
just tried the patch from SF, works great! thanks. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
The problems iAN reported has been fixed too btw.
Thanks for that! |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:BTW, this means that it is now a "REAL MACHINE, OMG!" in WVL's test prog...
(thanks to Rubi's improvements)
im not sure if thats a good thing. real things tend to be more Hoxsish now,you know;) |
| |
Wisdom
Registered: Dec 2001
Posts: 90 |
tlr, thanks for the quick fix and the binary! =) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Also thanx for the excellent and now usable mouse emulation under Linux. ;D \o/
A bug that has been there since all times (for me at least with my Linux distro) is when starting x64 with a .prg file and immediatly hitting alt-w for warpspeed loading. That almost always causes x64 to deadlock. It's ok to hit alt-w after loading, but hitting it when loading never works. It works flawlessly when starting with a .d64 file though. |
| |
GiZMO
Account closed
Registered: Nov 2003
Posts: 1 |
Awesome. i'll try it out now... thanks |
| |
Ed
Registered: May 2004
Posts: 173 |
Tested and confirmed: yes slightly off the colours scale using x64dtv. The new pal emulation works 50 fps without double scan lines but double size, but with double scanlines and double size i get about 3 fps (2.4 ghz p4 processor, windows).
|
