Login

Back to forum Reply to this topic Go to last reply Posted By IstvanV on 2007-05-16 05:39:11  plus4emu 1.1.0 Changes in version 1.1.0 * implemented 1551 drive emulation * added floppy drive LED display to the GUI (1541 is red, 1551 is green, and 1581 is yellow) * the debugger now allows for debugging floppy drives; the drives are also mapped to the physical address range $180000-$1BFFFF * fixed 1541 disk change detection * keyboard map can be configured with the GUI * external game devices like joysticks and gamepads are supported, and can be assigned in the keyboard map like normal keys * the 'step over' button in the debugger now also skips branch instructions * invalid opcodes that normally jam the CPU can be used as breakpoints (with the priority assumed to be 3) that open the debugger, and the execution of the program can continue as if there was a NOP instruction * added new command line options for loading disk image, snapshot, and demo files on start-up; on Windows, D64 and D81 files are also optionally associated with the emulator * it is now possible to use WAV, AIFF, and other sound file formats as tape images; these files can be read and written, however, new files are created in plus4emu format * blank video output is generated when the TED is disabled by setting bit 5 of $FF07 * reduced horizontal texture resolution to 384 in OpenGL mode when the quality is set to 0, for improved performance * minor GUI improvements and fixes The new version can be downloaded from here: http://sourceforge.net/project/showfiles.php?group_id=192837 Posted By Chicken on 2007-05-16 07:53:52  Re: plus4emu 1.1.0 Hi Istvan, first of all, it's good to see you back because it means that you reconsidered some of the decision you made a while ago. Most importantly, you continued to work on your emulator I just dled the Win32 port and gave it a quick test run. To those who are curious, it installed flawlessly and runs "out of the box". Then I checked some demos which ran just fine. None of these do anything "too tricky", though. I might look into that later on. Finally, I hacked in some tests... e.g. 1010 SEI 1011 DEC $FF1D 1014 JMP $1011 Don't ask if there's any sense in this Though, it looks different on the real machine. I've been messing a bit with TED and lots of things are emulated correctly, even some that only YAPE (until now) gets right. After this quick test, I can't say more, there are just too many options that I haven't used, yet. Hopefully, others will give this emulator a try, too. This will help finding bugs... if there are any Btw, when I reset (F11) after e.g. INCreasing $ff1d the plus/4 screen kinda scrolls down until it reaches its normal position. Is this on purpose? Posted By IstvanV on 2007-05-16 08:26:35  Re: plus4emu 1.1.0 The differences compared to the real machine you noticed when incrementing or decrementing $FF1D in a loop are most likely a television emulation issue, rather than a TED problem. Indeed, the main areas where compatibility problems can still be found are television/PAL emulation (such as the results of using invalid horizontal or vertical synchronization), and a few 1541 fast loaders, so I should mainly improve those. The TED and CPU emulation is probably mostly OK (I do know about a few timing differences in very specific cases, and the effects of writing to $FF1E are not correctly reproduced with some combinations of original/new value, although other emulators do not seem to get these right yet, either), but bug reports are definitely welcome. Posted By Litwr on 2007-05-17 03:14:12  Re: plus4emu 1.1.0 Thanx! Posted By MagerValp on 2007-05-17 07:26:45  Re: plus4emu 1.1.0 After installing all dependencies, and adding /usr/X11R6/include to the CPPPATH in the SConstruct, it compiles on MacOS X. When running ./plus4emu I get a window that refuses to focus when I click on it - it only reacts on the close button (or ctrl-c). Menubar is visible, emulation screen is black. Posted By IstvanV on 2007-05-17 07:39:24  Re: plus4emu 1.1.0 Did you install the ROM images and set up the configuration (the README includes installation instructions for Linux, but OS X should be similar) ? Other than that, you may try running with or without -no-opengl, and compiling with disableSDL set to 1 in SConstruct; I did encounter problems with newer SDL versions on Linux: it seems to conflict with FLTK and cause a crash, so compiling without SDL (which is only needed for joystick/gamepad input) is worth trying. Posted By MagerValp on 2007-05-18 06:07:08  Re: plus4emu 1.1.0 Yes, I ran makecfg and downloaded the roms: .plus4emu .plus4emu/config .plus4emu/config/P4_16k_NTSC.cfg .plus4emu/config/P4_16k_NTSC_3PLUS1.cfg .plus4emu/config/P4_16k_NTSC_3PLUS1_FileIO.cfg .plus4emu/config/P4_16k_NTSC_FileIO.cfg .plus4emu/config/P4_16k_PAL.cfg .plus4emu/config/P4_16k_PAL_3PLUS1.cfg .plus4emu/config/P4_16k_PAL_3PLUS1_FileIO.cfg .plus4emu/config/P4_16k_PAL_FileIO.cfg .plus4emu/config/P4_64k_NTSC.cfg .plus4emu/config/P4_64k_NTSC_3PLUS1.cfg .plus4emu/config/P4_64k_NTSC_3PLUS1_FileIO.cfg .plus4emu/config/P4_64k_NTSC_FileIO.cfg .plus4emu/config/P4_64k_PAL.cfg .plus4emu/config/P4_64k_PAL_3PLUS1.cfg .plus4emu/config/P4_64k_PAL_3PLUS1_FileIO.cfg .plus4emu/config/P4_64k_PAL_FileIO.cfg .plus4emu/config/P4_Keyboard_HU.cfg .plus4emu/config/P4_Keyboard_US.cfg .plus4emu/demo .plus4emu/disk .plus4emu/gui_cfg.dat .plus4emu/plus4cfg.dat .plus4emu/progs .plus4emu/roms .plus4emu/roms/3plus1hi.rom .plus4emu/roms/3plus1lo.rom .plus4emu/roms/dos1541.rom .plus4emu/roms/dos1551.rom .plus4emu/roms/dos1581.rom .plus4emu/roms/p4_basic.rom .plus4emu/roms/p4_ntsc.rom .plus4emu/roms/p4fileio.rom .plus4emu/roms/p4kernal.rom .plus4emu/tape ./plus4emu: can't give focus, menubar visible, black emulation screen ./plus4emu -no-opengl: no focus, menubar visible but laid out across whole window, no emulation screen I recompiled without SDL, and now I don't even get a window. Posted By MagerValp on 2007-05-18 06:30:52  Re: plus4emu 1.1.0 Hmm, I think I know what the problem is. FLTK makes it an actual Carbon binary, and not an X11 program. Carbon apps cannot be run as a plain unix binary (./plus4emu), but needs the supporting structure of a .app package. I created one: plus4emu.app plus4emu.app/Contents plus4emu.app/Contents/Info.plist plus4emu.app/Contents/MacOS plus4emu.app/Contents/MacOS/plus4emu plus4emu.app/Contents/PkgInfo plus4emu.app/Contents/Resources plus4emu.app/Contents/Resources/plus4emu.icns and I can double click it, but it just exits with: *** error: configuration variable is not found Since it's no longer run under a plain unix environment, I'm guessing it's just having trouble finding the config files. For a proper Mac port it should be looking in ~/Library/Preferences and ~/Library/Application\ Support anyway. Having become a father 9 days ago I don't have the time to dig any deeper, but maybe one of the other Mac users in here can do a quick port and submit a proper patch. Posted By IstvanV on 2007-05-18 07:20:19  Re: plus4emu 1.1.0 This error message does not occur when the configuration files are not found, as errors while loading the configuration on start-up are normally ignored. It usually means that an invalid command line option was used, but could also be caused by an internal error (i.e. bug or broken executable). By the way, other projects that use FLTK also seem to create a resource fork with /Developer/Tools/Rez; is that important ? If everything else fails, I also have a hacked version that does not use threads, as FLTK with threading is often a source of problems on OS X. Posted By MagerValp on 2007-05-19 06:47:25  Re: plus4emu 1.1.0 AFAIK you can use a resource fork instead of a .app package, but since it uses filesystem meta data, it's easier to work with .apps from makefiles, when zipping, etc. Hmm, I wonder what ends up in ARGV when you double click on a .app. Posted By IstvanV on 2007-05-19 17:45:23  Re: plus4emu 1.1.0 It can be easily tested if there is a problem with the command line arguments: just add 'argv = 1;' at the beginning of main() in gui/main.cpp, at about line 35. Posted By IstvanV on 2007-05-19 17:46:13  Re: plus4emu 1.1.0 Correction: of course, I meant 'argc = 1;'. Posted By MagerValp on 2007-05-20 14:11:01  Re: plus4emu 1.1.0 argc = 1 did the trick, the emu starts. Nothing shows up in the emulation window though... Posted By IstvanV on 2007-05-20 14:38:39  Re: plus4emu 1.1.0 Are the menus functional ? Can you open the debugger and use the Step button ? If yes, then maybe there is just no configuration loaded, because the file is either not found, or reading it fails for some reason (which may possibly be related to the command line problem). You can check the machine configuration to see if there are ROM files loaded; if there are none, then it should be set up as follows for a minimal working configuration (use the ... buttons to browse files): 00 p4_basic.rom 01 p4kernal.rom Posted By MagerValp on 2007-05-21 03:49:15  Re: plus4emu 1.1.0 A config appears to be loaded: http://www.paradroid.net/tmp/emu.png The CPU is looping at $d90a, part of the keyboard input routine. Posted By IstvanV on 2007-05-21 07:57:24  Re: plus4emu 1.1.0 So, almost everything seems to work, except there is no video display. This could be either because of an OpenGL problem, or a FLTK threading (or other threading) problem. The first possibility can be tested by changing the line 'bool glEnabled = true;' in gui/main.cpp, main(), so that the variable is set to false; of course, this could be set on the command line, but that does not work yet. To find out if there are threading issues, I have uploaded a version of the emulator that does not use separate threads for display/GUI and emulation. This is available in the SVN repository, and can be downloaded with the following command: svn co http://plus4emu.svn.sourceforge.net/svnroot/plus4emu/tags/plus4emu-1.1.0-nothreads By the way, this also includes some commented out code at the beginning of main() that can be used to display the contents of argv[] on start-up in a window. Posted By MagerValp on 2007-05-21 16:21:16  Re: plus4emu 1.1.0 Disabling OpenGL doesn't work, the FLTK GUI gets stretched across the screen. The nothreads version doesn't act any different from the threaded one. When launching the app argv is filled with: '/Users/pelle/src/plus4emu-1.1.0-nothreads/plus4emu.app/Contents/MacOS/plus4emu' '-psn_0_34340865' argv[0] is apparently a Process Serial Number, that you can read about here: http://developer.apple.com/documentation/Carbon/Reference/Process_Manager/Reference/reference.html#//apple_ref/c/tdef/ProcessSerialNumber Probably safe to ignore, but you could use it to detect if the program is launched on a Mac. argv[0] makes it easy to locate plus4emu.app/Contents/Resources, where things like ROM images could be searched for. Posted By IstvanV on 2007-05-21 16:56:21  Re: plus4emu 1.1.0 OK, so I should ignore command line options starting with -psn_ on OS X, and the path in argv[0] could be useful for determining the base directory for data and configuration files (which is currently $HOME/.plus4emu/) when running from an .app. But I am running out of ideas regarding the display problem. What can still be tried is experimenting with the settings in the display configuration dialog, particularly the buffering mode, and maybe setting the quality to zero. The GUI getting stretched in software mode is strange, could removing these lines at the beginning of Plus4EmuGUI::run() in gui/gui.cpp change things (they are originally there to prevent FLTK from automatically resizing widgets while the window is being resized, as it looks ugly): mainWindow->resizable((Fl_Widget *) 0); emulatorWindowGroup->resizable((Fl_Widget *) 0); Posted By IstvanV on 2007-05-21 17:51:49  Re: plus4emu 1.1.0 Hmm, could it be that the way the emulator display is implemented as a child window of the main window is a problem ? The two can be made separate by removing line 232 in gui/gui.fl: code0 {o->add(emulatorWindow);} as well as line 304: emulatorWindowGroup->remove(*emulatorWindow); Posted By MagerValp on 2007-05-22 04:13:52  Re: plus4emu 1.1.0 No go. Display settings don't seem to affect anything. Making the display a global(?) window just makes it appear outside of the emulator window, with a hall of mirrors effect. Making the window non-resizable just lays out the widgets differently. Posted By IstvanV on 2007-05-22 07:13:17  Re: plus4emu 1.1.0 And that happens even without threads, running in software mode, and SDL disabled at compile time ? However, even without display, it can be tested if everything else is working correctly, for example, when opening a disk image, the LED display should turn on, or sound output can be checked by typing a command like >ff11 48 in the debugger (you may need to set the audio output device). The emulator can be stripped down to a minimum (no GUI, no keyboard input, only a video display window) by replacing these lines in gui/main.cpp (nothreads version): gui_ = new Plus4EmuGUI(*(dynamic_cast<Plus4Emu::VideoDisplay *>(w)), *audioOutput, *vm, *vmThread, *config); gui_->run(); with: w->show(); vmThread->pause(false); do { if (!vmThread->process()) { w->hide(); break; } if (dynamic_cast<Plus4Emu::FLTKDisplay_ *>(w)->checkEvents()) w->redraw(); Fl::wait(0.0); } while (w->shown()); Even after that, there is still no video ? Perhaps an alternative frontend needs to be developed that does not use FLTK. Posted By MagerValp on 2007-05-22 16:25:03  Re: plus4emu 1.1.0 OK, finally some positive results Inserting a d64 works, and blindly typing diR makes the LED light up, and I can see a directory listing in the hex dump at $0cf0. >ff11 48 produces noise. The code patch produces a naked basic screen with a blinking cursor, but it doesn't react to input. Posted By IstvanV on 2007-05-22 17:58:41  Re: plus4emu 1.1.0 I think I found the reason why display updates work with the previous hack, but not when using the GUI: FLTK 1.1.7 does not implement the "check" callback (which the GUI uses, but the main.cpp hack does not) on MacOS X for some reason. This has also been reported as a bug earlier by someone on the FLTK forums: http://www.fltk.org/newsgroups.php?s31+gfltk.bugs+v40+T0+Qcheck This bug seems to have been fixed in the recent 1.1.x beta versions (which had some minor glitches like incorrect widget colors when I last tried, though), but there is also a patch in the above mentioned forum post. So, with the check callback fixed (alternatively, the use of such callback could be just avoided, but it is needed to keep the video display up to date even while menus are opened), running the GUI and video display as separate windows, with the modified gui.fl file, should theoretically work. The next step is to have the emulation display in the same window as the GUI, like on the other platforms. I suspect a possible problem here is this (quote from the FLTK manual): "Known MacOS Bugs and Problems ... * Nested subwindows are not supported, i.e. you can have a Fl_Window widget inside a Fl_Window, but not a Fl_Window inside a Fl_Window inside a Fl_Window." Well, I have a Fl_Window inside a Fl_Group inside a Fl_Window. Maybe that is also not supported ? I should probably make changes to remove the Fl_Group. Posted By MagerValp on 2007-05-23 07:29:32  Re: plus4emu 1.1.0 Bingo. I patched FLTK, and voila: http://www.paradroid.net/tmp/plus4emu.png Crackers Demo 4 seems to run without a hitch. Posted By IstvanV on 2007-05-23 10:20:28  Re: plus4emu 1.1.0 That is good news. Do problems like the GUI getting stretched over the whole window still occur ? Is it safe to use the threaded (original) version with or without SDL, in software or OpenGL mode ? Posted By IstvanV on 2007-05-23 11:14:44  Re: plus4emu 1.1.0 Chicken: I think I can implement more accurate emulation of vertical synchronization in the next (1.1.1) release. However, I am not sure about the range of line counts that should still result in a stable display; with my TV card using composite video, I can make it shorter by up to 22 lines, and longer by up to 30 lines, and with no vertical sync at all, it free runs at 312.5 lines, but this probably varies depending on the type of TV/monitor/card being used. Also, I will probably use very low (<= ~280) line counts for detecting NTSC mode. Posted By Chicken on 2007-05-24 10:33:42  Re: plus4emu 1.1.0 Sounds good... Yes, those things depend a lot on the display type used. Some newer TV sets with digital components don't show anythings at all if it's not the type of signal they expect. What kind of TV card are you using? BT8x8 based cards used to be very popular but nowadays there are many Pilips SAA 713x ones around? Maybe we can collect some data with some kind of test suit for various display types. Posted By IstvanV on 2007-05-24 15:38:04  Re: plus4emu 1.1.0 Yes, I do have an SAA713x based card. Here is a simple program I used for testing: http://www.sharemation.com/IstvanV/vsync.prg It can be run with either G 1003 or G 1006. In the first case, it will set an interrupt routine that extends or shrinks the display by changing the number of lines in the bottom border (the amount can be set in $E0 as a 2's complement signed value). The second one skips the vertical syncronization, and is used for testing free running mode; the number of lines is controlled by $E1. A screenshot from the real machine: http://www.sharemation.com/IstvanV/vsync1.jpg and the emulator: http://www.sharemation.com/IstvanV/vsync2.jpg Posted By MagerValp on 2007-05-26 13:28:10  Re: plus4emu 1.1.0 Threaded, with SDL, in OpenGL mode works fine, and no stretching. The QCheck was all that was needed. Posted By IstvanV on 2007-05-29 09:20:10  Re: plus4emu 1.1.0 OK, I have added the -psn_* command line fix, and the FLTK patch to the SVN sources. The current version can be downloaded with: svn co http://plus4emu.svn.sourceforge.net/svnroot/plus4emu/plus4emu The .app could also be uploaded to the SVN. If you would like to create a binary package, I can add it to the SourceForge download page when 1.1.1 is released. Posted By MagerValp on 2007-05-29 14:57:29  Re: plus4emu 1.1.0 I checked out the patched source and built a .app: http://www.paradroid.net/tmp/plus4emu-macosx-i386.zip All that's needed to build is adding /usr/X11R6/include to CPPPATH in the SConstruct. If you send me a 128x128 source image (32-bit png with alpha) I can make a proper icon for it. Posted By IstvanV on 2007-05-30 07:23:35  Re: plus4emu 1.1.0 Thanks, the .app files (except the binary) and the include path fix are now in the SVN. The plus4emu executable is copied to the .app by SCons. By the way, does an .app need to be created for makecfg - which also uses FLTK - as well, or does that work from the command line ? In any case, it should probably be included with a binary package. Is the executable in the .zip file statically linked against the dependencies (FLTK, PortAudio, libsndfile, dotconf, and SDL) ? I built the Linux packages that way, so that they work if the user does not have some of the libraries, or an incompatible version is installed. I do not have an icon yet, so for now I just used the one from the .zip file. Posted By MagerValp on 2007-06-01 07:26:06  Re: plus4emu 1.1.0 I just ran makecfg from the commandline. It should probably be included in the .app, and executed automatically on startup if the config directory doesn't exist. Could you make the emulator look in ~/Library/Application\ Support/plus4emu when it's started on a mac? The binary is not statically linked, so I guess it's kinda useless. How do I get the SConfig to statically link the libs in /usr/local/lib? The rest are standard system libraries: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.5.1) /usr/local/lib/libdotconf-1.0.0.dylib (compatibility version 11.0.0, current version 11.4.0) /usr/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.0.0) /usr/local/lib/libportaudio.0.0.19.dylib (compatibility version 0.0.19, current version 0.0.19) /usr/local/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.17.0) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Posted By IstvanV on 2007-06-02 09:39:14  Re: plus4emu 1.1.0 OK, I can replace ~/.plus4emu with "~/Library/Application Support/plus4emu". Is it safe to assume that "~/Library/Application Support/" already exists ? makecfg could indeed be run automatically when there are no configuration files, although finding it if it is not in the PATH may be an issue. Or should it be just integrated into the main plus4emu executable ? That way, it could be run explicitly with a command line option like -makecfg; adding "reinstall configuration files" to the menu is also possible. The simplest way to make sure that the libraries are statically linked is to remove any dotconf, SDL, portaudio, sndfile, and fltk dylibs (although FLTK is apparently already static), and build static libraries instead; this is typically done with configure options like --enable-static --disable-shared. Alternatively, if the dynamic libs are to be kept as well, it is possible to instruct the linker to use static versions of specific libraries, for example: g++ -L. -Wl,-rpath,/usr/local/lib -o plus4emu gui/gui.o gui/gui_fl.o gui/disk_cfg_fl.o gui/disp_cfg_fl.o gui/kbd_cfg_fl.o gui/snd_cfg_fl.o gui/vm_cfg_fl.o gui/debug_fl.o gui/about_fl.o gui/main.o -L/usr/local/lib -L/usr/X11R6/lib64 -lplus4emu -lresid -Wl,-static -lfltk_gl -Wl,-Bdynamic -lGLU -lGL -Wl,-static -lfltk -Wl,-Bdynamic -lpthread -lm -lXext -lX11 -Wl,-static -ldotconf -lSDL -lportaudio -lsndfile -Wl,-Bdynamic -ljack -lasound -lpthread -lrt Of course, the exact command line is different on OS X, so you should just build with scons first, then copy and paste the linker command line, enclosing any libraries that are not standard system libraries within -Wl,-static and -Wl,-Bdynamic (hopefully the flags are the same on the Mac). Perhaps I can add this as an option to SConstruct somehow. Posted By IstvanV on 2007-06-02 09:52:29  Re: plus4emu 1.1.0 One more issue I would like to solve/improve in the 1.1.1 version is 1541 serial bus timing. I did find a trick that allows Crackers' Demo 3 and Grand Prix Circuit to load, but it is ugly; maybe it also breaks some other loaders. However, without hacks, I could not get these to work so far, even after a lot of experimenting. Posted By MagerValp on 2007-06-02 15:29:48  Re: plus4emu 1.1.0 Application Support exists by default. On the mac you can just stick makecfg in plus4emu.app/Contents/MacOS/makecfg, and it can be run with ./makecfg. I can make a shell wrapper that does it automagically. Integrating it into the main executable is probably nicer on windows and linux though. Adding -Wl,-static gives the somewhat cryptic "/usr/bin/ld: only one of -static or -dynamic can be specified". There seems to be an implicit -dynamic somewhere. ld doesn't accept the arg -rpath: "/usr/bin/ld: unknown flag: -rpath". I think it's safe to say that ld is a different beast on MacOS X (Mach-O is used instead of elf...) Posted By IstvanV on 2007-06-02 16:08:11  Re: plus4emu 1.1.0 Another possible method for static linking is copying the .a files to the plus4emu directory before running scons, so that they are found instead of any dynamic libraries installed on the system. This is actually how I build the Linux binary packages. Posted By IstvanV on 2007-06-02 17:48:25  Re: plus4emu 1.1.0 It seems I have found a solution to another problematic demo: "Exacting demo" apparently only loads with the 1541 ROM, and not the 1541-II, which I have been including with the ROM package until now. Perhaps I should make the former (more precisely, the combination of 1540-c000.325302-01.bin and 1541-e000.901229-05.bin from zimmers.net) the default ? Posted By MagerValp on 2007-06-03 12:03:56  Re: plus4emu 1.1.0 Moving the .a files into the plus4emu build directory has no effect. Explicitly linking lib*.a leads to a bunch of unresolved symbols, but through trial and error I arrived at these: g++ -o plus4emu -L. gui/gui.o gui/gui_fl.o gui/disk_cfg_fl.o gui/disp_cfg_fl.o gui/kbd_cfg_fl.o gui/snd_cfg_fl.o gui/vm_cfg_fl.o gui/debug_fl.o gui/about_fl.o gui/main.o -lplus4emu -lresid -lfltk_gl -lfltk /usr/local/lib/libfltk.a /usr/local/lib/libfltk_gl.a /usr/local/lib/libdotconf.a /usr/local/lib/libSDL.a /usr/local/lib/libportaudio.a /usr/local/lib/libsndfile.a -framework AGL -framework OpenGL -framework Carbon -framework ApplicationServices -framework CoreAudio -framework AudioToolbox -framework AudioUnit -framework IOKit -framework QuickTime -framework AppKit g++ -o makecfg -L. installer/makecfg.o installer/mkcfg_fl.o -lplus4emu /usr/local/lib/libfltk.a /usr/local/lib/libdotconf.a -framework Carbon Phew! You can grab a new .app here: http://www.paradroid.net/tmp/Plus4Emu-MacOSX-i386.zip Included is also a shellscript the checks if lib/appsupport/p4emu exists, and runs makecfg otherwise. Of course makecfg still creates ~/.plus4emu by default, so it doesn't quite work... It would also be good if makecfg could be run non-interactively, and just create the config in argv[1]. PS: Yes, original 1541 roms (325302-01 and 901229-05) are a better default. Posted By IstvanV on 2007-06-03 18:20:29  Re: plus4emu 1.1.0 The SVN sources are now updated. The changes include: SConstruct copies 'makecfg' to the .app package; the base directory for configuration etc. has been changed from ~/.plus4emu to ~/Library/Application Support/plus4emu on OS X; the main executable automatically runs makecfg on all platforms if the configuration file is not found (the command path is guessed from argv[0]); new option for selecting 1541 timing emulation mode. I have also replaced the 1541 ROM file, and renamed the 1541-II one to dos15412.rom. The makecfg utility does allow for specifying the path on the command line, and it does not display the file selection dialog then, although there is still the other window that asks for confirmation. A command line option like -f could easily be added, though, to force (re)installation without any dialogs. I will add the framework flags to SConstruct (I do recall -framework Carbon -framework ApplicationServices being needed when using FLTK). Posted By MagerValp on 2007-06-04 04:57:17  Re: plus4emu 1.1.0 cp does not accept the a flag: mkdir -p plus4emu.app/Contents/MacOS ; cp -af makecfg plus4emu.app/Contents/MacOS/makecfg cp: illegal option -- a usage: cp [-R [-H | -L | -P [-f | -i | -n] [-pv] src target cp [-R [-H | -L | -P [-f | -i | -n] [-pv] src1 ... srcN directory scons: *** [plus4emu.app/Contents/MacOS/makecfg] Error 64 The frameworks are only needed when building statically linked binaries, when you link dynamically it's all handled automagically. Posted By MagerValp on 2007-06-04 04:59:23  Re: plus4emu 1.1.0 Hmm, after svn update I get a black screen again. Posted By IstvanV on 2007-06-04 05:51:34  Re: plus4emu 1.1.0 The cp error should be fixed now. The black screen may be caused by the change from ~/.plus4emu to ~/Library/Application Support/plus4emu, if the ROM files have not been copied to ~/Library/Application Support/plus4emu/roms. Posted By IstvanV on 2007-06-04 06:08:20  Re: plus4emu 1.1.0 Also, you may try deleting ~/Library/Application Support/plus4emu/plus4cfg.dat that has probably been created. Then, after the ROM files are installed, running the emulator should automatically start makecfg. Posted By IstvanV on 2007-06-05 10:32:30  Re: plus4emu 1.1.0 Well, it looks like the new version is getting ready for release. Is there anything left to be done ? Does the current SVN work without problems ? If everything is OK, I will test on Linux and Windows, and create packages soon. Posted By Chicken on 2007-06-05 11:07:33  Re: plus4emu 1.1.0 My PC here doesn't have a tv card so I wasn't able to test anything. It's on my list, though, and I'll try it whenever I get the chance to. Have you tried various speeders/demos/games with the old 1541ROMs? Most ppl I know had a 1541-II back then and never complained about demos that weren't working because of the drive. Though, I have to admit, I don't know if there are programs that refuse to work with the old ROM set. And if Exacting Demo is known to only run with the old ROM set, it's probably the best way to go for now. Posted By IstvanV on 2007-06-05 11:32:27  Re: plus4emu 1.1.0 Actually, the problem with "Exacting demo" was caused by not emulating correctly the CPU I/O port data direction register ($0000). While there is normally not much use setting it to anything other than the default of $0F, this demo has a protection that temporarily overwrites the I/O port registers with garbage, and with the original code, this caused the 1541 ROM to lock up because of a bogus ATN signal. It was only a coincidence that with some older DOS revisions the problem did not seem to occur. Anyway, I have fixed the $0000 register to work correctly, and now the demo loads without problems; I did not test it with the 1541-II yet, but now that I found the real problem, I would expect it to work as well. However, the ROM version I mentioned earlier (1540-c000.325302-01.bin and 1541-e000.901229-05.bin) is apparently also used by YAPE, and it is probably a safe default. I still include the 1541-II DOS with the ROM package as 'dos15412.rom', and you can easily load it in the machine configuration. What still needs some testing is the new alternate 1541 timing code that fixes several loaders that previously failed; so far, it seems to work quite well, even if I used a hack to work around the loader used in e.g. Crackers' Demo 3. Posted By IstvanV on 2007-06-05 12:22:49  Re: plus4emu 1.1.0 Hmm, maybe I have just found the solution to the 1541 timing ? After reducing the serial bus delay in the drive emulation from one cycle to a half cycle (500 ns), Crackers' Demo 3 and GPC load without any hacks. I always tried increasing it until now, that may explain all the experimenting with no results. This should be tested more. If it works well, I should probably name the new timing mode "high accuracy", rather than "hack". Posted By IstvanV on 2007-06-05 14:32:32  Re: plus4emu 1.1.0 The new 1541 timing code is in the SVN now, and enabled by default. Posted By MagerValp on 2007-06-05 17:17:55  Re: plus4emu 1.1.0 The now built in makecfg needs to be made non-interactive. It pops up a file requester that doesn't accept focus, though you can click the OK button. I don't quite see what good the file requester is, as there's no point in installing the files anywhere else. The Reinstall plus4emu configuration files popup is also superfluous, or at least misnamed, as it's installing for the first time, and not reinstalling. Maybe Hungarian keymap support can be moved into the program prefs? OK, first time you launch, and click past the file requester and hungarian keymap popup, you get a black screen. After unzipping the roms and relaunching you still get a black screen, as config->machine->memory isn't initialized. After loading one of the configs, the emu finally starts. It's a lot of hoops to jump through. You should consider shipping the roms with the application - VICE already does this, and has been doing it for over ten years, without any problems. Posted By IstvanV on 2007-06-05 17:57:17  Re: plus4emu 1.1.0 OK, I have changed the SVN sources so that it is now non-interactive on OS X, using the newly added -f flag. It is possible to change the keyboard layout later by loading one of the configuration files created by makecfg. The reason why the ROM setup is uninitialized if the files are installed only after running the emulator is that files that are not found are automatically cleared from the configuration so that errors will not keep occuring repeatedly. So, the ROMs should either be installed before launching the .app for the first time (as suggested by the README), or the configuration needs to be reinitialized by loading one of the presets, or deleting ~/Library/Application Support/plus4emu/plus4cfg.dat and running the emulator again. While packaging the ROM images with the releases is technically easy to do, I am not sure about the possible licensing issues, since it is only allowed to host open source free software on SourceForge. Back to top Reply to this topic Copyright © Plus/4 World Team, 2001-2024