Altirra 2.70 released

[flashjazzcat]

Which version of the emulator are you using? I just tested it here and it appears OK. Note that only bits 1-3 are guaranteed to read the expected values (according to the Altirra Hardware Reference Manual), and PAL reads $01 here, while NTSC reads $0F.

Edited May 30, 2016 by flashjazzcat

[atx4us]

Which version of the emulator are you using? I just tested it here and it appears OK. Note that only bits 1-3 are guaranteed to read the expected values (according to the Altirra Hardware Reference Manual), and PAL reads $01 here, while NTSC reads $0F.

Hello FJC,

 

I don't think the results depend as much on the version of the emulator as the selected OS ROM files. With the many OS ROM files are available for the emulators today, (eg. Altirra OS), I'm not sure if I can detect NTSC vs. PAL reliably in my program. So the key question that I have is, is there a reliable way to detect PAL computers and not to depend on a the value from a single memory location?

 

Thanks,

Hayden

[atx4us]

Hello FJC,

 

I don't think the results depend as much on the version of the emulator as the selected OS ROM files. With the many OS ROM files are available for the emulators today, (eg. Altirra OS), I'm not sure if I can detect NTSC vs. PAL reliably in my program. So the key question that I have is, is there a reliable way to detect PAL computers and not to depend on a the value from a single memory location?

 

Thanks,

Hayden

Altirra OS is a bad example on my part! It seems to return the correct values. But, I think my concern is still valid because I'm sure there are other OS options out there that I'm not even aware of and what values will they return? Is there another way to determine NTSC vs. PAL without relying on just memory locations. For example, running a test loop?

 

Thanks,

Hayden

[flashjazzcat]

It's not a ROM location but a hardware register which should (will) read the same regardless of the OS used. I never bother with it, though. I prefer to watch VCOUNT and see how far it counts in one frame (it's higher on PAL hardware).

[phaeron]

Whoops:

http://www.virtualdub.org/beta/Altirra-2.80-test40.zip

http://www.virtualdub.org/beta/Altirra-2.80-test40-src.zip

 

 

According to the Mapping the Atari, I can determine a PAL vs. NTSC computer by reading the value at address 53268 (below). However, in Altirra, I'm not seeing these values. Am I missing something or is there a better way to tell between a PAL vs. NTSC computer? Thanks.

 

"53268 $DO14 COLPM2
(W) Color and luminance of player and missile 2 (706).

PAL
® Used to determine if the Atari is PAL (European and Israeli
TV compatible when BITs 1 - 3 equal zero) or NTSC (North
American compatible when BITs 1 - 3 equal one; 14 decimal, $E)."

 

This is correct, and is supported by Altirra. The catch is in the "bits 1-3" part. It's often ignored that Atari only documented bits 1-3 of the byte read from the PAL register as being significant, with bits 0 and 4-7 supposed to be ignored. This documentation is misleading in that it gives the value 14, but that's only for bits 1-3. In practice, bit 0 is always set and bits 4-7 are clear, giving 1 for PAL/SECAM and 15 for NTSC. I haven't heard of any computer giving different values. There was a rumor that SECAM systems would give 0 instead of 1, but I believe this has been discredited.

 

There is an additional caveat, which is that this register reports whether GTIA is NTSC or PAL. It doesn't tell you whether ANTIC is NTSC or PAL. On the vast majority of computers these will be matched, but people have created mixed-mode computers that have a PAL ANTIC with an NTSC GTIA. This means that the PAL register only actually indicates the color encoding and not the frame rate (50/60Hz). If you really want to handle all computers correctly including mixed-mode computers, you need to poll VCOUNT in order to determine the ANTIC type. You can emulate this configuration in recent versions of Altirra by choosing the PAL-60 or NTSC-50 video modes.

 

[atx4us]

It's not a ROM location but a hardware register which should (will) read the same regardless of the OS used. I never bother with it, though. I prefer to watch VCOUNT and see how far it counts in one frame (it's higher on PAL hardware).

You're right! I just wasn't thinking straight. It's been a very long time since I've been back to the Atari 8-bit computers and it really shows. Thanks for the help to get me thinking Atari computers again.

[atx4us]

Whoops:

http://www.virtualdub.org/beta/Altirra-2.80-test40.zip

http://www.virtualdub.org/beta/Altirra-2.80-test40-src.zip

 

 

 

