| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
x64 vs x64sc, drive emulation
I'm taking a break from shitposting about assembler syntax to do some actual development, and I just noticed that the fastloader I'm working on works under x64sc but fails under x64 (vice-2.4). Should I care? Just wondering if it means my timing's too tight to be reliable on a range of real drives..
(yes yes, I'll dig some actual hardware out tomorrow to see if it works on the real thing, and I'm also having another attempt at building vice from a source tree. I'll do some emu maintenance one of these years..)
edit- and yes, I had true drive emulation enabled in both. |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for a start, you should try it with a nightly build and delete 2.4 =) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Actually my experience was, that the emulator is less picky than a real drive and some VIA stuff is not emulated right. So you will happen to have things working on emulator, but not on a real drive. Pain ahead, have fun :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats correct of course - however 2.4 is even a lot more bugged than the nightlies are :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
and while at it: WRITE FUCKING TEST PROGRAMS DAMNIT - its the only way to get emulatorcrap fixed |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Groepazthats correct of course - however 2.4 is even a lot more bugged than the nightlies are :)
Is it a lot of work to promote one of those nightly builds to a 2.5 release? People tend to stick to the latest "stable" release available. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"people" are silly. 2.5 will come when all remaining issues are fixed, perhaps the windows port removed, and osx killed and buried under a rock. and after that we'll have rolling releases, so no more "major" versions anyway. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Windows port removed? That's going to ruffle some feathers :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
we've asked for help with it for quite a while now, with exactly zero response. couldnt care less by now. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Might as well drop support for Athena and Xaw3d, can't imagine people still using that. And Gtk2 is unmaintained as well, even the MATE desktop is moving to Gtk3 because of that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
both the xaw and the gtk ui are maintained - its not about what your favourite distro uses at all. (and yes, strange enough, there are ppl who prefer the XAW ui) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Point taken. But when I said Gtk2 was unmaintained, I meant upstream, didn't mean the VICE Gtk2 port. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
sure sure. the same ui can be compiled for gtk3 though, the switch is almost done (and then it will become default too) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I've been using the Gtk3 port for some time now, works fine. And with the latest VICE version the UI threads work fine too.
Even on this Mint 17.3 box which doesn't exactly use very up-to-date version of libraries. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yeah, the one thing missing is hardware scaling support |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Aha, that's why I couldn't get ./configure to enable that. Had all the relevant libs installed as far as I could tell.
Another mystery solved ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
gtkglext doesnt exist for GTK3 (and probably never will), so another solution is needed (perhaps SDL) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Gtk3 devs seem to do whatever is required for Gnome3 to run, but nothing else. Not like the good old Gtk2 which was more separated from Gnome2. In my mind GTK still stands for Gimp ToolKit, not Gnome ToolKit.
That said, there seems to be a port of gtkglext to Gtk3, but that hasn't been maintained for 4 years, so fat chance I guess.
SDL will work, I think, though I admit I don't have a lot of experience with it, I mostly deal with either very low level stuff: assemblers, libraries to work with emu files, and C64-native code, or high level database-crap with Python/Qt. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
that "port" is not only unmaintained.... it also doesnt work at all =P not last time i checked anyways, i doubt that changed though :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Are you saying there's crap code on GitHub? I recently started my own repo on GH, the irony! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
even i could make a repo there, so the answer is definitely yes =D |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Wait, there's still meant to be a ./configure? I can see one in the sources for vice-2.2 and vice-2.3, but not in the nightly.
was about to have another run at making sense of the build scripts in build/macosx |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you checked out the svn version, first run ./autogen.sh - that creates the configure scripts |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ah! Thank you. It's a while since I've built anything nontrivial without using a package manager. Not familiar with autogen.
I've now successfully built a binary that, um, crashes on launch. Still, something to debug. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
<abo> vice Jun-25 00:48: gpz * r31325 - /trunk/vice/src/arch/unix/ps-ieee1284.c: fix segfault
:=) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
..and now I've installed some more stuff and am passing sensible values to arch/unix/macosx/make-bindist.sh I finally have a recent OS X cocoa build.
Turns out Jam Ball 2 doesn't work in x64 either, and I know that one at least works on real hardware, so I'm going to stick my fingers in my ears and use x64sc for now.
On the plus side, I can have another run at adding "OS X port maintainer" to my list of hats. Thinking of ditching the OS X+X11 build, mind. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
a lot of stuff doesnt work in x64, there is really no good reason to not use x64sc on a PC these days. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quote: a lot of stuff doesnt work in x64, there is really no good reason to not use x64sc on a PC these days.
I was about to say - just discovered Monochrome also doesn't work in x64.
Off to the glue factory! |
| |
iAN CooG
Registered: May 2002
Posts: 3194 |
Quote: I was about to say - just discovered Monochrome also doesn't work in x64.
Off to the glue factory!
what? works perfecly fine here in x64.exe |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quoting ChristopherJamOn the plus side, I can have another run at adding "OS X port maintainer" to my list of hats.
😘
Quote:Thinking of ditching the OS X+X11 build, mind.
Kill it with fire. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"what? works perfecly fine here in x64.exe"
+1 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Thanks iAN, Oswald; you prompted me to have another stickybeak.
I just nuked my org.viceteam.x64/vicerc (oops, should have thought to try that before), and now Monochrome, Jam Ball 2, and my fastloader test are all fine!
No idea what setting is different at this point; there are a lot of options in the old file that aren't in a freshly generated one. I'll do a binary search if i'm really bored..
Can I have my two weeks back now? Actually, scratch that, at least I can build the nightlies now, which is a good thing in its own right. |
| |
soci
Registered: Sep 2003
Posts: 480 |
Jam ball 2 "fails" here as well not too surprisingly in the default configuration because it's 250 blocks and it's started with kernal load from the generated autostart disk image.
So on your x64sc either it's directly injected or you have cartridge attached which can load under I/O. The difference is very likely that these are not set up in the x64 configuration the same way.
Edit: great, that you've found this out as well while I was composing this message ;) Anyway, I'll keep it. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Sorry soci, I should have mentioned I was using the .d64 with the (not very good) included loader. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Found the culprit.
IECDevice8=1
had somehow snuck into my vicerc; no idea how/when I managed that.
Also, no idea what it does. Anyone? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
what about looking it up in the docs? =P |
| |
soci
Registered: Sep 2003
Posts: 480 |
It lets you access the virtual drive through the IEC bus signals. Can cause similar troubles as another drive left on the bus when using custom loaders. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Thanks all, but I'm still a bit lost. Looks like there are at least three cases, namely
a) IECDevice8=0 DriveTrueEmulation=0
b) IECDevice8=0 DriveTrueEmulation=1
c) IECDevice8=1
I gather case (b) emulates the 1541 CPU plus disk orientation, and one or both of the others just interpret the IEC protocol? But how do (a) and (c) differ?
And would not (b) and (c) both have issues with colliding signals from multiple drives? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
just use the default settings (in the nightly build) - which is "no virtual device traps, true drive emulation enabled, one drive only". anything else will cause problems in one situation or another. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Will do. |
