Jump to content
IGNORED

Altirra 3.90 released


phaeron

Recommended Posts

Anyway this is the Area 3 music.  As stated before, the CSAVE bell during the main melody seems ok, the issues happen with the saw wave bit at the beginning of the tune.  Correct on real HW, and on Altirra 3.20, incorrect on later Altirra, and also on my Dragonfly 7800 cart with PokeyMax

 

exo-area3.xex

Edited by Synthpopalooza
  • Like 1
Link to comment
Share on other sites

I've tracked down the issue with the two-tone technique, it has to do with a fix that I made for 1.79MHz timers in two-tone mode not having the proper extra two cycle delay. I'm guessing the specific problem has to do with the interaction between two-tone mode and 16-bit linked timers. So I can say that the issue is confirmed, but I'd have to dig more into what's going on in the actual hardware since the fix won't be as simple as reverting the change that triggered it.

 

  • Like 4
  • Thanks 2
Link to comment
Share on other sites

Posting the source code for both tunes ... and the exe for the second one.

 

Specifically, AUDCTL=$60 or $61 with two-tone mode engaged.  The 1.79 two tone mode is overlaid on either a 15 or 64 khz base clock.  Also posting my note table for both modes as a reference should you want to test.

 

Area 3 (aka title) uses 64khz clock, while Area 4 uses 15 khz.

 

exo-area3.xex exo-title.asm exo-title.s exo-title4.asm exo-title4.s exo-title4.xex pokey notes - skctl.xlsx

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, phaeron said:

I've tracked down the issue with the two-tone technique, it has to do with a fix that I made for 1.79MHz timers in two-tone mode not having the proper extra two cycle delay. I'm guessing the specific problem has to do with the interaction between two-tone mode and 16-bit linked timers. So I can say that the issue is confirmed, but I'd have to dig more into what's going on in the actual hardware since the fix won't be as simple as reverting the change that triggered it.

 

The two tunes don't use 16-bit, just a 1.79 clock on first channel, paired with either 64 or 15 khz clock, which will affect which octave you can play notes in.

Link to comment
Share on other sites

22 hours ago, oo7 said:

So my goal was to run 640x480 60hz exclusive full screen. And this is where i was having a problem. I had set altirra to dx11… before trying other recommendations which would work but would take me out of the exclusive resolution i wanted i dropped to dx9 mode. This fixed it. Also explains why the other apps work, they are running in dx9

 

i now think the wrong behaviour i observed is either a issue directly with dx11 or with dx11 and my radeon or dx11 and altirra. 
 

will test other combos on other and report back.

It sounds like the display mode you're asking for isn't actually supported. Direct3D 11 has a bad habit of 'fixing' the display mode if it doesn't match exactly, which results in the stretch-o-vision that you describe. If your monitor has an on-screen-display, you can check it to see if Windows is actually switching to the right display resolution. When the display mode match fails, Windows just picks a random other resolution without the program knowing, and this causing broken displays. The display mode fuzzy-match logic is different between D3D9 and D3D11 and it sounds like only the D3D9 version is successfully matching. I'd like to try to resolve this because the intent is to eventually switch to D3D11 as the default.

 

As a side note, I just found a bug where if you have hardware screen effects enabled (bloom) then D3D9 will not successfully switch to exclusive full-screen mode. This will be fixed in the next test release.

 

21 hours ago, Keatah said:

I would assume there'll come a time (if not already) that all emulators will have to properly scale internally since 4K is pretty much standard and 8K awaiting price drops. Modern resolutions are huge compared to a 41-year old Atari.

This has already long been the case, for any emulator that isn't running full-screen in Mode 13h. A 240-line tall display is tiny on any display that can run Windows, and even if the display can be switched that low, the display scaling on a modern display isn't very controllable or representative of old displays. Using GPU hardware acceleration for this stretch is critical these days since even a modern CPU will struggle to do software stretching up to FHD+ at 60 fps. And that's before taking into account extras like gamma-correct scanlines.

 

What's becoming increasingly common is the realization that point-sampling, i.e. this:

 

image.png.67bb09e00b5001902e25ad5fd4ea163a.png

 

isn't "retro", it just looks like #$&*. Same with bilinear, which is a blurry mess. Which is why Altirra defaults to sharp bilinear instead, which looks sharper than bilinear without scaling everything unevenly. CRT emulation is also getting popular, but is a lot harder to get looking good across the board and is also a lot more complex and heavy to render. (Altirra's default rendering with bloom enabled takes 3ms/frame on an integrated GPU at 2560x1440, and that's with half precision optimizations and not doing that much.)

  • Like 2
  • Thanks 2
Link to comment
Share on other sites

5 hours ago, phaeron said:

It sounds like the display mode you're asking for isn't actually supported. Direct3D 11 has a bad habit of 'fixing' the display mode if it doesn't match exactly, which results in the stretch-o-vision that you describe. If your monitor has an on-screen-display, you can check it to see if Windows is actually switching to the right display resolution. When the display mode match fails, Windows just picks a random other resolution without the program knowing, and this causing broken displays. The display mode fuzzy-match logic is different between D3D9 and D3D11 and it sounds like only the D3D9 version is successfully matching. I'd like to try to resolve this because the intent is to eventually switch to D3D11 as the default.

 