This is correct, and is supported by Altirra. The catch is in the "bits 1-3" part. It's often ignored that Atari only documented bits 1-3 of the byte read from the PAL register as being significant, with bits 0 and 4-7 supposed to be ignored. This documentation is misleading in that it gives the value 14, but that's only for bits 1-3. In practice, bit 0 is always set and bits 4-7 are clear, giving 1 for PAL/SECAM and 15 for NTSC. I haven't heard of any computer giving different values. There was a rumor that SECAM systems would give 0 instead of 1, but I believe this has been discredited.

 

There is an additional caveat, which is that this register reports whether GTIA is NTSC or PAL. It doesn't tell you whether ANTIC is NTSC or PAL. On the vast majority of computers these will be matched, but people have created mixed-mode computers that have a PAL ANTIC with an NTSC GTIA. This means that the PAL register only actually indicates the color encoding and not the frame rate (50/60Hz). If you really want to handle all computers correctly including mixed-mode computers, you need to poll VCOUNT in order to determine the ANTIC type. You can emulate this configuration in recent versions of Altirra by choosing the PAL-60 or NTSC-50 video modes.

 

Thank you for the much needed clarifications and for the additional details. The documentation wasn't entirely clear to me. But, now I know. I'm still learning more about the Atari 8-bit computers after all these years!

[Docwiz]

Whoops:

http://www.virtualdub.org/beta/Altirra-2.80-test40.zip

http://www.virtualdub.org/beta/Altirra-2.80-test40-src.zip

 

 

 

Hi,

 

First I want to say how I enjoy your emulator. Between this emulator, the Amiga emulator WINUAE and DosBox, I pretty much get all my old computer fill. Thank you for taking your time and hard work to make this wonderful emulation stuff!

 

Now on to my issue....

 

I am using Windows 10 Professional 64-bit and I am running the 32-bit version and I can run it fine and it works fine. The only problem that I have had is with one of the Direct 3D 9 shaders (specifically VINTAGE TV.cgp)

I have an Nvidia 670 GTX and I can run it fine in a window, but it stop updating the screen if I go full screen.

 

So, I can hear the music of the game or sound effects and I can actually still play it, but I can't see anything because the screen stops updating when it comes to full screen. Obviously full screen is what you would want.

If you want, I can provide a video of it, so you can see it.

 

Anyone else have this issue with this shader specifically?

 

Also, I have a question for you. Why not focus on Direct 3D 11/12 or the new Vulcan shaders as they are more future proof?

[+Stephen]

Hello everyone,

 

According to the Mapping the Atari, I can determine a PAL vs. NTSC computer by reading the value at address 53268 (below). However, in Altirra, I'm not seeing these values. Am I missing something or is there a better way to tell between a PAL vs. NTSC computer? Thanks.

 

"53268 $DO14 COLPM2

(W) Color and luminance of player and missile 2 (706).

PAL

® Used to determine if the Atari is PAL (European and Israeli

TV compatible when BITs 1 - 3 equal zero) or NTSC (North

American compatible when BITs 1 - 3 equal one; 14 decimal, $E)."

Just a guess, but I am thinking the value is the same in Altira because the same OS ROM is used for PAL and NTSC. IIRC, you can check the VCOUNT register.

[flashjazzcat]

I think he's OK now, since bit 0 being set causes the returned value not to match the (incorrect) one quoted in Mapping the Atari. As mentioned, it's not a ROM location but a GTIA register, so it doesn't matter which ROM is used.

[Suppawer]

 

I can run it fine in a window, but it stop updating the screen if I go full screen.

So, I can hear the music of the game or sound effects and I can actually still play it, but I can't see anything because the screen stops updating when it comes to full screen. Obviously full screen is what you would want.

 

I have the same issue

[flashjazzcat]

 

I have the same issue

 

Same here too.

[phaeron]

Try now:

http://www.virtualdub.org/beta/Altirra-2.80-test41.zip

http://www.virtualdub.org/beta/Altirra-2.80-test41-src.zip

 

 

Also, I have a question for you. Why not focus on Direct 3D 11/12 or the new Vulcan shaders as they are more future proof?

 

D3D11 requires Vista+ with Platform Update and D3D12 requires Windows 10. The shaders I've tried to make this work with, on the other hand, don't really even push shader model 3.0 except by instruction count. Shaders that don't use new features don't run any faster on the newer D3D versions. The main impediment to improving the Vintage TV shader that I found and ported is not the shader language or the graphics API, but simply that the shaders are a mess and hard to optimize.

 

