From: Vincent R. <vin...@fr...> - 2012-05-19 16:14:36
|
New snapshot: EmuTOS CVS-20120519 http://sourceforge.net/projects/emutos/files/snapshots/CVS-20120519/ - Fixed tos-lang-change regression - Faster mul_div() implementation - Updated French translation Except the missing translations, documentation, and cartridge image, it is supposed to be ready for the 0.8.7 release. -- Vincent Rivière |
From: Vincent R. <vin...@fr...> - 2012-05-28 09:27:32
|
New snapshot: EmuTOS CVS-20120528 http://sourceforge.net/projects/emutos/files/snapshots/CVS-20120528/ - Fixed Bconout() return value - Fixed Fwrite() for AUX: or PRN: - Updated Finnish, Spanish, Italian and Russian translations - Fixed compilation with older GCC - New emutos-cartridge binary archive Some minor features are still missing for 0.8.7: - mkrom (for Steem cartridge image) - Czech translation - Greek translation - size of the buttons in resolution change dialog box - documentation - debug symbols (maybe) Anyway, the main code is finished. Those binaries are expected to have no regression from 0.8.6 and no major bug in new features. -- Vincent Rivière |
From: Eero T. <oa...@he...> - 2012-05-28 22:14:17
Attachments:
diskinfo.png
vdi2.png
|
Hi, On maanantai 28 toukokuu 2012, Vincent Rivière wrote: > New snapshot: EmuTOS CVS-20120528 > http://sourceforge.net/projects/emutos/files/snapshots/CVS-20120528/ > > - Fixed Bconout() return value Verified. > - Fixed Fwrite() for AUX: or PRN: > - Updated Finnish, Spanish, Italian and Russian translations Everything else looks fine, but the text alignment in disk info dialog is screwed up, see attachment. Maybe something could be done for aligning translated text in dialogs like this after EmuTOS is released? Btw. I found a small new issue. There's some issue with with EmuTOS 2-plane / 4 color mode support. While normal med-rez looks fine, Hatari VDI mode with 4 colors looks like in the attached picture when using EmuTOS. In normal TOS case, fonts and menus are OK. (But the black color has changed to yellow.) > - Fixed compilation with older GCC > - New emutos-cartridge binary archive > > Some minor features are still missing for 0.8.7: > - mkrom (for Steem cartridge image) > - Czech translation > - Greek translation > - size of the buttons in resolution change dialog box > - documentation > - debug symbols (maybe) > > Anyway, the main code is finished. > Those binaries are expected to have no regression from 0.8.6 and no major > bug in new features. - Eero |
From: Vincent R. <vin...@fr...> - 2012-05-28 22:55:55
|
On 29/05/2012 00:09, Eero Tamminen wrote: > Verified. Many thanks for your tests, Eero. > While normal med-rez looks fine, Hatari VDI mode > with 4 colors looks like in the attached picture > when using EmuTOS. Ok, I understand that real ST emulation works fine, but Hatari's Extended VDI modes have trouble. From your snapshot, it seems that Hatari uses a 2-plane video mode, while EmuTOS thinks there are 4 planes. I don't know how Hatari hacks the video mode, but the tweaked information does not seem to reach the VDI implementation. First, it should be proven that this is not a Hatari bug. Then it may be fixed for 0.8.7 (Roger?) if this is not too complicated and does not introduce regressions. -- Vincent Rivière |
From: Roger B. <rfb...@ym...> - 2012-05-29 05:00:49
|
On 29 May 2012 at 0:55, Vincent Rivière wrote: > On 29/05/2012 00:09, Eero Tamminen wrote: > > > While normal med-rez looks fine, Hatari VDI mode > > with 4 colors looks like in the attached picture > > when using EmuTOS. > > Ok, I understand that real ST emulation works fine, but Hatari's Extended > VDI modes have trouble. > > From your snapshot, it seems that Hatari uses a 2-plane video mode, while > EmuTOS thinks there are 4 planes. > > I don't know how Hatari hacks the video mode, but the tweaked information > does not seem to reach the VDI implementation. First, it should be proven > that this is not a Hatari bug. Then it may be fixed for 0.8.7 (Roger?) if > this is not too complicated and does not introduce regressions. > I'm willing to take a look at it, but I don't know anything about extended VDI modes. Can someone explain? Roger |
From: Roger B. <rfb...@ym...> - 2012-05-29 05:00:50
|
On 29 May 2012 at 1:09, Eero Tamminen wrote: > > Everything else looks fine, but the text alignment > in disk info dialog is screwed up, see attachment. > > Maybe something could be done for aligning translated > text in dialogs like this after EmuTOS is released? > There are a number of dialogs that could be cleaned up. But I wouldn't want to change things and cause problems with multiple language support. I guess as long as I don't move the format string leftwards, I'd be OK? Roger |
From: Vincent R. <vin...@fr...> - 2012-05-29 08:51:31
|
On 29/05/2012 07:00, Roger Burrows wrote: > There are a number of dialogs that could be cleaned up. But I wouldn't want to > change things and cause problems with multiple language support. I guess as > long as I don't move the format string leftwards, I'd be OK? That dialog has been ugly for ages, this is not a priority. If the change is easy and does not cause any regression in any language, why not fixing it for 0.8.7. Also, it would be nice to use the YYYY date format in that dialog, I looked at the implementation and it is not simple. So I believe it would be better to delay any improvement of that dialog after the release. -- Vincent Rivière |
From: Eero T. <oa...@he...> - 2012-05-29 19:11:37
|
Hi, On tiistai 29 toukokuu 2012, Roger Burrows wrote: > On 29 May 2012 at 1:09, Eero Tamminen wrote: > > Everything else looks fine, but the text alignment > > in disk info dialog is screwed up, see attachment. > > > > Maybe something could be done for aligning translated > > text in dialogs like this after EmuTOS is released? > > There are a number of dialogs that could be cleaned up. But I wouldn't > want to change things and cause problems with multiple language support. > I guess as long as I don't move the format string leftwards, I'd be OK? Best would be to have some tool for which one can give old and new pot file and which then applies the similar whitespace transformation to translations. This of course requires that only changes in the pot files would be whitespace transformations. Another possibility would be to somehow in the po file tell that certain strings belong to same group, which texts should be right aligned. The tool could then right aligned all strings in this group to the size of the longest string. I think a throwaway tool like that could be done fairly quickly in Python (I could probably look into it later on). It could at the same time check the dialog stuff. :-) - Eero |
From: Thomas H. <th...@gm...> - 2012-05-29 17:39:55
|
Am Tue, 29 May 2012 01:00:14 -0400 schrieb "Roger Burrows" <rfb...@ym...>: > On 29 May 2012 at 0:55, Vincent Rivière wrote: > > > On 29/05/2012 00:09, Eero Tamminen wrote: > > > > > While normal med-rez looks fine, Hatari VDI mode > > > with 4 colors looks like in the attached picture > > > when using EmuTOS. > > > > Ok, I understand that real ST emulation works fine, but Hatari's > > Extended VDI modes have trouble. > > > > From your snapshot, it seems that Hatari uses a 2-plane video > > mode, while EmuTOS thinks there are 4 planes. > > > > I don't know how Hatari hacks the video mode, but the tweaked > > information does not seem to reach the VDI implementation. First, > > it should be proven that this is not a Hatari bug. Then it may be > > fixed for 0.8.7 (Roger?) if this is not too complicated and does > > not introduce regressions. > > > I'm willing to take a look at it, but I don't know anything about > extended VDI modes. Can someone explain? IIRC Hatari uses two "hacks" to inform TOS about an extended VDI resolution: - First, Hatari installs a ROM catridge that is executed during system boot. The cartridge uses Line-A $A000 so that Hatari can grab the pointer to the Line-A variables. It then patches the Line-A variables for the right resolution (see VDI_LineA in vdi.c): STMemory_WriteWord(linea-46, VDICharHeight); /* v_cel_ht */ STMemory_WriteWord(linea-44, (VDIWidth/8)-1); /* v_cel_mx (cols-1) */ STMemory_WriteWord(linea-42, (VDIHeight/VDICharHeight)-1); /* v_cel_my (rows-1) */ STMemory_WriteWord(linea-40, VDICharHeight*((VDIWidth*VDIPlanes)/8)); /* v_cel_wr */ STMemory_WriteWord(linea-12, VDIWidth); /* v_rez_hz */ STMemory_WriteWord(linea-4, VDIHeight); /* v_rez_vt */ STMemory_WriteWord(linea-2, (VDIWidth*VDIPlanes)/8); /* bytes_lin */ STMemory_WriteWord(linea+0, VDIPlanes); /* planes */ STMemory_WriteWord(linea+2, (VDIWidth*VDIPlanes)/8); /* width */ - Second, Hatari intercepts the VDI/AES trap and searches for VDI "open workstation" / "open virtual workstation" calls. If it detects such a call, it patches the parameters of the workstation: STMemory_WriteWord(VDIIntout, VDIWidth-1); /* IntOut[0] Width-1 */ STMemory_WriteWord(VDIIntout+1*2, VDIHeight-1); /* IntOut[1] Height-1 */ STMemory_WriteWord(VDIIntout+13*2, VDIColors); /* IntOut[13] #colors */ STMemory_WriteWord(VDIIntout+39*2, 512); /* IntOut[39] #available colors */ STMemory_WriteWord(LineABase-0x15a*2, VDIWidth-1); /* WKXRez */ STMemory_WriteWord(LineABase-0x159*2, VDIHeight-1); /* WKYRez */ This works fine with all TOS versions so far, but EmuTOS still seems to think that it works in low resolution instead. I wonder why, ... got to check $ff8260 to see whether we return low or medium resolution in this mode... Thomas |
From: Thomas H. <th...@gm...> - 2012-05-29 20:56:52
|
Am Tue, 29 May 2012 19:39:42 +0200 schrieb Thomas Huth <th...@gm...>: > Am Tue, 29 May 2012 01:00:14 -0400 > schrieb "Roger Burrows" <rfb...@ym...>: > > > On 29 May 2012 at 0:55, Vincent Rivière wrote: > > > > > On 29/05/2012 00:09, Eero Tamminen wrote: > > > > > > > While normal med-rez looks fine, Hatari VDI mode > > > > with 4 colors looks like in the attached picture > > > > when using EmuTOS. > > > > > > Ok, I understand that real ST emulation works fine, but Hatari's > > > Extended VDI modes have trouble. > > > > > > From your snapshot, it seems that Hatari uses a 2-plane video > > > mode, while EmuTOS thinks there are 4 planes. > > > > > > I don't know how Hatari hacks the video mode, but the tweaked > > > information does not seem to reach the VDI implementation. First, > > > it should be proven that this is not a Hatari bug. Then it may be > > > fixed for 0.8.7 (Roger?) if this is not too complicated and does > > > not introduce regressions. > > > > > I'm willing to take a look at it, but I don't know anything about > > extended VDI modes. Can someone explain? > ... > > This works fine with all TOS versions so far, but EmuTOS still seems > to think that it works in low resolution instead. I wonder why, ... > got to check $ff8260 to see whether we return low or medium > resolution in this mode... Two more observations: - When the AES open the workstation, they seem to get the right resolution information (I added a kprintf to g_v_opnwk() to check) - It still works fine with EmuTOS 0.8.6, so this is a regression. Does anybody have any ideas why EmuTOS' VDI now ignores here the values from the line-a variables / VDI open workstation call? Thomas |
From: Vincent R. <vin...@fr...> - 2012-05-29 21:00:51
|
On 29/05/2012 22:56, Thomas Huth wrote: > - It still works fine with EmuTOS 0.8.6, so this is a regression. > > Does anybody have any ideas why EmuTOS' VDI now ignores here the values > from the line-a variables / VDI open workstation call? There are now calls to Getrez() in the desktop for the resolution change mechanism, this is a clue. Roger, could you please look at that? -- Vincent Rivière |
From: Roger B. <rfb...@ym...> - 2012-05-29 23:24:41
|
On 29 May 2012 at 23:00, Vincent Rivière wrote: > On 29/05/2012 22:56, Thomas Huth wrote: > > - It still works fine with EmuTOS 0.8.6, so this is a regression. > > > > Does anybody have any ideas why EmuTOS' VDI now ignores here the values > > from the line-a variables / VDI open workstation call? > > There are now calls to Getrez() in the desktop for the resolution change > mechanism, this is a clue. > > Roger, could you please look at that? > I can guess a few places where the problem might be, but to debug it, I need to have a setup that demonstrates the problem. I've tried to configure the extended VDI, but it won't work for me. Can someone email me a working Hatari config file with things set up properly? Some other questions that are relevant: How are extended resolutions supposed to work with resolution changing? Is EmuTOS supposed to remember that someone may have hacked its boot resolution so when you re-select the boot resolution (after switching to another one), it uses the hacked values rather than the standard ones? Is the hacking supposed to apply to the boot resolution, or to an initial desktop resolution set via EMUDESK.INF? Roger |
From: Eero T. <oa...@he...> - 2012-05-29 21:48:15
Attachments:
grab0001.png
|
Hi, On tiistai 29 toukokuu 2012, Eero Tamminen wrote: > On maanantai 28 toukokuu 2012, Vincent Rivière wrote: > > New snapshot: EmuTOS CVS-20120528 > > http://sourceforge.net/projects/emutos/files/snapshots/CVS-20120528/ > > > > - Fixed Bconout() return value > > Verified. Unfortunately Midimaze 2 MIDI ring linking still doesn't work and neither does another game using serial, which both work with normal TOS. :-/ > Btw. I found a small new issue. There's some issue > with with EmuTOS 2-plane / 4 color mode support. > > While normal med-rez looks fine, Hatari VDI mode > with 4 colors looks like in the attached picture > when using EmuTOS. Another minor issue is that with TT emulation, using 4 VDI planes the console text size is wrong, both in EMUCON and text-only TOS programs, see attachment. (This issue could maybe be related to the text size issue I mentioned in earlier mails, which wasn't related to TT emulation or Hatari VDI mode.) - Eero |
From: Vincent R. <vin...@fr...> - 2012-05-29 21:53:39
|
On 29/05/2012 23:43, Eero Tamminen wrote: > Unfortunately Midimaze 2 MIDI ring linking still doesn't work and > neither does another game using serial, which both work with normal > TOS. :-/ While Bconout() should be reliable now, Bconin() is still very buggy on the serial port since it does not use buffering so input characters are more likely to be lost. This will have to be fixed later. -- Vincent Rivière |
From: Thomas H. <th...@gm...> - 2012-05-29 23:51:39
|
Am Tue, 29 May 2012 19:24:02 -0400 schrieb "Roger Burrows" <rfb...@ym...>: > On 29 May 2012 at 23:00, Vincent Rivière wrote: > > > On 29/05/2012 22:56, Thomas Huth wrote: > > > - It still works fine with EmuTOS 0.8.6, so this is a regression. > > > > > > Does anybody have any ideas why EmuTOS' VDI now ignores here the > > > values from the line-a variables / VDI open workstation call? > > > > There are now calls to Getrez() in the desktop for the resolution > > change mechanism, this is a clue. > > > > Roger, could you please look at that? > > > I can guess a few places where the problem might be, but to debug it, > I need to have a setup that demonstrates the problem. I've tried to > configure the extended VDI, but it won't work for me. Can someone > email me a working Hatari config file with things set up properly? I started Hatari like this: ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img But you can also simply enable it in the GUI: Press F12 -> Atari Screen - Enable "Use extended VDI screen" - Select "4 colors" > Some other questions that are relevant: > How are extended resolutions supposed to work with resolution > changing? Is EmuTOS supposed to remember that someone may have > hacked its boot resolution so when you re-select the boot resolution > (after switching to another one), it uses the hacked values rather > than the standard ones? Don't worry about resolution switching in that mode - it also does not work with original TOS. Hatari will force the GEM to always stay in the mode that has been selected in Hatari's GUI, since the Line-A variables and opnwk values are always patched to the same values. To change the color depth, the user has to use Hatari's GUI and reset the system. > Is the hacking supposed to apply to the boot > resolution, or to an initial desktop resolution set via EMUDESK.INF? Good question ... there is some very ugly code in Hatari that tries to patch the DESKTOP.INF of the original TOS ... so maybe we will run into more problems if EmuTOS now also tries to switch the resolution according to EMUDESK.INF. ... I guess we've got to try it out how well it works as soon as the 4 color problem has been fixed. Thomas |
From: Roger B. <rfb...@ym...> - 2012-05-31 23:26:50
|
The problem is now fixed. A couple of things to note: 1. Eero's original problem showed up because he had a saved EMUTOS.INF with a resolution different from the default boot resolution. What EmuTOS does in this case is to go through the resolution switch *before* the desktop is opened. This switch causes lineA variables to be reinitialised, thereby causing the display problem. If Eero had booted without EMUDESK.INF, then the screen would have been fine. But it would still have got messed up if resolution change was subsequently selected. 2. EmuTOS now detects when critical lineA variables have been hacked by a cartridge application, and does not attempt a resolution change during bootup in this case. Also, by design, the resolution change dialog is unavailable in this situation. This should cause no problems since, according to Thomas's previous email, selecting resolution change should essentially do nothing anyway when an extended VDI mode is in effect. Roger |
From: Eero T. <oa...@he...> - 2012-06-01 22:10:50
|
Hi, On perjantai 01 kesäkuu 2012, Roger Burrows wrote: > The problem is now fixed. A couple of things to note: > > 1. Eero's original problem showed up because he had a saved EMUTOS.INF > with a resolution different from the default boot resolution. What > EmuTOS does in this case is to go through the resolution switch *before* > the desktop is opened. This switch causes lineA variables to be > reinitialised, thereby causing the display problem. If Eero had booted > without EMUDESK.INF, then the screen would have been fine. But it would > still have got messed up if resolution change was subsequently selected. > > 2. EmuTOS now detects when critical lineA variables have been hacked by a > cartridge application, and does not attempt a resolution change during > bootup in this case. Also, by design, the resolution change dialog is > unavailable in this situation. This should cause no problems since, > according to Thomas's previous email, selecting resolution change should > essentially do nothing anyway when an extended VDI mode is in effect. Is there any particular reason why resolution is set before cartridge is initialized in EmuTOS? As things work with normal TOS, I assume it does that only afterwards. - Eero |
From: Roger B. <rfb...@ym...> - 2012-05-30 00:52:55
|
On 30 May 2012 at 1:51, Thomas Huth wrote: > > I started Hatari like this: > > ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img > I just tried that (with the emutos .img name changed appropriately) but it did nothing. > But you can also simply enable it in the GUI: > > Press F12 -> Atari Screen > - Enable "Use extended VDI screen" > - Select "4 colors" > That's what I tried to do at first with 1.6.1 under Windows - Hatari just exited without a message. I tried the 512K image and the US 256K image. Roger |
From: Vincent R. <vin...@fr...> - 2012-05-30 08:25:33
|
On 30/05/2012 02:52, Roger Burrows wrote: >> ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img >> > I just tried that (with the emutos .img name changed appropriately) but it did > nothing. I asked the Hatari team some time ago. The "Use extended VDI screen" feature works only in ST mode, not in Falcon mode. -- Vincent Rivière |
From: Roger B. <rfb...@ym...> - 2012-05-30 20:31:50
|
On 30 May 2012 at 10:25, Vincent Rivière wrote: > On 30/05/2012 02:52, Roger Burrows wrote: > >> ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img > >> > > I just tried that (with the emutos .img name changed appropriately) but it > did > > nothing. > > I asked the Hatari team some time ago. The "Use extended VDI screen" > feature works only in ST mode, not in Falcon mode. > Thanks for the info, should help in deciding how to fix the problem. However, I *was* trying to start in ST mode. The next thing I'm going to try is starting with the Hatari debugger on, although since it previously returned to the Windows desktop with no message, I'm not hopeful ... Roger |
From: Eero T. <oa...@he...> - 2012-05-30 21:24:40
|
Hi, On keskiviikko 30 toukokuu 2012, Roger Burrows wrote: > On 30 May 2012 at 10:25, Vincent Rivière wrote: > > On 30/05/2012 02:52, Roger Burrows wrote: > > >> ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img > > > > > > I just tried that (with the emutos .img name changed appropriately) > > > but it did nothing. What means "did nothing"? Hatari aborted and (hopefully) showed an error in console? > > I asked the Hatari team some time ago. The "Use extended VDI screen" > > feature works only in ST mode, not in Falcon mode. > > Thanks for the info, should help in deciding how to fix the problem. > > However, I *was* trying to start in ST mode. The next thing I'm going to > try is starting with the Hatari debugger on, although since it > previously returned to the Windows desktop with no message, I'm not > hopeful ... VDI mode should work as well in Windows, there's nothing Linux specific in it. What if you try to switch to VDI mode from the Hatari options "Atari Screen" dialog? When you OK that change, the emulator should tell you that it requires reseting the emulation. - Eero |
From: Eero T. <oa...@he...> - 2012-05-31 20:01:42
Attachments:
grab0002.png
|
Hi, On keskiviikko 30 toukokuu 2012, Vincent Rivière wrote: > > I just tried that (with the emutos .img name changed appropriately) but > > it did nothing. > > I asked the Hatari team some time ago. The "Use extended VDI screen" > feature works only in ST mode, not in Falcon mode. What doesn't work with VDI mode is TOS v4. TOS v4 bombs at boot if one uses 16-color VDI mode. EmuTOS boots with "--machine falcon" and VDI mode without bombing. - Eero |
From: Roger B. <rfb...@ym...> - 2012-05-31 04:30:45
|
On 31 May 2012 at 0:19, Eero Tamminen wrote: > > On keskiviikko 30 toukokuu 2012, Roger Burrows wrote: > > On 30 May 2012 at 10:25, Vincent Rivière wrote: > > > On 30/05/2012 02:52, Roger Burrows wrote: > > > >> ./hatari --vdi 1 --vdi-planes 2 --tos ~/devel/emutos/cvs/emutos2.img > > > > > > > > I just tried that (with the emutos .img name changed appropriately) > > > > but it did nothing. > > What means "did nothing"? > Hatari aborted and (hopefully) showed an error in console? > Hatari went back to the desktop, no console, no message. > > > > I asked the Hatari team some time ago. The "Use extended VDI screen" > > > feature works only in ST mode, not in Falcon mode. > > > > Thanks for the info, should help in deciding how to fix the problem. > > > > However, I *was* trying to start in ST mode. The next thing I'm going to > > try is starting with the Hatari debugger on, although since it > > previously returned to the Windows desktop with no message, I'm not > > hopeful ... > > VDI mode should work as well in Windows, there's nothing Linux > specific in it. > > What if you try to switch to VDI mode from the Hatari options > "Atari Screen" dialog? > > When you OK that change, the emulator should tell you that it > requires reseting the emulation. > Yes. I did. Same problem. This is what I do: Start at the DOS command prompt. Start Hatari normally (ST/68000) with the debugger turned on. After working through all the normal bus error msgs, I get the Atari desktop. Go to the GUI, select extended VDI, reset machine, OK ... and straight back to the command prompt. I'm using a 512K image, if that makes any difference. Roger |
From: Roger B. <rfb...@ym...> - 2012-05-31 17:36:29
|
OK, I finally found what to do to use extended VDI: I removed the GEMDOS drive from my config. This should either be documented somewhere or it's a bug. Now I'll look at the original problem ... Roger |
From: Thomas H. <th...@gm...> - 2012-05-31 18:19:21
|
Am Thu, 31 May 2012 13:35:47 -0400 schrieb "Roger Burrows" <rfb...@ym...>: > OK, I finally found what to do to use extended VDI: I removed the > GEMDOS drive from my config. This should either be documented > somewhere or it's a bug. That's certainly a bug. However, I can not reproduce it here under Linux, so it's most likely specific to Windows... :-( Since there are hardly any Hatari hackers on Windows around, chances are very low that this gets fixed, I'm sorry. Thomas |