As a side note, I just found a bug where if you have hardware screen effects enabled (bloom) then D3D9 will not successfully switch to exclusive full-screen mode. This will be fixed in the next test release.

 

This has already long been the case, for any emulator that isn't running full-screen in Mode 13h. A 240-line tall display is tiny on any display that can run Windows, and even if the display can be switched that low, the display scaling on a modern display isn't very controllable or representative of old displays. Using GPU hardware acceleration for this stretch is critical these days since even a modern CPU will struggle to do software stretching up to FHD+ at 60 fps. And that's before taking into account extras like gamma-correct scanlines.

 

What's becoming increasingly common is the realization that point-sampling, i.e. this:

 

image.png.67bb09e00b5001902e25ad5fd4ea163a.png

 

isn't "retro", it just looks like #$&*. Same with bilinear, which is a blurry mess. Which is why Altirra defaults to sharp bilinear instead, which looks sharper than bilinear without scaling everything unevenly. CRT emulation is also getting popular, but is a lot harder to get looking good across the board and is also a lot more complex and heavy to render. (Altirra's default rendering with bloom enabled takes 3ms/frame on an integrated GPU at 2560x1440, and that's with half precision optimizations and not doing that much.)

Glad my side tracking helped you find that issue then. (Exclusive fullscreen + bloom)

 

The DX11 explanation you gave makes perfect sense as those are resolutions that are not supported (which I never realized)

 

Your statements on "retro look" are so true, with most emulation I struggle to find a look I like, most emulators I take to retroarch for the best CRT emulation I can find, this helps where programmers did tricks on CRTs to look better ((example Shinobi 3 sega genesis on a CRT or with the right shader water and water falls look amazing and transparent on a lcd without the right shaders its lines, dithering) This being said I find Altirra does a very good job at looking retro.

 

Im going to take this opportunity to once again say thanks very much for Altirra, I truly love this emulator, I like it so much that I actually bought a specific machine for it that I call my atari portable, your emulator runs great (accuracy & compatibility) and on top of it your code executes so efficient, very little power required for what is going on. 

 

 

Link to comment
Share on other sites

9 hours ago, ascrnet said:

Query in Altirra is there any way to know which cartridge address lines (A0 to a12) were used when loading a .CAR image ??

All of them up to log(cartsize), right? What is the goal you're trying to accomplish? To see if there is only 2k of content in 8k image?

Link to comment
Share on other sites

I have a improvement ticket for Avery regarding VBXE... coming back to A8 and VBXE coding and being now 2 years in SNES Land... most emulators there show the PPU registers not just by values but sense of gfx panel.

 

e.g. frame buffer, sprite hardware and palette... I spent 2 days debugging my code and realised by accident... palette was empty and black... no wonder nothing on screen... :D

 

  • Like 2
Link to comment
Share on other sites

12 hours ago, jindroush said:

All of them up to log(cartsize), right? What is the goal you're trying to accomplish? To see if there is only 2k of content in 8k image?

my goal is to understand how the ultracart 32k works since I want to emulate it on FPGA for the Ultimate cart.?

Link to comment
Share on other sites

5 minutes ago, ascrnet said:

my goal is to understand how the ultracart 32k works since I want to emulate it on FPGA for the Ultimate cart.?

Obviously 32k cart must be bankswitched and there's no way how checking A0-A12 would help you (as you need also A13 and A14 to address the bank selection)

In Atari800 source (can't see it in Altirra sources) there's
//switch bank

case CARTRIDGE_ULTRACART_32:
case CARTRIDGE_BLIZZARD_32:
case CARTRIDGE_ADAWLIAH_32:
set_bank_A0BF(4, 3);

break;

//on write to D5

case CARTRIDGE_ULTRACART_32:
new_state = (old_state + 1) % 5;

break;

From this I'd say that it works like this: there are 4 8kb banks (mapped in A000-BFFF), and each access to D5xx changes to next bank, 5th state is to turn cart off. I don't have the dump though to verify that.

Link to comment
Share on other sites

On 8/19/2021 at 1:30 PM, patjomki said:

Is there an Altirra device for Sophia 2 available? I like to test HIRESBC a little bit.

Not currently. I have a Sophia 2 and know how it works, but it is not currently emulated.

 

13 hours ago, Heaven/TQA said:

I have a improvement ticket for Avery regarding VBXE... coming back to A8 and VBXE coding and being now 2 years in SNES Land... most emulators there show the PPU registers not just by values but sense of gfx panel.

 

e.g. frame buffer, sprite hardware and palette... I spent 2 days debugging my code and realised by accident... palette was empty and black... no wonder nothing on screen... :D

The PPU has regular tile layouts which are more amenable to this, but I could add a debugger command to dump the VBXE palette since I don't think there is one right now.

 

5 hours ago, jindroush said:

In Atari800 source (can't see it in Altirra sources) there's

It's there, but called by the old name of MicroCalc as it seems that it has been renamed afterward in Atari800. Your functional description of CAR type 52 is correct.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Keatah said:

What are these little numbers on the bottom? The 1, 2, and 12 on-screen indicators.

1200XL console LEDs, LED #1 and LED#2. They are toggled when Ctrl+F1 and Ctrl+F4 are pressed to toggle the display and international character sets, respectively. They are controlled by bits in PORTB, which is why you see them activate when the extended RAM tester runs.

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...