The major draw of D3D11 and especially D3D12 is reduced draw call overhead. That's not much of a benefit when you're doing 3 draw calls a frame instead of 500+ and CPU time in the graphics driver is already negligible. Also, dealing with D3D11 is significantly more complicated when using downlevel hardware, particularly DX9-class. This puts you in a weird twilight zone layer called 10level9 which is somewhat awkward to deal with and requires shaders to be compiled into a weird mega-format with multiple subshaders for each tier. I've dealt with this for the built-in shaders but it's more annoying to deal with for custom external shaders. Direct3D 9, on the other hand, is extremely well established by this point and pretty much anyone with a computer worth running Altirra can run D3D9 with at least shader model 2.0.

 

Vulkan is fairly new and I don't have a render path for it currently. It's conceptually similar to D3D12 and Mantle, which means higher draw call performance but more manual hazard management and a higher minimum GPU spec, and the same lower applicability here. With regard to shaders, the API doesn't appear to require a runtime shader language compiler, which is a problem for this usage. Even if it did, GLSL historically has had more differences from Cg, some gratuitous (why mix instead of lerp?). Then there's the issue that platform-level support for the GL APIs on Windows hasn't been as good, which makes things like low-latency windowed mode vsync more challenging (or at least, buried knee-deep in extensions).

 

The new graphics APIs are highly oriented towards streamlining the draw path because Direct3D 9 was notorious for hugely expensive draw calls -- as in, your frame rate could be determined almost entirely by the number of times DrawIndexedPrimitive() is called per second. For years OpenGL enjoyed about a 2.5x benefit over D3D9 in this regard, D3D11 eventually somewhat caught up, and Mantle showed the way to making it significantly faster than even that. Some of the changes involved, though, can be somewhat annoying if you're just trying to draw some 2D shapes and images on screen as Altirra mostly does. For instance, to blit an image to the screen, D3D11 requires a blend state object, rasterizer state object, sampler state object, constant buffer object, input layout object, shader resource view object, and render target view object, in addition to the classic vertex shader, pixel shader, texture, and swap chain objects. All of this runs nicely smoothly once you've got it all up and running, since most of the validation happens at create time. However, getting it all off the ground kinda sucks.

 

[Suppawer]

Try now:

http://www.virtualdub.org/beta/Altirra-2.80-test41.zip

 

Works excellent. Thanks!

[flashjazzcat]

Yep: working great now.

 

Apologies if I already asked this (and was answered), but is there any way to emulate the SDX switch on the IDE Plus 2.0 (i.e. by tying it to System->Console Swiches->Enable Cart SDX)? IDE Plus always defaults to the switch condition on real hardware, which in the machine as emulated is hard-coded "on". Even when using SDX, it's sometimes useful to use the U1MB SDX instead. Or perhaps per-device switch settings would be better off moved to the device tree's properties dialogues, since I guess there may be times when there's some ambiguity as to exactly which device the Console Switch selection actually refers. Or perhaps just add more stuff to the menu (like the BB settings, which just grey out)... unsure.

Edited June 2, 2016 by flashjazzcat

[flashjazzcat]

Can the "File View" View mode (in the disk explorer) and window size be made persistent? It's a super-convenient way to view readme files in ARCs but it would be rather cool if it could open in - say - "Text: wrap to window" every time, and with the window somewhat expanded.

[JoSch]

