Navigation ::
blueMSX forum
FAQ
::
Search
::
Memberlist
::
Usergroups
::
Register
::
Profile
::
Log in to check your private messages
::
Log in
blueMSX forum Forum Index
->
News Updates
Post a reply
Username
Subject
Message body
Emoticons
View more Emoticons
Font colour:
Default
Dark Red
Red
Orange
Brown
Yellow
Green
Olive
Cyan
Blue
Dark Blue
Indigo
Violet
White
Black
Font size:
Tiny
Small
Normal
Large
Huge
Close Tags
[quote="mars2000you"]2010 was a very difficult year for the blueMSX team, this for personal reasons. We have however made some additions and improvements, but all is not ready for an official release. As these additions and improvements can interest some people, we have decided to release a beta version for Christmas ! :D Remember : it’s a beta version, only the core of the emulator is updated and some bugs could appear. [b]Important : if you get audio problems with this beta, please deselect the option "Enable reverse playback" in the Options/General menu before booting a machine[/b] What’s new ? - added support for smooth rewind of emulation (check hotkey in shortcut editor) - added support for ColecoVision Super Action Controller - added support for ColecoVision Super Expansion Module hardware - added support for ColecoVision Expansion Module #2 using mouse - added support for Parallax ARC cartridge - added support for stereo PSG in MSX machine configuration - fixed critical bug that caused trainer and cheats to fail as well as memory writes in the debugger when any of the following languages were selected : Catalan – Chinese Simplified - Chinese Traditional – Dutch – Finnish - Russian - fixed bug in handling of transparent sprites - fixed ARTRAGs VDP command engine bug - fixed ‘no frequency’ bug in SN76489 emulation - fixed minor bug in Beer IDE emulation You can find this beta here : http://www.bluemsx.com/rel_download/blueMSX_2.8.3_beta.zip[/quote]
Options
HTML is
OFF
BBCode
is
ON
Smilies are
ON
Disable BBCode in this post
Disable Smilies in this post
All times are GMT
Jump to:
Select a forum
blueMSX Foreign Users Forum
----------------
日本語 ユーザー フォーラム
バグ報告
blueMSXへの質問
blueMSXへの要望
FAQ
blueMSX Users Forum
----------------
News Updates
General discussion
Cheats
Questions & Answer
Suggestions
Suggestions Addressed
Bug Reports
Compatibility Reports
FAQ
blueMSX Betatesters
----------------
General forum - Beta Testers
Bug Report - Beta Testers
Topic review
Author
Message
clockwise
Posted: Wed Feb 09, 2011 11:51 am
Post subject:
dvik wrote:
There was an issue related to the rewind that caused some tearing. We fixed that issue, and replaced the old download zip with a new one (same link) you could try that one and see if it works better.
thanks, but just tested, it's just same binary (http://www.bluemsx.com/rel_download/blueMSX_2.8.3_beta.zip)
...same CRC, tearing....
bidouille
Posted: Sat Jan 29, 2011 8:08 am
Post subject: ADAM
This brilliant future updated
Disappointment however is that the extension of the console Coleco ADAM is still not supported, consider you one day add to the list of ADAM consoles emulated.
géniale cette mis à jour à venir
une déception néanmoins c'est que l'extension ADAM de la console COLECO n'est toujours pas supporté, envisagez vous un jour d'ajouter l'ADAM à la liste des consoles émulées.
LoC
Posted: Thu Jan 06, 2011 1:42 pm
Post subject:
Hi,
Yes, the updated version works much better, thank you. There's however still a small difference with 2.8.2. Can it be that you implemented some sort of dynamic vsync in 2.8.3?
I'm asking because in 2.8.2 when I'm running say an MSX2 demo which has a smooth horizontal text scroll (FacDemo4 for example) , then every once in a while it would make a visible skip (probably because the screenmode I use on my old MSX monitor isn't 100% aligned in timings to the MSX, I'll explain below). Whereas in 2.8.3 at the points where it would make a visible skip in 2.8.2 it makes visible screen tearing for a short moment.
If I look closely than I see a visible screen tear starting at the top of the screen which slowly moves downwards. It's visible with the vertical text scroll on the right of FacDemo4. The screen tear slowly moves downward and then reaches the horizontal scroll, which then shortly tears, then everything is smooth again, and a second later I see the tear starting to move slowly from the top of the screen again to the bottom. This process repeats continuously. This tearing effect is also visible in 2.8.3 with other demos that have smooth scrolling.
Now please bear with me for a (technical) explanation of my current screen setup.
I have attached my old MSX monitor as a second monitor to my PC with the help of a VGA to SCART cable and the utility Soft15Khz (which adds custom 15Khz screenmodes to any modern ATI or Nvidia gfx cards), as explained in my post in the suggestions forum,
see here
.
Soft15Khz creates custom screenmodes based on what is called a "modeline". This modeline specifies both the horizontal and vertical active pixel time, front and back porch time (horizontal and vertical blanking) and the horizontal and vertical sync time. The modeline specifies it in the following format:
Modeline <NAME> <PIX_FREQ> <H_AKTIV> <H_START> <H_END> <H_TOTAL> <V_AKTIV> <V_START> <V_END> <V_TOTAL> <OPTIONS>
PIX_FREQ stands for the Pixel Frequency, in MHz. Important is that the frequency can only be specified up to 2 decimals, so e.g. 5,37Mhz. More decimals gets rounded to the nearest two decimals.
H_ACTIV stand for the active Pixels horizontally
H_START stands for the beginning of the Synchronisation on the horizontal line.
H_END stands for the end of the Synchronisation on the horizontal line.
H_TOTAL stand for the total pixels on the horizontal line.
V_ACTIV stands for the active lines vertically.
V_START stands for the beginning of the Synchronisation vertically
V_END stands for the end of the Synchronisation vertically.
V_TOTAL stands for the total number of lines vertically.
Now to make it even more complicated the time between H_ACTIV and H_START is the "front porch", which stands for horizontal right blanking time. The time between H_END and H_TOTAL is the backporch, which means horizontal left blanking time. The time between V_ACTIV and V_START is the vertical bottom blanking and between V_END and V_TOTAL is the vertical top blanking. The blanking periods are there for making old monitors go from active display to black, to prepare the electron beam of a monitor or tv to make the vertical or horizontal retrace, after which it can start to draw the next horizontal line (or when at the end of a frame retrace back to the top to start the next frame).
OK, still with me?
. Now to create a screenmode that lines up with the timings of an old computer (like the MSX2), one needs to know the timings of the video display chip of that old computer. So for BlueMSX running in MSX2 mode, one needs to know the exact timings of the Yamaha V9938. Something which you are experts in I can imagine
It has taken me a while to figure that one out, but after understanding the above I've been looking for the technical handbook of the V9938, which actually contains extremely useful information about the exact timings.
According to the Yamaha V9938 handbook the V9938 runs at 5,37Mhz. This is slightly different from the MSX VDP, which according to the TMS 9918 handbook runs at 5,3693175Mhz.
5,37Mhz equals 1/5,37=0,1862 microseconds displaytime per pixel.
In the handbook both active display time, horizontal and vertical blanking and horizontal and vertical synchronization periods are specified, see page 128 of the Yamaha V9938 technical handbook. But, timings in analog circuitry allows for some deviation from typical timings. So the timings are specified as "Min.", "Typ." and "Max". Taking for example the active display time of the 9938 equals Min=47microsec, Typ=47.68microsec, Max=48microsec.
At a rate of 5,37Mhz, these equate to Min=~252pixels, Typ=~256pixels and Max=~257pixels of active display per horizontal line. These sort of deviations are also applied to the timings of the hor. and vert. borders, blanking and sync timings as well.
My guess is that BlueMSX runs somewhere between typical timings and the allowed deviations or does it run at exact typical timings? Since that was a little hard for me to find out I experimented with various timings based on my knowledge gathered from both the TMS 9918 and Yamaha 9938 handbooks.
The interesting part is that if I run BlueMSX in "Sync to MSX refresh" mode, that especially the length of the left and right blanking periods have a large impact on the accuracy of the joystick input! Since I'm a big Nemesis series fan, I tested it extensively with Nemesis 2. I have a SUZO Arcade joystick attached to my PC through the Stella Adapter and also a real MSX (Philips NMS8250) attached through a switchbox on the same monitor. That supplies me with a good reference on playing Nemesis 2 on the real thing.
What I found out whas that when I extend the left blanking time that a lot of input lag on the joystick is introduced, especially in the parts of Nemesis 2 where there is slowdown on the MSX part. This gets even worse with Salamander as there are many more parts where there is slowdown. The BlueMSX joystick input starts to lag then in a way which introduces a lot of "floating" movements of your ship.
My current PC system consists of Windows 7 64-bit, a powerful Intel Core I7-920 and an Ati 4850 video card. I'm running BlueMSX with the settings recommended by Ootake (author of Pc-Engine emulator 'Ootake', see here:
http://www.ouma.jp/ootake/delay-win7vista.html
), to minimize joystick input lag created by the PC/Windows system. He also has some advice for emulator authors to minimize input lag in the emulation coding and get PSG sound as close as possible to the original. You might be aware of these suggestions, but just in case, see here:
http://www.ouma.jp/ootake/delay.html
So to make a long story short(er) I experimented with the timings until a point where sync timings are in line with the handbook, which makes for almost perfect smooth scrolling in MSX2 demos AND has the least joystick input lag on Nemesis 2 and Salamander.
The Modeline that I'm using now takes together active display time and left and right border to come out at 281 "active" pixels (256+left and right borders), 5 pixels for the left blanking, 25 pixels for hsync, and 31 pixels for the right blanking, to come out at total pixels per horizontal line of 342 (the typical timing specification for both MSX1/2).
The vertical time has 313 total lines, 3 lines for bottom blanking, 3 lines for vertical sync and 13 lines for the top blanking. Active display + top and bottom borders come out at 294 lines (212 plus the borders).
Running at 5,37Mhz the modeline is as follows:
modeline "281x294@50,16535" 5,37 281 286 311 342 294 297 300 313 -hsync -vsync
I would greatly appreciate it if you could let me know what the exact timings of BlueMSX are? That way I can possibly improve on the timings in the above modeline and do even better testing with BlueMSX.
Now a last thing to make the subject of exact replication of MSX timings even more difficult, is that there is apparently some roundings in modern videocards as well, which gives rise to a slight difference between requested timings and the actual timings.
To give an example, the above modeline requests a screenmode that has total timing dimensions of 342x313 at 5,37Mhz. That should theoretically give 50,16535 frames per second. BUT, if I test the actual FPS by running the tool 'Frequency Test 1.6', see
http://www.mediafire.com/?lycrjcm55j37n
, then I get 50,2044 frames per second!
The above probably explains why BlueMSX in 'Sync to MSX Refresh' still shows a very small visible hickup on smooth scrolling MSX2 demos every X seconds! Or is there something else happening?
Now I've tried extensively to create modelines with different timings to see if I could get smooth scrolling, but that I now believe is not possible without some modification to the BlueMSX options. There will always be some difference between the requested video timings from the modern video card and what the actual output will be. The only way to accomodate for this requested input versus output timing, would be to make a slider in BlueMSX where you you could make a tiny adjustment to probably the Pixel Clock rate at which BlueMSX runs to get it fully in Sync with the actual 15Khz video output of the PC.
For the above example that would mean moving the slider to make BlueMSX run the emulated VDP at 5,37418 Mhz, to get the output fully in sync with the actual output of the PC, i.e. 50,2044Hz. The change in Mhz actually would even fall within the allowed deviations of the specified analog timings? Or if you can think of another solution to accommodate this problem, that would be highly appreciated.
Now I know this is a very long story, but I feel strongly about the fact that BlueMSX is so very close to perfect emulation of the MSX, that with accounting for the above it would get to full 100% perfect emulation for the people who are willing to go through the "trouble" of actually setting BlueMSX up on their PC with a real MSX monitor or old CRT TV. There is nothing more bliss as total perfection and being able to run BlueMSX in the knowledge that it looks and feels like the real thing
So to round up, because it has been such a long story, I would appreciate it if you could let me know
- What the currently used exact timings of BlueMSX are for the video display in 'sync to MSX refresh' mode, and
- If it would be possible to add an option to adjust the BlueMSX timings (e.g. the pixel clock rate) and accommodate for the difference between requested screenmode timings through Soft15Khz and actual output timings. Or maybe some other solution you can think of?
Thanks and best,
LoC
dvik
Posted: Wed Jan 05, 2011 7:35 am
Post subject:
There was an issue related to the rewind that caused some tearing. We fixed that issue, and replaced the old download zip with a new one (same link) you could try that one and see if it works better.
LoC
Posted: Tue Jan 04, 2011 7:30 pm
Post subject:
clockwise wrote:
just to report,
seems as flip/double-buffering (sync on MSX refresh) is broken...you get lots of tearing compare to v2.82
I can confirm the same on the screentearing versus v2.82
P.S. The rewind feature is very cool btw
clockwise
Posted: Sat Jan 01, 2011 8:43 pm
Post subject:
just to report,
seems as flip/double-buffering (sync on MSX refresh) is broken...you get lots of tearing compare to v2.82
mars2000you
Posted: Sat Dec 25, 2010 3:05 pm
Post subject: blueMSX 2.8.3 beta
2010 was a very difficult year for the blueMSX team, this for personal reasons.
We have however made some additions and improvements, but all is not ready for an official release. As these additions and improvements can interest some people, we have decided to release a beta version for Christmas !
Remember : it’s a beta version, only the core of the emulator is updated and some bugs could appear.
Important : if you get audio problems with this beta, please deselect the option "Enable reverse playback" in the Options/General menu before booting a machine
What’s new ?
- added support for smooth rewind of emulation (check hotkey in shortcut editor)
- added support for ColecoVision Super Action Controller
- added support for ColecoVision Super Expansion Module hardware
- added support for ColecoVision Expansion Module #2 using mouse
- added support for Parallax ARC cartridge
- added support for stereo PSG in MSX machine configuration
- fixed critical bug that caused trainer and cheats to fail as well as memory writes in the debugger when any of the following languages were selected : Catalan – Chinese Simplified - Chinese Traditional – Dutch – Finnish - Russian
- fixed bug in handling of transparent sprites
- fixed ARTRAGs VDP command engine bug
- fixed ‘no frequency’ bug in SN76489 emulation
- fixed minor bug in Beer IDE emulation
You can find this beta here :
http://www.bluemsx.com/rel_download/blueMSX_2.8.3_beta.zip
Powered by
phpBB
© 2001, 2005 phpBB Group