Search the Community
Showing results for tags 'MAC'.
Found 3 results
I opened this thread because of two reasons, i know it's problematic to run a program like jtintv from terminal, GUIintv is a very good solution. but also i expect that a lot of users will stumble over the need of "SDL 1.2" to start jzintv in OSX. though to first remind of this fact and offer the link to "SDL 1.2". https://www.libsdl.org/download-1.2.php release 2.0 won't work with jzintv osx! second to give some hints how to start jzintv from the osx terminal and to offer my "run from file" compilation of batch files start the emulator from a gamespecific icon. how to run jzintv from terminal? in general it's something like this: path/jzintv -p path/rom romimagename where "path" is your path to the jzintv folder (wherever you unpacked jzintv), assuming the system roms are named exec.*, grom.* and ecs.*, and present in the "rom" folder of "jzintv", as well as the romimage you like to load is present in "rom". romimagename is the name of the romimage to load without suffix (.int,.bin,.rom), jzintv recognizes the type itself. if there are spaces in the path or in the names like "home/my jzintv" or "some game.bin" the whole path or name will have to be in quotes with this call jzintv will open in a 320x200 sized window. we want a larger window or fullscreen of course. there are a vast amount of flags you can set for jzint if you type path/jzintv -help jzintv will type out all the flags for jzintv the flags for jzintv: that's quite alot! we won't need the most if you just like to run a game path/jzintv -p path/rom -z1 -a11025 romimagename -z is the resolution mode (640x480,8bitplanes) in this case, -a the samplerate or path/jzintv -p path/rom -p path/romz -z960x600,8 -f1 -a11025 -q romimagename -z is now a custom resolution, -f1 determines it should open in fullscreen mode, -q suppresses the output in the terminal. an interesting flag is the scaler (--prescale=), looks a bit funny if the games loose their blockyness. after all no big thing to start jzintv. no one except a keyboard fetishist likes to type in these commands each time he likes to play a game. it's obvious if you don't have a GUI like GUIintv is you will need small executables witch contain your most used flags to run jzintv this is how "run from file" was born, i made the tedious work to create for almost all games a small batch file on which i attached my icons while they will call a general batch with the most used flags the games batch are still editable to set specific flags like -s1 (use ecs). i hope this covers the questions one can have how to run jzintv osx. but of course as long as i'm present in web i can answer questions.
Deluxe Emplant card for Amiga with Zorro slots. Key MAC chips for running MAC software on a Zorro capable Amiga with 68020 or better CPU. All 5 RAM slots are populated and properly set for maximum RAM. New battery installed to maintain RAM contents. Has the e586DX expansion added. Do not have reliable floppies with software, but the Emplant software is freely available on the net. Fully supported by Fusion 3.2 (latest version.) Includes the MAC's VIA chips, MAC compatible serial & device ports, SCSI interface, and SIMM slot to read SIMM based MAC ROMs. Can also read chip based ROMs but the RAM chips will need to be temporarily removed to read those. Does not run the ROM from the board, but makes an image, so only need to remove the RAM to read the ROMs once. Asking $125 + shipping & PP fees. SOLD!
I started a new topic: "OS X issues" with focus only on the OS X specific problems/changes, etc. The Logic Analyzer helped me to understand the lower communication speed over Bluetooth. The timing of the Bluetooth stack in the OS X seems to be ugly. Instead of expected ~50ms pauses between data chunks I observed ~250ms pauses (200ms additional delay in OSX BT stack?) Additionally bigger data chunks were not transmitted in one shot. With "bigger" I mean a diskette sector + checksum (129 bytes), There was a 200ms pause in between. The virtual serial port is opened with O_NDELAY parameter, so the "read()" and "write()" calls are non blocking. The "write()" call will not necessarily process all bytes. It returns the number of bytes that could be written. The still awaiting bytes have to be sent in the next "write()" call (in a loop) and this happens for 129 bytes (sent in to chunks: 126 + 3) At the end, the data transfer was successful, but I don't have any idea how to improve that