|
| |
There are 105 guests and 1 MSX friend online
You are an anonymous user.
|
| | | | Saturday, May 29, 2004 - 01:43 Submitted by: mth Topic: Emulation | | It was a long wait, but it happened: openMSX 0.4.0 was just released. The highlight of this release is Catapult, which has grown to be a fully featured GUI for openMSX. Also, the following improvements were made: (read release notes for more details)
- Implemented TCL as central scripting language (including console)
- New build system which replaces the GNU auto* tools
- Added support for compiling on FreeBSD 4 and 5. Thanks to ag0ny, Jorito and Reikan. Also updated support for Mac OS X, thanks to Jalu
- New frameskip/sync algorithm, which can deal much better with the situation where another process or the OS claims the CPU for a while. As a result, animation and music play more fluent and openMSX feels faster
- Better CPU timing (Z80 and R800) and also for R800 specifically: CAS/RAS optimization, refresh delay, IO operations take 3 cycles
- CPU frequency is not fixed anymore: Frequency can be unlocked and modified from the console and the "6MHz mode" of Panasonic MSX2+ machines is now supported
- Fixes in TurboR FDC: FDD LED, disk change signal, drive detection, empty drive behaviour (Disk offline). Thanks to Tetsuo Honda
- Finalized internal mapper for Panasonic FS-A1FM and added support for its "frontswitch" for the firmware
- RS232 interface in Sony_HB-G900P has 2kb RAM
- Sony HBI-55 datacartridge now fully implemented
- Added proper support for Koei and Wizardry mappers (with SRAM). Thanks to dvik (blueMSX author) for the info
- Added about 14 new machines
- Volumes are all in a 0-100 range now; added master_volume setting
- Several optimisations in rendering
- Fixed sprites in overscan
- Added basic frames-per-second indicator
- New "type" command: use to enter text into the MSX keyboard buffer (not finalized yet)
- Added a debugger interface to more devices. New debug interface commands
You can download openMSX 0.4.0 here
Related link: openMSX Home Page |
| | |
|
| By mth on May 29 2004, 01:57 | Admins: please fix the download link.
| | |
| By snout on May 29 2004, 01:59 | whoops 
| | |
| By mth on May 29 2004, 02:02 | Thanks! MSX-ers never sleep, do they? 
| | |
| By snout on May 29 2004, 02:03 | at least some don't
| | |
| By tfh on May 29 2004, 15:41 | Cool, finally a version with a GUI  Now let's play around with this one for a bit
| | |
| By Maggoo on May 29 2004, 20:59 | Great update but... what happen to sound quality ??? 0.3.4 was great and now MSX Audio sounds like it goes thru bad amateur radio receiver....
| | |
| By manuel on May 29 2004, 21:01 | There's a small problem with the packaged settings.xml file. The Mixer settings have a 'samples' parameter of only 512. Try to increase it to 1024, 2048 or even 4096... For Windows the value needs to be higher sometimes. But we forgot to change it before we packaged it. Note that too high values introduce a delay in the audio.
| | |
| By Maggoo on May 29 2004, 21:17 | Aah, MUCH better like this, thanks
| | |
| By manuel on May 29 2004, 21:19 | What value did you use, in the end?
| | |
| By Maggoo on May 29 2004, 22:41 | 2048 sounds about right
| | |
| By SLotman on May 29 2004, 22:58 | Is it me or this version is a LOT slower than previous versions?
Common, there's LAG when I am typing on BASIC....!!
| | |
| By flyguille on May 29 2004, 23:53 | well, what's the minimun PC requirements for a good speed?? Is much slower?
got the CAPS problem fixed?... can be fixed?
| | |
| By manuel on May 30 2004, 09:39 | It shouldn't be much slower than 0.3.4 at all! Please join our IRC channel so that we can try to find out what is going wrong. #openMSX on irc.freenode.net.
| | |
| By TS on May 30 2004, 11:31 | Hi, I just like to pay my respect to the openMSX dev team for there great effort.
I been waiting for this update and and it truely worth the wait.
The combination of catapult is beautiful and a great joy using it.
I dig the adjustable effect setting. Changes of blur & glow in realtime
is simply fantastic! (I was playing around with this feature and
forgot to play the actual game.)
Anyway keep up the good work & congrad!
-toshinho (TEAM blueMSX)
| | |
| By manuel on May 30 2004, 11:51 | On behalf of all openMSX developers: thanks a lot Tishinho!
| | |
| By manuel on May 30 2004, 11:52 | Sorry: toshinho!
| | |
| By snout on May 30 2004, 12:23 | A huge step ahead once again! I'm looking forward to the next run of Emulator Comparison tests!
| | |
| By djh1697 on May 31 2004, 22:50 | It is a lovely emulator, shame it doesn't want to work with the MSXmania disk images.
| | |
| By Vincent van Dam on June 01 2004, 09:28 | That's actually an incompatebility in the dsk images from MSX-1-MANIA. I created a perl script that can fix a dsk image, but I havn't got around to fix, test and reupload all the images.
| | |
| By manuel on June 01 2004, 09:38 | Vincent, can you explain to me in detail what the exact problem is?
The loader seems to hang the MSX, but David Haslett said it does work on a real MSX... This seems to indicate a bug in openMSX...
| | |
| By turbor on June 01 2004, 12:31 | Vincent, correct me if I'm wrong (we mailed about this).
It is the fact that the diskimages are SS-sized (360KB) but contain a bootsector that says it is a DD-sized image (well the boot sector is saying half-and-half about it iirc)
So the trouble in openMSX is the way you map a sector/track towards it offset in the diskimage. For the first track this doesn't pose a problem, but the actual data sectors for the file were/are wrongly calculated because of this contradicting info.
So it has to do with how we decide if a disk needs two heads. Since we read the 'faulty' info of the 'corrupt' bootsector..., if we would simply use the image size to decide if we need one or two drive heads then the result would be different :-). On a real MSX you actually send your heads to the correct physical track, without regard if it is the top or bottom drivehead we need to use, so it works on a real MSX.
| | |
| By Vincent van Dam on June 01 2004, 17:53 | Yes, that's correct. The image has $f9 as media type, 2 sides, but only 720 sectors. This is caused by a flawed master image. Basicly, it should be handled as a double sided disk.
The fix I made replaces the boot sector with one for a single sided disk, and moves the fat to the and directory records to their equivalent single side place.
| | |
|
|
| | |