@phaeron Can you look at this issue (http://atariage.com/forums/topic/240919-mad-pascal/?p=3526101)?

I used Altirra 1.71.

Edited June 7, 2016 by JoSch

[phaeron]

@phaeron Can you look at this issue (http://atariage.com/forums/topic/240919-mad-pascal/?p=3526101)?

I used Altirra 1.71.

 

I can't tell anything from a screenshot. Please provide a program I can run to reproduce the issue.

[JoSch]

Oh, sorry. Tebe posted a zip (http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=453802). In the directory eight_ray there is a binary.

Edited June 8, 2016 by JoSch

[phaeron]

Oh, sorry. Tebe posted a zip (http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=453802). In the directory eight_ray there is a binary.

 

This is due to a bug in the Mad Pascal output routine. The program is overwriting RMARGN with $01:

- 5238: 59: 82 | A=EB X=BB Y=28 (N     ) | 234A: 20 89 23          JSR $2389
    5238: 59: 94 | A=EB X=BB Y=28 (N     ) | 2389: 18                CLC
    5238: 59: 98 | A=EB X=BB Y=28 (N     ) | 238A: 75 98             ADC $98,X    ;$53
    5238: 59:103 | A=F1 X=BB Y=28 (N     ) | 238C: 85 90             STA $90
    5238: 59:106 | A=F1 X=BB Y=28 (N     ) | 238E: 98                TYA
    5238: 59:108 | A=28 X=BB Y=28 (      ) | 238F: 75 A8             ADC $A8,X    ;$63
    5238: 59:112 | A=28 X=BB Y=28 (      ) | 2391: 85 91             STA $91
    5238: 60:  1 | A=28 X=BB Y=28 (      ) | 2393: A0 00             LDY #$00
    5238: 60:  3 | A=28 X=BB Y=00 (    Z ) | 2395: B1 90             LDA ($90),Y  ;$28F1
    5238: 60:  8 | A=01 X=BB Y=00 (      ) | 2397: 95 98             STA $98,X    ;$53

This is happening because the I/O routine is depending on the value of the X register on return from the PUT BYTE routine of the E: device:

  9088: 47:  7 | A=4C X=93 Y=01 (N     ) | 2335: CA                DEX
  9088: 47:  9 | A=4C X=92 Y=01 (N     ) | 2336: A9 9B             LDA #$9B
- 9088: 47: 11 | A=9B X=92 Y=01 (N     ) | 2338: 20 EC 24          JSR $24EC
    9088: 47: 17 | A=9B X=92 Y=01 (N     ) | 24EC: 2C EC 24          BIT $24EC
    9088: 47: 22 | A=9B X=92 Y=01 (      ) | 24EF: A2 00             LDX #$00
    9088: 47: 28 | A=9B X=00 Y=01 (    Z ) | 24F1: 0D 3E 2A          ORA $2A3E
    9088: 47: 44 | A=9B X=00 Y=01 (N     ) | 24F4: A8                TAY
    9088: 47: 52 | A=9B X=00 Y=9B (N     ) | 24F5: BD 47 03          LDA ICPTH,X  ;$0347
    9088: 47: 64 | A=FA X=00 Y=9B (N     ) | 24F8: 48                PHA
    9088: 47: 70 | A=FA X=00 Y=9B (N     ) | 24F9: BD 46 03          LDA ICPTL,X  ;$0346
    9088: 47: 78 | A=CA X=00 Y=9B (N     ) | 24FC: 48                PHA
    9088: 47: 84 | A=CA X=00 Y=9B (N     ) | 24FD: 98                TYA
    9088: 47: 88 | A=9B X=00 Y=9B (N     ) | 24FE: 60                RTS
    9088: 47:100 | A=9B X=00 Y=9B (N     ) | FACB: A4 57             LDY DINDEX
    9088: 47:103 | A=9B X=00 Y=00 (    Z ) | FACD: F0 0C             BEQ $FADB
  + 9088: 47:106 | A=9B X=00 Y=00 (    Z ) | FADB: 20 3C F9          JSR $F93C
  + 9088: 48:107 | A=9B X=00 Y=17 (N     ) | FADE: 20 EA F8          JSR $F8EA
    9088: 49: 60 | A=9B X=00 Y=00 (N     ) | FAE1: A8                TAY
    9088: 49: 64 | A=9B X=00 Y=9B (N     ) | FAE2: 0E A2 02          ASL ESCFLG
    9088: 49: 76 | A=9B X=00 Y=9B (    Z ) | FAE5: B0 1E             BCS $FB05
    9088: 49: 80 | A=9B X=00 Y=9B (    Z ) | FAE7: 29 1F             AND #$1F
    9088: 49: 84 | A=1B X=00 Y=9B (      ) | FAE9: C9 1B             CMP #$1B
    9088: 49: 88 | A=1B X=00 Y=9B (    ZC) | FAEB: 90 18             BCC $FB05
    9088: 49: 92 | A=1B X=00 Y=9B (    ZC) | FAED: A2 0E             LDX #$0E
    9088: 49: 96 | A=1B X=0E Y=9B (     C) | FAEF: 98                TYA
  + 9088: 49:100 | A=9B X=0E Y=9B (N    C) | FAF0: 20 CA FC          JSR $FCCA
    9088: 52: 62 | A=9B X=FF Y=9B (N    C) | FAF3: D0 10             BNE $FB05
    9088: 52: 70 | A=9B X=FF Y=9B (N    C) | FB05: 8C FB 02          STY ATACHR
  + 9088: 52: 78 | A=9B X=FF Y=9B (N    C) | FB08: 20 23 F6          JSR $F623
    9088: 58: 80 | A=80 X=BA Y=01 (      ) | FB0B: 4C B5 FD          JMP $FDB5
    9088: 58: 86 | A=80 X=BA Y=01 (      ) | FDB5: 84 64             STY ADRESS
    9088: 58: 92 | A=80 X=BA Y=01 (      ) | FDB7: 18                CLC
  + 9088: 58: 96 | A=80 X=BA Y=01 (      ) | FDB8: 20 41 F9          JSR $F941
    9088: 59: 11 | A=80 X=BA Y=01 (N     ) | FDBB: A4 64             LDY ADRESS
    9088: 59: 14 | A=80 X=BA Y=01 (      ) | FDBD: 60                RTS
  9088: 59: 20 | A=80 X=BA Y=01 (      ) | 233B: E8                INX
  9088: 59: 24 | A=80 X=BB Y=01 (N     ) | 233C: A9 06             LDA #$06
  9088: 59: 32 | A=06 X=BB Y=01 (      ) | 233E: 95 98             STA $98,X    ;$53

It happens to work on the XL/XE OS because that normally returns with X=0. However, this behavior is still broken, because the value actually returned depends on CRSINH, so the program still breaks and trashes OS zero page even on the XL/XE OS if the cursor is disabled. This is also highly likely to break if an alternate E: device is used, like the XEP-80 or S_VBXE drivers.

[JoSch]

 

This is due to a bug in the Mad Pascal output routine. The program is overwriting RMARGN with $01:

[..]

It happens to work on the XL/XE OS because that normally returns with X=0. However, this behavior is still broken, because the value actually returned depends on CRSINH, so the program still breaks and trashes OS zero page even on the XL/XE OS if the cursor is disabled. This is also highly likely to break if an alternate E: device is used, like the XEP-80 or S_VBXE drivers.

I thought, that it's possible that XL OS just makes a mistake itself. Thanks for clarifying that. I will tell Tebe.

Edited June 8, 2016 by JoSch

[tebe]

ok, i found the bug and killed him, (calling '@putchar #eol' is replaced by '@print #eol', @print save regX)

 

thx

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.80-test42.zip

http://www.virtualdub.org/beta/Altirra-2.80-test42-src.zip

 

Fixes a bug that fjc reported with SIDE2 drive removal reporting (incorrect state on device init).

 

Adds partial emulation of Happy 1050 drive functions when Happy drive emulation mode is selected. It is not enough to get backup/duplication support working as that unfortunately requires full drive emulation, but it does support Happy high speed operation (38400 baud), the quiet command, RAM read/write commands, and a couple of the tests. Enhancement test will run but fails the ROM check (because there is no ROM), RPM tester works, head positioning test works, read/write test won't work, tracer won't work, sector copier works, backup won't work, compactor won't work, multi drive won't work.

[serj]

Avery, you decided to break the record?

the maximum quantity of beta versions of the emulator (more than 41) quitted for 2.0 versions.

[atx4us]

I think he's OK now, since bit 0 being set causes the returned value not to match the (incorrect) one quoted in Mapping the Atari. As mentioned, it's not a ROM location but a GTIA register, so it doesn't matter which ROM is used.

Hi guys!

 

I've been messing around a little bit more with the VCOUNT register and I found an efficient way to get the maximum VCOUNT value. I was expecting a value of 130 for NTSC and 155 for PAL video systems. However, if I keep rerunning the program, I sometimes get 131 for NTSC and 156 for PAL video systems on the Altirra Emulator. How can this be? Can the number of video lines vary this way? (and even on a real computer?)

 

Thanks,

Hayden

 

Action! Program:

 

Proc Main()

Byte VCtr, VCount=$D40B ;54283

 

; NTSC = 130/131

; PAL = 155/156

;

Do

VCtr=VCount

Until VCount<VCtr Od

 

PrintBE(VCtr)