cwscws Posted January 3, 2012 Share Posted January 3, 2012 (edited) That's interesting, considering that the only thing I did was add new modes. The "square pixels (fixed multiples only)" mode is just the "integral square pixels" mode renamed. I haven't made any changes at all to the DirectDraw code. The stripe patterns you are seeing are likely the result of scaling down and forcing point sampling mode. The fixed multiple modes will fall back to fractional scaling if the zoom factor drops below 100%. If you are using 320x240 as the display resolution this will always happen for any overscan mode other than OS Screen Only as current versions of Altirra are not intended to run at that low of a resolution. The Normal overscan mode is 336x240/288, the Extended mode is 376x240/288, and the Full mode is 456x262/312. I found the source of my problem with the stripes: scanlines were turned on. I didn't notice that first... The other problem still exist: When using DirectX only and setting custom resolution to 320 x 240 with "Stretch Mode - Square Pixels" the screen is compressed in some way as it centered horizontally (and, because of the right resolution of 320 x 240 with "OS Screen Only", it is horizontally not stretched or distorted in any way) but vertically it is only 2/3 of the right height and displayed on the lower border of the screen. There is a distortion every 20th line or so. Even in window mode. But when using "Stretch Mode - Square Pixels (fixed multiples only) the distortions are gone in window mode but when switching to full screen the picture is again on the lower right side of the screen but heavily distorted (looks like heavily scaled down to maybe about 200 x 100 pixels). With the "Stretch Mode - Preserve Aspect Ratio" it fills the full screen resolution again but it is stretched and therefore not pixel exact, looking distorted. It's interesting that with "Stretch Mode - Preserve Aspect Ratio (fixed multiples only)" I also get the picture again on the lower right side of the screen but heavily distorted again (again looks like 200 x 100 pixels). I can get the best result with "Stretch Mode - Fit to Window" when using 336 x 240 and "Overscan Mode - Normal" (with 320 x 240 as custom resolution and "OS Screen only" I can see very slight vertical distortions which look more like antialiasing then distortions). With this mode the screen does not seem to be stretched or distorted in any way. Scrolling is also very soft (no tearing). So it seems that I found a solution for my problem. Nevertheless it seems to be a bug with the other modes mentioned above, especially with "Stretch Mode - Square Pixels (fixed multiples only)" - it must be a bug that the picture is shown on the lower right side of the screen instead of full screen as the resolution would fit perfectly (320 x 240 with OS Screen Only)... After I got the screen mode right I noticed that vsync is not that good as with Altirra 1.9 and DirectDraw, almost but not fully. It's good but I still get very slight jerking when scrolling. I tried different speed modes but that does not do the trick. I think you could get rid of this problem when using sync to screen instead of vsync... --------- I have another feature request: Can you please include an option for a custom key map? I would like to map the keys for "Option", "Start" and "Select" not to F1, F2 and F3 but to other keys. Edited January 3, 2012 by cwscws Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2012 Share Posted January 3, 2012 Please, no sync to screen or only as a choice...please... My LCD only has 60 or 70Hz, PAL emulation would run too fast, I don't have the money to go out and buy brand new hardware no matter how hard some people in the emulation community cannot understand. Just had a similar sort of chat on another forum, "just go out and get a $1000 dollar monitor", "just go and buy new hardware already", pah, if life was so simple, as most will know on here I cannot work because of illness, I barely afford silly things like the Internet. Sorry, rant mode off, I just hate it when people not on this forum just presume its all so easy... Quote Link to comment Share on other sites More sharing options...
cwscws Posted January 3, 2012 Share Posted January 3, 2012 Nevertheless I noticed that vsync in DirectX mode is not working at all. As my system runs at about 60 Hz I never noticed that but switching vsync on or off doesn't make a difference. It's interesting that Altirra 1.9 works perfect with DirectDraw and vsync. Sync to screen would not make your emulation too fast - as you can switch to 60 Hz, all NTSC based games would run at native speed but with the advantage of perfect syncing. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2012 Share Posted January 3, 2012 Nevertheless I noticed that vsync in DirectX mode is not working at all. As my system runs at about 60 Hz I never noticed that but switching vsync on or off doesn't make a difference. It's interesting that Altirra 1.9 works perfect with DirectDraw and vsync. Sync to screen would not make your emulation too fast - as you can switch to 60 Hz, all NTSC based games would run at native speed but with the advantage of perfect syncing. The problem here is that not every game is American, many are Polish etc in origin and some will break under 60Hz I believe, its also fair to remember that those of us in the UK etc have been playing in 50Hz since day one and if forced into a Hz rating not common to us would find it a very odd experience. Sorry, there are other places than the US you know 1 Quote Link to comment Share on other sites More sharing options...
cwscws Posted January 3, 2012 Share Posted January 3, 2012 I know, I'm from with the EU... Nevertheless I think a sync to screen would be nice (of course, optionally). Or a really working vsync. I also thought about stretching and filtering: Despite everything I would like to see a 1:1 pixel output without any stretching and filtering. If I set resolution to e.g. 640 x 480 I would like to see 336 x 240 native resolution within this higher resolution (so picture would be smaller in the middle of the screen). I request this because I do not have a resolution like 336 x 288 for PAL (but 336 x 240 for NTSC is available). So I would switch to 352 x 288, which is available here, and Altirra should display 336 x 288 without stretching (leaving some unused pixels left and right of the picture). This would be cool and I could avoid any other display problems I discribed before... Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2012 Share Posted January 3, 2012 Lol..Sorry, my bad guess there I'm sure the Atari God that is Phaeron will go down whatever available dev paths he has to make sure the goodness that is Altirra will be as accurate as possible since that's been the whole idea behind Altirra, no silly hacks, just working as it should by excellent emulation coding. As always its a WIP and there's bits to go but all in all its a great bit of coding. /Altirra preaching over..... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 What amazes me is that the EXE is still not 2MB long... Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 3, 2012 Share Posted January 3, 2012 I must admit, I would kill for a PAL60 (well, essentially an overclocked CPU) mode purely for development purposes.. A lot of the time I code using NTSC just because it's a smoother ride under emulation (null) Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 4, 2012 Author Share Posted January 4, 2012 OK, I've managed to reproduce the offset display issue at low resolutions on an XP machine... that should be enough to fix it. What amazes me is that the EXE is still not 2MB long... It actually takes a lot of effort to write 2MB of code, without cheating with auto-generation, or as is more commonly done, pulling in a lot of libs made by someone else. To give you another idea, one of the projects I worked on professionally took about five years and eventually a team of more than 25 people to produce a 12MB executable. Code size is now almost always insignificant compared to data or heap size, now that we have more than 64K of RAM and aren't loading over a 19200 baud SIO bus. That having been said, I wouldn't mind the executable actually being smaller... but despite having just ranted about bloat on my blog, there's a point at which even I don't care enough, compared to everything else on the list. I must admit, I would kill for a PAL60 (well, essentially an overclocked CPU) mode purely for development purposes.. A lot of the time I code using NTSC just because it's a smoother ride under emulation I can trivially add such an option... but the main problem is that it would also drop the pitch of the sound by a quarter of an octave due to synchronized sound. Avoiding that would require pitch shifting, which adds latency. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 4, 2012 Share Posted January 4, 2012 It actually takes a lot of effort to write 2MB of code, without cheating with auto-generation, or as is more commonly done, pulling in a lot of libs made by someone else. To give you another idea, one of the projects I worked on professionally took about five years and eventually a team of more than 25 people to produce a 12MB executable. Code size is now almost always insignificant compared to data or heap size, now that we have more than 64K of RAM and aren't loading over a 19200 baud SIO bus. That having been said, I wouldn't mind the executable actually being smaller... but despite having just ranted about bloat on my blog, there's a point at which even I don't care enough, compared to everything else on the list. Yeah - I think the fact it's taken so long for Altirra to approach 2MB after having such a myriad of features added to it over time kind of demonstrates the fact it's not easy to produce that much code. One of my projects consists of 35KB of raw assembler... it took two years to get it up to that size! Quote Link to comment Share on other sites More sharing options...
cwscws Posted January 4, 2012 Share Posted January 4, 2012 (edited) OK, I've managed to reproduce the offset display issue at low resolutions on an XP machine... that should be enough to fix it. GREAT! If this really works as it should, I should see a correct unstretched picture in 336x240 with "Stretch Mode - Square Pixels (fixed multiples only)" and overscan normal. But please include an option to see unfiltered and unstretched 1:1 pixels even it is not the native resolution but higher resolutions (like I said 336x288 on a 352x288 - in this case with with black bars left and right). And if this is not much work, a method to remap keys from the keyboard. Edit: I just noticed a problem with resolution switching when starting Altirra by command line and the parameter /f. On my system is simply does not switch to the custom resolution (it's using the desktop resolution instead). But it is no problem when pressing Alt + Return when the emulator is running... Edited January 4, 2012 by cwscws Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 4, 2012 Share Posted January 4, 2012 (edited) Its great that you guys still have the mindset to create code that isn't bloat, with so many that have succumbed to the M$ school of oversized beta's at full price packed full of bugs its nice to see some people do it right. I use Openoffice because its free, its nothing like the size of MS nonsense and its better in my book. I've never had a single issue with it and if I lose my backup I can download the entire suite in minutes even on my awful speed. Long live all you decent coders.... Edited January 4, 2012 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
atx4us Posted January 5, 2012 Share Posted January 5, 2012 Altirra-2.10-test7 - Looks like the key repeat issue with Action! is fixed. Thank you! Altirra has come a long way and it's looking really great! Quote Link to comment Share on other sites More sharing options...
JCat Posted January 6, 2012 Share Posted January 6, 2012 One of my favorite emus, no doubt. Would love to see this running on an Android or IPad some day, though the iPad would have to be jail broken. Quote Link to comment Share on other sites More sharing options...
cwscws Posted January 6, 2012 Share Posted January 6, 2012 (edited) With Altirra 2.1-test9 the display-mode "Stretch Mode - Square Pixels" or with "(fixed multiples only)" and Filter "Point" works perfect now! Even if I use 352 x 256 pixels are displayed 1:1! That's exactely what I requested! Thank you! The only thing I still have to test are PAL-modes. I'll report that as soon as I have tested it. Did you change anything in the fullscreen switching code for command line paramater /f? It didn't work before right and I still have to test this with the new version... The only thing I'm missing now is the possibility to remap keys (like Option, Select, Start) to other keys or key combinations. At the moment only game controllers can be (re)mapped but not the Atari keyboard itself... Edit: vsync still does not do anything on my computer, no matter if I select it or not - it's the same result. With 336 x 240 I noticed a slight jerking at scrolling, but with 352 x 256 scrolling is absolutely soft (without activating (the non-working) vsync)! Edit2: I just tried PAL-mode with 352 x 288 - pixels are still 1:1, working perfect! But as said - vsync not really has any effect... Edited January 6, 2012 by cwscws Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 7, 2012 Share Posted January 7, 2012 Any chance that someone has a file that demonstrates the full use of the Altirra label files ? I want to quickly add proper Altirra label output to Acme 0.93 whilst I'm changing some other things in it today, and so far I've added CC65 label support for now, but would like to add proper Altirra label file support since it seems there's all manner of groups, RWE flags and other goodies lurking in the specification.. Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 7, 2012 Author Share Posted January 7, 2012 It's not terribly exciting. You have a header line that reads "Altirra symbol file" followed by a [symbols] group. Each symbol line is then of the form: mode address,length name Where mode is one or more of the characters rwx for read/write/execute, the address is a 16-bit hex address without any prefix, the length is a hex length in bytes without a prefix, and the name is just the symbol name. A zero length indicates a symbol of indeterminate length. The main use of the rwx flags is to disambiguate the hardware read-only and write-only registers that occupy the same addresses, but it's a moot point in that case as the debugger's internal hardware symbols have priority when loaded. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 8, 2012 Share Posted January 8, 2012 I'm chasing a nasty bug here and have a request: Could the Breakpoint facility be altered to allow VRAM accesses (specifically by blit) to trigger one? e.g. BA W V:38880 Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 8, 2012 Share Posted January 8, 2012 It's not terribly exciting. You have a header line that reads "Altirra symbol file" followed by a [symbols] group. Each symbol line is then of the form: mode address,length name Where mode is one or more of the characters rwx for read/write/execute, the address is a 16-bit hex address without any prefix, the length is a hex length in bytes without a prefix, and the name is just the symbol name. A zero length indicates a symbol of indeterminate length. The main use of the rwx flags is to disambiguate the hardware read-only and write-only registers that occupy the same addresses, but it's a moot point in that case as the debugger's internal hardware symbols have priority when loaded. Cool, so it is as straight forward as I thought then.. Just wanted to support everything that was possible since the debugger is getting a lot of use here.. Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 11, 2012 Share Posted January 11, 2012 Is there any chance of having some way to set breakpoints from the command line or maybe, like Vice, a set of monitor commands that are loaded before execution begins although after any symbol file is loaded ? The /debug and /debugbreak command line options are really handy, but things can get a bit tedious having to re-enter the breakpoints.. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 11, 2012 Share Posted January 11, 2012 While developing, a handy trick is to use instructions that write to an unused area then you can have an all-in-one trap. e.g. sta $D7FF Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 11, 2012 Share Posted January 11, 2012 I guess my problem is that I'm being super lazy and using Visual Studio, so I press F5 it fires up Altirra, and when I rebuild or end debugging it simply tears down all the processes created by the debugging session, so I'm not running a persistent Altirra session over builds, which would be the answer then I'd only need to set things once per session.. I just like a nice environment that's as consistent as possible for my simple brain That said... I just was about to start adding something to Altirra to do what I want, when I found this in the command line processing code, which isn't mentioned in the help output on the command line.. while(cmdLine.FindAndRemoveSwitch(L"debugcmd", arg)) { debugMode = true; debugModeSuspend = true; dbg->QueueCommand(VDTextWToA(arg).c_str(), false); } So, I can add debugger commands to the command line via /debugcmd "bp LabelName" for example.. Which is almost exactly what I wanted.. Now to write a utility match the export symbols to line numbers and then I can integrate the VS breakpoints directly into my build cycle, and just use F9 to enable/disable breakpoints Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 11, 2012 Share Posted January 11, 2012 Is there an Altirra option to only run one instance of the emulator? Maybe you could use that and set VS not to shut it down. Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 11, 2012 Share Posted January 11, 2012 I recall there was some mention on the IDE thread about some option added to do only one instance, but I'm not mad about that way of doing things to be honest.. As for VS, I've never seen any option to not tear down the processes created by starting a debug session, but I could be wrong as it's not something I've ever wanted to not do.. I'm perfectly happy now anyway.. I can now export my breakpoints to a file and have the command line breakpoints constructed as part of the build process so it's as automagic as I want now, well from the point of being able to have breakpoints inserted each session anyway.. edit: Oh crikey! And as luck would have it I've just found the .batch command in the debugger, so I guess that's everything I was looking for really when combined with the /debugcmd option.. So now all you need is to do /debugcmd ".batch debuggercommands.txt" and bob's your sisters brother.. Bingo.. Phaeron really has thought of everything Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2012 Share Posted January 11, 2012 Tools -> Options -> Startup -> Reuse program instance. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.