Menu
▾
▴
openmsx-bugs — Bug mails
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(24) |
Jul
|
Aug
(6) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(16) |
Feb
(5) |
Mar
|
Apr
(4) |
May
(10) |
Jun
(9) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
(13) |
Dec
(15) |
| 2004 |
Jan
(23) |
Feb
(22) |
Mar
(24) |
Apr
(18) |
May
(17) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(22) |
Oct
(22) |
Nov
(7) |
Dec
(15) |
| 2005 |
Jan
(10) |
Feb
(5) |
Mar
(19) |
Apr
(14) |
May
(17) |
Jun
(8) |
Jul
(13) |
Aug
(1) |
Sep
(22) |
Oct
(12) |
Nov
(9) |
Dec
(16) |
| 2006 |
Jan
(10) |
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
(2) |
Jul
(10) |
Aug
(11) |
Sep
(29) |
Oct
(1) |
Nov
(11) |
Dec
(13) |
| 2007 |
Jan
(17) |
Feb
(14) |
Mar
(4) |
Apr
(5) |
May
(9) |
Jun
(3) |
Jul
(8) |
Aug
(9) |
Sep
(5) |
Oct
(5) |
Nov
(5) |
Dec
(17) |
| 2008 |
Jan
(7) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
(2) |
Nov
(5) |
Dec
|
| 2009 |
Jan
(36) |
Feb
(21) |
Mar
(62) |
Apr
(13) |
May
(15) |
Jun
(36) |
Jul
(8) |
Aug
(22) |
Sep
(2) |
Oct
(13) |
Nov
(15) |
Dec
(7) |
| 2010 |
Jan
(30) |
Feb
(60) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(12) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
|
Nov
(9) |
Dec
(9) |
| 2011 |
Jan
(2) |
Feb
(3) |
Mar
(9) |
Apr
|
May
(5) |
Jun
(21) |
Jul
(15) |
Aug
(14) |
Sep
(9) |
Oct
(6) |
Nov
(3) |
Dec
(2) |
| 2012 |
Jan
(14) |
Feb
(1) |
Mar
(7) |
Apr
(7) |
May
(14) |
Jun
(2) |
Jul
(9) |
Aug
(8) |
Sep
(12) |
Oct
(2) |
Nov
(1) |
Dec
(27) |
| 2013 |
Jan
(4) |
Feb
(19) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2013-04-03 14:59:12
|
Bugs item #3609901, was opened at 2013-04-03 07:08 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609901&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Graphics Group: None Status: Open Resolution: None >Priority: 4 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Nobody/Anonymous (nobody) Summary: Screen not/wrongly updated while doing reverse_frame Initial Comment: I start up openMSX - set renderer SDL - set scale_factor 2 - set scanline 0 - set blur 0 - set glow 0 I reverse to where the MSX logo is showing up and press pause. I type: reverse_frame Now the logo disappears and the whole MSX screen becomes blue (background color). Even worse: I press F10 to remove the console. Console is still showing, but in lower brightness... Unpausing makes drawing work again. When doing advance_frame after reverse_frame, I first get a black screen. Doing another advance_frame I see the screen drawn again. More advance_frame commands after this work as expected. When I wait until the full MSX logo is drawn and then do reverse_frame, the screen doesn't become blue, but still shows the MSX logo. It keeps showing it, no matter how often I do reverse_frame from that situation... Very weird. For TASers, a working advance/reverse_frame function is essential. On SDLGL-PP I get only black screens when doing reverse_frame and there the console does disappear when pressing F10. I get the same behaviour on openMSX 0.9.1. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-04-03 07:59 Message: It only seems to happen when a GFX9000 is inserted... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609901&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-04-03 14:08:37
|
Bugs item #3609901, was opened at 2013-04-03 07:08 Message generated for change (Tracker Item Submitted) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609901&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Graphics Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Nobody/Anonymous (nobody) Summary: Screen not/wrongly updated while doing reverse_frame Initial Comment: I start up openMSX - set renderer SDL - set scale_factor 2 - set scanline 0 - set blur 0 - set glow 0 I reverse to where the MSX logo is showing up and press pause. I type: reverse_frame Now the logo disappears and the whole MSX screen becomes blue (background color). Even worse: I press F10 to remove the console. Console is still showing, but in lower brightness... Unpausing makes drawing work again. When doing advance_frame after reverse_frame, I first get a black screen. Doing another advance_frame I see the screen drawn again. More advance_frame commands after this work as expected. When I wait until the full MSX logo is drawn and then do reverse_frame, the screen doesn't become blue, but still shows the MSX logo. It keeps showing it, no matter how often I do reverse_frame from that situation... Very weird. For TASers, a working advance/reverse_frame function is essential. On SDLGL-PP I get only black screens when doing reverse_frame and there the console does disappear when pressing F10. I get the same behaviour on openMSX 0.9.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609901&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-04-03 13:51:59
|
Bugs item #3609900, was opened at 2013-04-03 06:51 Message generated for change (Tracker Item Submitted) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609900&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Wouter Vermaelen (m9710797) Summary: In pause, key events are sent to the MSX Initial Comment: In pause key events are sent to the MSX, which means that while replaying with the reverse feature it will switch to record mode. Scenario is: replay mode, pause press and _release_ keys unpause This happens for instance when you accidentally type a key in the openMSX window while it's being paused. I was thinking that the correct behaviour would be to stop sending keys to the MSX in pause, but when unpausing, resync the key status with the MSX (in case you want to press a key and already did that in pause and then unpause to have it effective immediately). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609900&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-04-03 13:48:36
|
Bugs item #3609899, was opened at 2013-04-03 06:48 Message generated for change (Tracker Item Submitted) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609899&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Nobody/Anonymous (nobody) Summary: Delta Soft Tool Disc crashes in openMSX in bootsector Initial Comment: Attached disk image works fine on real machine (tested with nowind on GT), but crashes on emulated machine in openMSX (either di; halt (MSX2), or other hangup (turboR)). So far Wouter found out: - if i copy the files to another disk (with original bootsector) it seems to work - bootsector loads msxdos.sys at address 0x100 and then jumps to 0x100 .. but the program loaded at 0x100 does not correspond to the content of the msxdos.sys file ... no idea yet why not ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3609899&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-04-03 13:29:00
|
Bugs item #3603872, was opened at 2013-02-08 12:53 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603872&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) >Assigned to: Wouter Vermaelen (m9710797) Summary: OSDcontrol key repeat not working on Android Initial Comment: Key repeat works on PC now, but for some reason, not on Android when controlling with the virtual D-pad. This makes browsing long lists (e.g. when you have many ROMs in the ROM list in the Load ROM menu) very cumbersome. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-04-03 06:28 Message: Fixed by Wouter in revision 13195. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603872&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-03-12 22:17:04
|
Bugs item #3607823, was opened at 2013-03-12 15:17 Message generated for change (Tracker Item Submitted) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3607823&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Nobody/Anonymous (nobody) Summary: Maximum baud rate is 3720 baud? Not expected. Initial Comment: The MSX tools Speedsave 4000 and Turbo 5000 claim you can save at a maximum of 4600 baud to cassette and then load it with normal basic commands. However, when I change cas2wav conversion factor in CasImage.cc to values higher than 3720 baud, the MSX cannot load the CAS based software anymore. Tried on several MSX machines... (Note that in 2005, this maximum was even lower, 2760 baud... so something happened in the mean time that made this figure better, but it's not OK yet... Is this some kind of timing?) Perhaps bug 1235168 is related... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3607823&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-03-12 21:55:15
|
Bugs item #1235168, was opened at 2005-07-09 05:01 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=1235168&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Wouter Vermaelen (m9710797) Summary: microWAVer (and CD Sequential) WAV files won't work Initial Comment: They do work on a real MSX. One example is attached. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-03-12 14:55 Message: Hmm, now the test signal is approved again... no idea why though. Same happens as the original comment of 2005-09-28. MicroWAVer still doesn't work, still gives some error (after loading the loader, you have to disable motorcontrol and then it says: Loading:{some gibberish} <Err> ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2009-06-10 13:22 Message: When testing CD Sequential now, the test signal is not approved (almost, but not enough). And there's not much one can do to 'adjust the signal', as the program advises.... Also, the attached MicroWAVer sample hangs up almost immediately after loading. ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2005-09-28 00:12 Message: Logged In: YES user_id=78178 CD Sequential files aren't working either. The loader works and is satisfied with the test signal. However, when loading an actual game, you always get "Checksum Error". This is most likely caused by the same bug as for MicroWAVer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=1235168&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-03-01 22:30:32
|
Bugs item #3603184, was opened at 2013-02-03 07:20 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603184&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Sound Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) >Assigned to: Wouter Vermaelen (m9710797) Summary: Changing to rhythm mode disables channels on Okazaki core Initial Comment: Run attached program on a turboR in R800 mode (timing is tuned for R800 mode). On openMSX it sounds chopped off, on real MSX you hear a very long release. It's like the channels are turned off when the rhythm bit is enabled, in openMSX, which is apparently wrong. On the alternative FM core, it sounds better. When removing line 91, you can even hear the drums on the real MSX, not in openMSX. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-03-01 14:30 Message: Fixed by Wouter in revision 13175. Confirmed to be fixed by Edwin, one of the original reporters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603184&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-20 20:26:11
|
Bugs item #3592046, was opened at 2012-12-03 01:55 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3592046&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Sound Group: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Alex Wulms (awulms) Summary: Android: SDL audio buffer size Initial Comment: On all devices we tried so far, the SDL setting 'audio buffer size' had to be changed from "very small" to "small" to not get choppy sound. Can this be made default, so that people have good sound right away? ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-20 12:26 Message: Fixed by awulms in 13111. ---------------------------------------------------------------------- Comment By: Alex Wulms (awulms) Date: 2012-12-15 06:41 Message: Question asked on the SDL Android port support forum (http://www.anddev.org/code-snippets-for-android-f33/sdl-port-for-android-sdk-ndk-1-6-t9218-840.html#p2228174) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3592046&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-18 13:16:38
|
Bugs item #3604044, was opened at 2013-02-10 13:44 Message generated for change (Comment added) made by m9710797 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3604044&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Sound Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Filip H.F. "FiXato" Slagter (fixato) Assigned to: Nobody/Anonymous (nobody) Summary: hq resampler + sse causes audio distortions Initial Comment: Start openMSX with audio/music extension and set resampler to hq. Load a game with MSX audio or music (Pixiedust for instance) support and enjoy the buzzing sound. Starting openMSX with -nosse solves the issue. The problem also is not present with blip resampler. <wouter___> iirc it was a bug in the windows specific asm code ---------------------------------------------------------------------- >Comment By: Wouter Vermaelen (m9710797) Date: 2013-02-18 05:16 Message: Fixed in revision 13172 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3604044&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-10 21:44:11
|
Bugs item #3604044, was opened at 2013-02-10 13:44 Message generated for change (Tracker Item Submitted) made by fixato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3604044&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Sound Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Filip H.F. "FiXato" Slagter (fixato) Assigned to: Nobody/Anonymous (nobody) Summary: hq resampler + sse causes audio distortions Initial Comment: Start openMSX with audio/music extension and set resampler to hq. Load a game with MSX audio or music (Pixiedust for instance) support and enjoy the buzzing sound. Starting openMSX with -nosse solves the issue. The problem also is not present with blip resampler. <wouter___> iirc it was a bug in the windows specific asm code ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3604044&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:37:19
|
Bugs item #1601355, was opened at 2006-11-22 11:26 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=1601355&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Nobody/Anonymous (nobody) Summary: Quattro crashes with MSX-AUDIO inserted Initial Comment: The game Quattro (can be downloaded from MRC), crashes with: File not open in 309 when it is started with any MSX-AUDIO inserted. It works normally on a real MSX, I verified. It crashes right after the title screen is displayed, after the system check. Using the same emulated MSX but without an MSX-AUDIO makes the game run just fine. It also crashes in a similar way on blueMSX, but there it says: Bad file mode in 321 according to John van Poelgeest on MRC: http://www.msx.org/forumtopicl6756.html ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:37 Message: I don't know what happened, but I just tested this again and it works fine now! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=1601355&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:29:40
|
Bugs item #2775281, was opened at 2009-04-19 18:16 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2775281&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Debugger Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger don't fit properly on 1024x768 Initial Comment: Currently the debugger don't fit properly at the 1024x768 resolution. The scrollbars get weird, its lower scroll button disappears and the slider get out of center. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:29 Message: Closing, we won't fix this. (And no reaction from submitter on edwin's suggestion.) ---------------------------------------------------------------------- Comment By: Edwin (edwinv) Date: 2012-05-27 07:41 Message: You can choose different fonts and rearrange the viewers to make it usable. Unless there is wrong that prevents that at low resolutions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2775281&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:28:16
|
Bugs item #2776825, was opened at 2009-04-20 14:59 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2776825&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: Dir-as-disk data corruption Initial Comment: The dir-as-disk feature seems to corrupt the data sometimes, when the directory contains more than 720KB of data. Steps to reproduce the problem: 1) Put both the MSX-DOS1 and MSX-DOS2 files (MSX-DOS?.SYS and COMMAND?.COM) 2) Add some files to the same dir, making it pass the 720KB limit 3) Boot a MSX Turbo-R. It will boot the MSX-DOS2 4) Modify some file 5) Shut down the MSX Turbo-R 6) Boot a Panasonic FS-A1WSX. It will boot the MSX-DOS1 7) The MSX-DOS1 is probably corrupted. It freezes after the "MSX-DOS version 1.0" message. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:28 Message: No reply from submitter, and I can't reproduce the issue.... so this can be closed... (we can't do anything about it). ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2012-12-22 13:13 Message: Dir-As-Disk has been refactored now. Can you still reproduce this? ---------------------------------------------------------------------- Comment By: Patrick van Arkel (vampier) Date: 2009-08-11 22:01 Message: While working on GraCo I had random crashes on openMSX when working with Dir-As-Disk. Switching to a .DSK image worked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2776825&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:10:53
|
Bugs item #2937991, was opened at 2010-01-23 07:33 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2937991&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: Interference between the MENU and PAUSE shortcuts Initial Comment: There's some strange interference between the MENU and PAUSE shortcuts. Steps to reproduce: 1) Boot the MSX 2) Press the shortcut to open the internal openMSX MENU (cmd+O on a Mac) 3) Press the shortcut to pause the emulation (cmd+P on a Mac). The PAUSE icon will show up as desired. 4) When you press again the MENU shortcut, the PAUSE icon will be gone and the emulation will continue as it was never paused. 5) Now every time you open the MENU, the PAUSE icon will show up again, but the emulation will be paused only while the MENU is open Testbed information: - openMSX-0.7.2-dev11023 on Mac OS-X v10.5.8 ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:10 Message: The menu pauses emulation for convenience (usually you do not need/want it to continue). The user is free to override that. But indeed, the menu is also overriding the pause state that the user desired. This has been a choice. Not sure what to do here.... should this behaviour be changed? I haven't heard other complaints. Are there serious use cases that are broken because of this behaviour? ---------------------------------------------------------------------- Comment By: FRS (sd-snatcher) Date: 2010-01-25 17:14 Message: > Should we restore the pause state at menu exit? Is that what this is about? I think so, as on the Mac I usually trip cmd+O while pressing the cmd+P and then it unpauses it without my request because I closed the menu. What is very weird is the fact that if you press cmd+P while the menu is on, the emulation continues normally. So, why do the MENU really needs to pause the emulation? Opening the console doesn't behave this way.. Shouldn't the MENU work the same way for interface consistence? ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2010-01-25 12:05 Message: I'm not sure what the problem is. When opening and closing the menu, openMSX is also automatically paused and unpaused. We do want to pause the emulation when opening the menu. Should we restore the pause state at menu exit? Is that what this is about? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=2937991&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:07:11
|
Bugs item #3031308, was opened at 2010-07-18 11:36 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3031308&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Graphics Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect colors alternative MSX1 VDP chips Initial Comment: The many MSX1 VDP models/clones had different palettes. I remember the first time I saw an Gradiente Expert DD-Plus when it was launched: The 1st thing I clearly noticed was that machine had a very different set of colors than the previous models. The reason became clear after some months: The "Plus" experts had the Toshiba's T7937A MSX-Engine (which has a Toshiba VDP inside). Currently, openMSX shows only the TMS9918 colors for all MSX1 models, which result on incorrect colors for those machines that had the other VDP types, like the Expert *Plus and Toshiba HX-10. Bifi's Pallete editor is able to demonstrate the differences of each palette and how much they affect the image perception, as some are darker, others more washed, and others have more saturated colors: http://bifi.msxnet.org/paledit/?t=2&d=shalom http://bifi.msxnet.org/paledit/?t=2&d=gradius2 http://bifi.msxnet.org/paledit/?t=2&d=golvellius http://bifi.msxnet.org/paledit/?t=2&d=arkanoid http://bifi.msxnet.org/paledit/?t=2&d=palette ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:07 Message: In revision 13003 an improvement was implemented: Improve TMS99X8/TMS9929 color palette This change was based on hit9918's request in this forum thread: http://www.msx.org/forum/msx-talk/openmsx/minor-openmsx-other-emulators-vd (see hit9918's post of 28-11-2012, 21:30 and later). If someone has reliable exact specs for the Toshiba VDP, that palette could also be implemented. ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2010-07-18 11:54 Message: See also bug 2552579, there are more differences with this VDP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3031308&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:03:44
|
Bugs item #3312847, was opened at 2011-06-06 18:36 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3312847&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Catapult Group: Next release >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: joxy (joxy) Assigned to: Nobody/Anonymous (nobody) Summary: crash after hardware scan window (no main window shown) Initial Comment: a stack trace attached OS: Ubuntu 10.04.* $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 10.04 LTS Release: 10.04 Codename: lucid $ uname -a Linux hostname1 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux $ $ openmsx-catapult --version openMSX Catapult 0.7.2 $ ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:03 Message: No reply from reporter and no other reports received... so,I think we can close this bug, we can't do something about it now. ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2011-07-16 03:59 Message: Can you still reproduce this issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3312847&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 21:01:57
|
Bugs item #3574930, was opened at 2012-10-05 16:48 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3574930&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: FRS (sd-snatcher) Assigned to: Nobody/Anonymous (nobody) Summary: openMSX is flooding the terminal with HDD checksum messages Initial Comment: openMSX-0.9.1 is flooding the terminal with 101 messages about the checksum progress. This causes the terminal to scroll too much, requiring the programmer to scroll back to see if there were any other important messages on his script. Example output: progress: Calculating SHA1 sum for msxhddtest.dmg... 0% progress: Calculating SHA1 sum for msxhddtest.dmg... 1% progress: Calculating SHA1 sum for msxhddtest.dmg... 2% progress: Calculating SHA1 sum for msxhddtest.dmg... 3% progress: Calculating SHA1 sum for msxhddtest.dmg... 4% progress: Calculating SHA1 sum for msxhddtest.dmg... 5% progress: Calculating SHA1 sum for msxhddtest.dmg... 6% progress: Calculating SHA1 sum for msxhddtest.dmg... 7% progress: Calculating SHA1 sum for msxhddtest.dmg... 8% progress: Calculating SHA1 sum for msxhddtest.dmg... 9% progress: Calculating SHA1 sum for msxhddtest.dmg... 10% progress: Calculating SHA1 sum for msxhddtest.dmg... 11% progress: Calculating SHA1 sum for msxhddtest.dmg... 12% progress: Calculating SHA1 sum for msxhddtest.dmg... 13% progress: Calculating SHA1 sum for msxhddtest.dmg... 14% progress: Calculating SHA1 sum for msxhddtest.dmg... 15% progress: Calculating SHA1 sum for msxhddtest.dmg... 16% progress: Calculating SHA1 sum for msxhddtest.dmg... 17% progress: Calculating SHA1 sum for msxhddtest.dmg... 18% progress: Calculating SHA1 sum for msxhddtest.dmg... 19% progress: Calculating SHA1 sum for msxhddtest.dmg... 20% progress: Calculating SHA1 sum for msxhddtest.dmg... 21% progress: Calculating SHA1 sum for msxhddtest.dmg... 22% progress: Calculating SHA1 sum for msxhddtest.dmg... 23% progress: Calculating SHA1 sum for msxhddtest.dmg... 24% progress: Calculating SHA1 sum for msxhddtest.dmg... 25% progress: Calculating SHA1 sum for msxhddtest.dmg... 26% progress: Calculating SHA1 sum for msxhddtest.dmg... 27% progress: Calculating SHA1 sum for msxhddtest.dmg... 28% progress: Calculating SHA1 sum for msxhddtest.dmg... 29% progress: Calculating SHA1 sum for msxhddtest.dmg... 30% progress: Calculating SHA1 sum for msxhddtest.dmg... 31% progress: Calculating SHA1 sum for msxhddtest.dmg... 32% progress: Calculating SHA1 sum for msxhddtest.dmg... 33% progress: Calculating SHA1 sum for msxhddtest.dmg... 34% progress: Calculating SHA1 sum for msxhddtest.dmg... 35% progress: Calculating SHA1 sum for msxhddtest.dmg... 36% progress: Calculating SHA1 sum for msxhddtest.dmg... 37% progress: Calculating SHA1 sum for msxhddtest.dmg... 38% progress: Calculating SHA1 sum for msxhddtest.dmg... 39% progress: Calculating SHA1 sum for msxhddtest.dmg... 40% progress: Calculating SHA1 sum for msxhddtest.dmg... 41% progress: Calculating SHA1 sum for msxhddtest.dmg... 42% progress: Calculating SHA1 sum for msxhddtest.dmg... 43% progress: Calculating SHA1 sum for msxhddtest.dmg... 44% progress: Calculating SHA1 sum for msxhddtest.dmg... 45% progress: Calculating SHA1 sum for msxhddtest.dmg... 46% progress: Calculating SHA1 sum for msxhddtest.dmg... 47% progress: Calculating SHA1 sum for msxhddtest.dmg... 48% progress: Calculating SHA1 sum for msxhddtest.dmg... 49% progress: Calculating SHA1 sum for msxhddtest.dmg... 50% progress: Calculating SHA1 sum for msxhddtest.dmg... 51% progress: Calculating SHA1 sum for msxhddtest.dmg... 52% progress: Calculating SHA1 sum for msxhddtest.dmg... 53% progress: Calculating SHA1 sum for msxhddtest.dmg... 54% progress: Calculating SHA1 sum for msxhddtest.dmg... 55% progress: Calculating SHA1 sum for msxhddtest.dmg... 56% progress: Calculating SHA1 sum for msxhddtest.dmg... 57% progress: Calculating SHA1 sum for msxhddtest.dmg... 58% progress: Calculating SHA1 sum for msxhddtest.dmg... 59% progress: Calculating SHA1 sum for msxhddtest.dmg... 60% progress: Calculating SHA1 sum for msxhddtest.dmg... 61% progress: Calculating SHA1 sum for msxhddtest.dmg... 62% progress: Calculating SHA1 sum for msxhddtest.dmg... 63% progress: Calculating SHA1 sum for msxhddtest.dmg... 64% progress: Calculating SHA1 sum for msxhddtest.dmg... 65% progress: Calculating SHA1 sum for msxhddtest.dmg... 66% progress: Calculating SHA1 sum for msxhddtest.dmg... 67% progress: Calculating SHA1 sum for msxhddtest.dmg... 68% progress: Calculating SHA1 sum for msxhddtest.dmg... 69% progress: Calculating SHA1 sum for msxhddtest.dmg... 70% progress: Calculating SHA1 sum for msxhddtest.dmg... 71% progress: Calculating SHA1 sum for msxhddtest.dmg... 72% progress: Calculating SHA1 sum for msxhddtest.dmg... 73% progress: Calculating SHA1 sum for msxhddtest.dmg... 74% progress: Calculating SHA1 sum for msxhddtest.dmg... 75% progress: Calculating SHA1 sum for msxhddtest.dmg... 76% progress: Calculating SHA1 sum for msxhddtest.dmg... 77% progress: Calculating SHA1 sum for msxhddtest.dmg... 78% progress: Calculating SHA1 sum for msxhddtest.dmg... 79% progress: Calculating SHA1 sum for msxhddtest.dmg... 80% progress: Calculating SHA1 sum for msxhddtest.dmg... 81% progress: Calculating SHA1 sum for msxhddtest.dmg... 82% progress: Calculating SHA1 sum for msxhddtest.dmg... 83% progress: Calculating SHA1 sum for msxhddtest.dmg... 84% progress: Calculating SHA1 sum for msxhddtest.dmg... 85% progress: Calculating SHA1 sum for msxhddtest.dmg... 86% progress: Calculating SHA1 sum for msxhddtest.dmg... 87% progress: Calculating SHA1 sum for msxhddtest.dmg... 88% progress: Calculating SHA1 sum for msxhddtest.dmg... 89% progress: Calculating SHA1 sum for msxhddtest.dmg... 90% progress: Calculating SHA1 sum for msxhddtest.dmg... 91% progress: Calculating SHA1 sum for msxhddtest.dmg... 92% progress: Calculating SHA1 sum for msxhddtest.dmg... 93% progress: Calculating SHA1 sum for msxhddtest.dmg... 94% progress: Calculating SHA1 sum for msxhddtest.dmg... 95% progress: Calculating SHA1 sum for msxhddtest.dmg... 96% progress: Calculating SHA1 sum for msxhddtest.dmg... 97% progress: Calculating SHA1 sum for msxhddtest.dmg... 98% progress: Calculating SHA1 sum for msxhddtest.dmg... 99% progress: Calculating SHA1 sum for msxhddtest.dmg... 100% ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 13:01 Message: We actually added these progress messages on purpose, because it can take a long time before the SHA1 sum is calculated for larger images. Due to the nature of the messaging system, these also show up on the console (next to the OSD). I propose not to fix this. The terminal is usually not used for something you really need. I'm curious about other people's opinion. ---------------------------------------------------------------------- Comment By: FRS (sd-snatcher) Date: 2012-10-05 16:50 Message: Note: The problem happens on the unix terminal, not on openMSX console. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3574930&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 20:53:36
|
Bugs item #3603872, was opened at 2013-02-08 12:53 Message generated for change (Tracker Item Submitted) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603872&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) Assigned to: Alex Wulms (awulms) Summary: OSDcontrol key repeat not working on Android Initial Comment: Key repeat works on PC now, but for some reason, not on Android when controlling with the virtual D-pad. This makes browsing long lists (e.g. when you have many ROMs in the ROM list in the Load ROM menu) very cumbersome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603872&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 20:50:52
|
Bugs item #3601023, was opened at 2013-01-15 12:35 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3601023&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Manuel Bilderbeek (manuelbi) >Assigned to: Wouter Vermaelen (m9710797) Summary: ARM: crash when reg18 is written Initial Comment: jan 07 2013 21:24:26 <awulms> its in BitmapConverter function jan 07 2013 21:25:34 <wouter__> some misaligned read error? jan 07 2013 21:26:50 <awulms> yes, its in some asm code jan 07 2013 21:27:10 <awulms> Its line 156 of src/video/BitmapConverter.cc jan 07 2013 21:27:33 <awulms> which is the close statement for some arm asm block jan 07 2013 21:28:59 <wouter__> both vramPtr0 and pixelPtr must be 4-byte aligned for this asm function jan 07 2013 21:54:38 <wouter__> mips and arm are two cpu architectures (like x86 is another one) .... so indeed the asm code is not used on mips, but even the c++ code contains misaslined accesses jan 07 2013 21:55:06 <awulms> the C++ compiler will probably handle it when generating the asm code jan 07 2013 21:55:40 <wouter__> no, we explicitly cast a pointer to 16-bit data to a ptr to 32-bit data jan 07 2013 21:55:42 <awulms> by generating aligned instructions like 'do an aligned read, update correct bits in the register, do an aligned write' jan 07 2013 21:56:23 <wouter__> when dereferencing a 32-bit pointer, the compiler will not add extra code for the case it might be misaligned jan 07 2013 21:56:29 <awulms> maybe the C-compiler is smart enough to see through it jan 07 2013 21:57:24 <wouter__> 'normally' the c++ compiler doesn't allow to do such unsafe ptr conversions, but we used a 'reinterpret_cast'. So basically telling the compiler "trust me i know what i'm doing" jan 07 2013 21:57:42 <wouter__> (but apparently i didn't really know ;-) jan 07 2013 21:58:17 <Vampier> hahaha jan 07 2013 21:58:23 <awulms> assertion "(reinterpret_cast<long>(pixelPtr) & 3) == 0" failed jan 07 2013 22:00:44 <wouter__> the c++ is code is wrong .. even if it happens to work on this combination of cpu/compiler/platform (which i don't think it will), it may still go wrong on a slightly different combination jan 07 2013 22:05:46 <wouter__> ah .. i see what's going on ... starting from ARMv6, the ARM architecture CAN perform misaligned load/stores, but only single word load/stores ... the asm version uses the 'stm' instruction (store-multiple) jan 07 2013 22:07:12 <wouter__> so the c++ is technically still wrong, but it happens to work on x86 and on armv6 with this version of gcc (when gcc optimizes harder and uses stm instructioms, it will also crash) ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 12:50 Message: Fixed in revision 13139 by Wouter. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3601023&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 20:49:50
|
Bugs item #3601025, was opened at 2013-01-15 12:39 Message generated for change (Settings changed) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3601025&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Manuel Bilderbeek (manuelbi) >Assigned to: Wouter Vermaelen (m9710797) Summary: OSDcontrol refactoring breaks key repeat Initial Comment: Key repeat in the OSD menu is broken. Regression compared to 0.9.1. ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-08 12:49 Message: Wouter fixed repeat in revision 13156. Thanks! I'll make a new report on key repeat not working on the Android version (at least on my phone). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3601025&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-07 21:26:06
|
Bugs item #3603207, was opened at 2013-02-03 13:31 Message generated for change (Comment added) made by vampier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: Next release >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Patrick van Arkel (vampier) Assigned to: Nobody/Anonymous (nobody) Summary: tab completion bug Initial Comment: Since a movie tells more than I can summarize; http://www.youtube.com/watch?v=RYftCyH4ycw ---------------------------------------------------------------------- >Comment By: Patrick van Arkel (vampier) Date: 2013-02-07 13:26 Message: fixed. thanks Wouter ---------------------------------------------------------------------- Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-04 02:55 Message: 13075 is the revision where this started, according to Patrick's bisecting which was still in my IRC log. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-04 10:55:57
|
Bugs item #3603207, was opened at 2013-02-03 13:31 Message generated for change (Comment added) made by manuelbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: Next release Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick van Arkel (vampier) Assigned to: Nobody/Anonymous (nobody) Summary: tab completion bug Initial Comment: Since a movie tells more than I can summarize; http://www.youtube.com/watch?v=RYftCyH4ycw ---------------------------------------------------------------------- >Comment By: Manuel Bilderbeek (manuelbi) Date: 2013-02-04 02:55 Message: 13075 is the revision where this started, according to Patrick's bisecting which was still in my IRC log. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-03 21:36:08
|
Bugs item #3603208, was opened at 2013-02-03 13:36 Message generated for change (Tracker Item Submitted) made by vampier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603208&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Graphics Group: Next release Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick van Arkel (vampier) Assigned to: Nobody/Anonymous (nobody) Summary: 3x SaI crash on windows Initial Comment: tested on revision 13148 (current when I type this) This crash occurs when I switch to 3x SaI on the SDL/SDLGL-FB16 and SDLGL-FB32 renderer. SDL-PP works fine. Stack trace: ntdll.dll!000007fecbfea27b() Unknown ntdll.dll!000007fecbfef0d4() Unknown ntdll.dll!000007fecc00bd8a() Unknown AcLayers.dll!000007fea4a49391() Unknown > openmsx.exe!free(void * pBlock) Line 51 C openmsx.exe!_aligned_free(void * memblock) Line 473 C openmsx.exe!openmsx::StretchScalerOutputBase<unsigned int>::~StretchScalerOutputBase<unsigned int>() Line 115 C++ openmsx.exe!openmsx::StretchScalerOutput<unsigned int>::`scalar deleting destructor'(unsigned int) C++ openmsx.exe!openmsx::FBPostProcessor<unsigned int>::paint(openmsx::OutputSurface & output) Line 387 C++ openmsx.exe!openmsx::Display::repaint(openmsx::OutputSurface & surface) Line 410 C++ openmsx.exe!openmsx::Display::repaint() Line 396 C++ openmsx.exe!openmsx::Display::signalEvent(const std::shared_ptr<openmsx::Event const > & event) Line 247 C++ openmsx.exe!openmsx::EventDistributor::deliverEvents() Line 114 C++ openmsx.exe!openmsx::Reactor::run(openmsx::CommandLineParser & parser) Line 580 C++ openmsx.exe!openmsx::SDL_main(int argc, char * * argv) Line 159 C++ openmsx.exe!main(int argc, char * * argv) Line 315 C openmsx.exe!__tmainCRTStartup() Line 241 C kernel32.dll!000007fecb79167e() Unknown ntdll.dll!000007fecbf1c3f1() Unknown free.c is a VS2012 component: *void free(pblock) - free a block in the heap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603208&group_id=38274 |
|
From: SourceForge.net <no...@so...> - 2013-02-03 21:31:35
|
Bugs item #3603207, was opened at 2013-02-03 13:31 Message generated for change (Tracker Item Submitted) made by vampier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General/misc Group: Next release Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick van Arkel (vampier) Assigned to: Nobody/Anonymous (nobody) Summary: tab completion bug Initial Comment: Since a movie tells more than I can summarize; http://www.youtube.com/watch?v=RYftCyH4ycw ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3603207&group_id=38274 |
1 message has been excluded from this view by a project administrator.
