Jump to content
IGNORED

Altirra 4.10 released


phaeron

Recommended Posts

9 hours ago, phaeron said:

If anyone knows how a PAL receiver reacts hue-wise to a swinging colorburst that isn't aligned to +/-45 degrees, I'd be interested.

First of all, it is important to emphasize that the first broadcast television system -- NTSC -- laid the foundation for PAL.
It should be remembered that in both NTSC & PAL, two consecutive lines have the same colour.
Unlike NTSC, the PAL colour burst signal has a defined phase that alternates between 135° and 225°.


Apart from their natural frequencies and the alternating phase, these systems do not differ in anything.

With PAL, a shift in phase will result in a little more R-Y on one line and a little less R-Y on the next line.
(note that same logic applies to B-Y).
The human eye will not be able to make the difference and an average colour that corresponds to the original PAL vector will be visible (unlike NTSC)

Link to comment
Share on other sites

4 hours ago, Stephen said:

I can assist with some test code - can you provide any details about this issue, or a link to an example perhaps?

Looks like possibly a timing issue causing bleed-through, the artifacts are smaller than GTIA hires pixels.

 

3 hours ago, ldelsarte said:

First of all, it is important to emphasize that the first broadcast television system -- NTSC -- laid the foundation for PAL.
It should be remembered that in both NTSC & PAL, two consecutive lines have the same colour.
Unlike NTSC, the PAL colour burst signal has a defined phase that alternates between 135° and 225°.


Apart from their natural frequencies and the alternating phase, these systems do not differ in anything.

With PAL, a shift in phase will result in a little more R-Y on one line and a little less R-Y on the next line.
(note that same logic applies to B-Y).
The human eye will not be able to make the difference and an average colour that corresponds to the original PAL vector will be visible (unlike NTSC)

Yes, but the issue is what happens when the phase doesn't alternate between 135° and 225°, but different angles with more or less phase separation. The PAL GTIA is imperfect in its phase generation depending on the color pot adjustment, and quite a lot of systems seem to be detuned for aesthetic reasons from the ideal phase angles.

 

  • Thanks 1
Link to comment
Share on other sites

On 2/6/2023 at 9:53 PM, phaeron said:

Yes, but the issue is what happens when the phase doesn't alternate between 135° and 225°, but different angles with more or less phase separation. The PAL GTIA is imperfect in its phase generation depending on the color pot adjustment, and quite a lot of systems seem to be detuned for aesthetic reasons from the ideal phase angles.

Some tests are needed and I want to give you a factual, correct answer. More on this when I test with a PAL computer and its colour pot adjustment.

To be continued...

Link to comment
Share on other sites

@phaeron me back on A8 coding... now I run into "settings" issue and might be my old age... but it seems Altirra saves settings automaticly by closing (video settings e.g.) but Audio? each time I open Altirra I need to set the downmix flag in the configure system --> audio settings when system is set to "stereo". is that intentional? me using 4.10

 

 

Link to comment
Share on other sites

22 minutes ago, Heaven/TQA said:

@phaeron me back on A8 coding... now I run into "settings" issue and might be my old age... but it seems Altirra saves settings automaticly by closing (video settings e.g.) but Audio? each time I open Altirra I need to set the downmix flag in the configure system --> audio settings when system is set to "stereo". is that intentional? me using 4.10

No, it's a bug.

Link to comment
Share on other sites

Is it possible to emulate APE or RespeQt with Altirra?  I've looked through all the settings that I could find, and nothing looked promising.  The only difference (I think) between these and high-speed Happy drives that operate in a cycle-correct manner is the lack of track-switching latency and the ultimate SIO speed selection potential.  Just curious.  I got a new laptop for Xmas, and I'm using Altirra a lot more (from my recliner!). 😉

 

Edit: Actually, both APE and RespeQt do a lot more than just emulate disk drives, but my question is just about the disk R/W operations -- sort of a generic SIO2PC.

Link to comment
Share on other sites

Altirra is already an Atari Peripheral Emulator in just about every Aspect, respectfully. That being said... I guess you are correct in that the SIO2PC devices and their backends/frontends are a kind of peripheral in and of themselves.

Edited by _The Doctor__
Link to comment
Share on other sites

2 hours ago, Larry said:

Is it possible to emulate APE or RespeQt with Altirra?  I've looked through all the settings that I could find, and nothing looked promising.  The only difference (I think) between these and high-speed Happy drives that operate in a cycle-correct manner is the lack of track-switching latency and the ultimate SIO speed selection potential.  Just curious.  I got a new laptop for Xmas, and I'm using Altirra a lot more (from my recliner!). 😉

 

Edit: Actually, both APE and RespeQt do a lot more than just emulate disk drives, but my question is just about the disk R/W operations -- sort of a generic SIO2PC.

If you mean emulating the drive emulators of APE and RespeQt for use in Altirra, there isn't much point. The built-in standard drive emulation is basically the same thing.

 

If you mean being able to use Altirra's drive emulation with a real Atari, that's difficult because of timing issues. Within Altirra, emulation timing is fully deterministic and everything can be precisely controlled. Across a serial port link, though, timing is a lot more critical and USB serial adapters in particular have terrible timing characteristics. One problem I found the last time I looked into this is that you're not even guaranteed that control signal events are synchronized with data bytes, so it is possible for the serial port driver to return the first byte of a command frame before reporting that the SIO command line has been asserted. This requires various workarounds that don't work very well with Altirra's internal architecture. The full drive emulation is even worse, as it requires sub-millisecond timing accuracy which is even more impractical.

 

  • Thanks 1
Link to comment
Share on other sites

32 minutes ago, Larry said:

"If you mean emulating the drive emulators of APE and RespeQt for use in Altirra, there isn't much point. The built-in standard drive emulation is basically the same thing."

 

Thanks.  No, not to use with a real Atari.    

You want to write out to a real disk drive from Altirra like SIOto1050 or ProSystem got it, that would be nice...

Edited by _The Doctor__
Link to comment
Share on other sites

4.20-test2, the debugger:

 

1) when resolving the PEI instruction, the console considers the indicated zero-page location as a pointer and dereferences it:

 

image.thumb.png.042b2bd7063752ef05a9ac02b37ea8f9.png

But PEI does not work so, in this case the value being pushed to the stack is $0002, and not $00FF, showing the latter lacks sense.

 

It is only the display thing, the instruction itself works correctly.

 

2) in the same circumstances, but with the RMW instructions, could the console show the value which the instruction, when executed, will load from the memory? Like here:

 

image.thumb.png.594d5550ed1935aef5641db113aa2e3b.png

I.e. if $00:$01F8 is $FFFF before INC, could it display "INC $14     [$00:01F8] = $FFFF"? Same for DEC, ASL, LSR, TRB, TSB and such, of course.

 

Thanks in advance.

Link to comment
Share on other sites

https://www.virtualdub.org/beta/Altirra-4.20-test3.zip
https://www.virtualdub.org/beta/Altirra-4.20-test3-src.7z

  • Display pan/zoom capability added.
  • Fixed some bugs in the D3D11 display path with GPUs that require power of two sized textures.
  • Fixed stereo-as-mono setting not saving.

Display pan/zoom lets you pan and zoom the display to any desired placement. It's independent of the existing sizing settings, but lets you manually offset the screen or zoom in very close on a selected part. It can be accessed either from View > View Frame > Pan/Zoom Tool, or by Alt+MMB drag for pan and Alt+Wheel for zoom. The direct controls are on Alt to prevent accidental zoom, especially with a trackpad.

 

On 2/17/2023 at 1:36 AM, drac030 said:

4.20-test2, the debugger:

 

1) when resolving the PEI instruction, the console considers the indicated zero-page location as a pointer and dereferences it:

 

But PEI does not work so, in this case the value being pushed to the stack is $0002, and not $00FF, showing the latter lacks sense.

I'll fix this, agreed that deferencing makes no sense. I could make it display the value pushed instead.

 

On 2/17/2023 at 1:36 AM, drac030 said:

2) in the same circumstances, but with the RMW instructions, could the console show the value which the instruction, when executed, will load from the memory? Like here:

 

I.e. if $00:$01F8 is $FFFF before INC, could it display "INC $14     [$00:01F8] = $FFFF"? Same for DEC, ASL, LSR, TRB, TSB and such, of course.

This unfortunately is more difficult as the CPU history stream doesn't contain the read values, it only contains the effective address. The deferenced values shown are generated by the disassembler, which is why history doesn't show it.

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

On 2/19/2023 at 7:43 AM, phaeron said:

PEI (dp) no longer shows deref value.

Thanks. Now it displays this:

 

image.thumb.png.d3696f34d9a1692c24d731380be20a70.png

The word pushed onto the stack is displayed, but what I am missing here is the effective address. Could it display something along "PEI ($85)  [$00:0085] = $0003" instead? It is the dp addressing mode, so the effective address, being dependent on the value of the D register, is not very obvious.

 

On 2/19/2023 at 1:46 AM, phaeron said:

This unfortunately is more difficult as the CPU history stream doesn't contain the read values, it only contains the effective address. The deferenced values shown are generated by the disassembler, which is why history doesn't show it.

I am not sure if I can quite follow here. You are saying that the history stream is one instruction ahead of the user, so the console window fetches the values from there before the user executed an instruction? If so, how does it work for PEI then?

 

For other things, there seems to be a problem with the debugger's command "o" (Step over). I asked once if it is possible that it could "step over" the MVN/MVP instructions, and you implemented it. But it does not seem to always work (or maybe in the test4 is stopped working at all, it just tried and it did not). Could you take a look at that? It is rather long to step through longer moves (yes, I can set a breakpoint after and let it go).

 

Also, would you like to implement a new command in the debugger, something like "go until change of flow", i.e. until a jump (jsr, jmp, jsl, jml), return from subroutine (rts, rtl) or branch taken?

 

EDIT: I also no not quite get the logic according to which the debugger disassembly window displays labels for zero-page locations. Like for LDA $08 it displays LDA WARMST, but when D != 0, the effective address is no longer $00:0008 or WARMST, so the debugger should not display the label but rather the numeric value of the argument instead. And it sometimes seems to do so, but sometimes it does not. Could you take a look at that?

 

image.thumb.png.bec6ba67708d2503b2dfe936b754cf90.png

 

Thanks in advance.

Edited by drac030
Link to comment
Share on other sites

59 minutes ago, drac030 said:

Thanks. Now it displays this:

 

image.thumb.png.d3696f34d9a1692c24d731380be20a70.png

The word pushed onto the stack is displayed, but what I am missing here is the effective address. Could it display something along "PEI ($85)  [$00:0085] = $0003" instead? It is the dp addressing mode, so the effective address, being dependent on the value of the D register, is not very obvious.

Alright, I'll get that change in. Needs a little more special casing in the disassembler.

 

59 minutes ago, drac030 said:

I am not sure if I can quite follow here. You are saying that the history stream is one instruction ahead of the user, so the console window fetches the values from there before the user executed an instruction? If so, how does it work for PEI then?

No, that's not the issue. The issue is that the history stream doesn't contain the necessary information and there isn't room in the history stream for it. The history stream contains the register state, the opcode bytes, and for indirect instructions, the effective address. The effective address is only included for indirect ops because for direct ops it can be computed from the instruction and the register state, i.e. LDA $0104,X with X=$10 gives $0110. Indirect addressing also requires knowing the address that was read from memory. But in order to provide the previous state for a memory op like INC, the data read from memory also has to be stored in the history stream. The history frame is currently full and doesn't have room for another 16-bit data field.

 

To give you an idea, the history frame contains: machine cycle, unhalted cycle, effective address, A/X/Y/S/P/PC, interrupt and sub-cycle state, the instruction, B/XH/YH/SH, B, K, and D. This is actually already overcommitted for 65C816; because of the lack of space, the 65C816 frame doesn't contain the extended instruction address, so per-bank cartridge debugging doesn't work in 65C816 mode.

 

59 minutes ago, drac030 said:

For other things, there seems to be a problem with the debugger's command "o" (Step over). I asked once if it is possible that it could "step over" the MVN/MVP instructions, and you implemented it. But it does not seem to always work (or maybe in the test4 is stopped working at all, it just tried and it did not). Could you take a look at that? It is rather long to step through longer moves (yes, I can set a breakpoint after and let it go).

Just tried it here and was able to step over MVN 0,0 even with interrupts. What are you seeing in your case, is it executing only one round or is it doing more before stopping?

 

59 minutes ago, drac030 said:

Also, would you like to implement a new command in the debugger, something like "go until change of flow", i.e. until a jump (jsr, jmp, jsl, jml), return from subroutine (rts, rtl) or branch taken?

I think I can do that, it'd have to single-step every instruction looking for a control flow instruction at the same stack level or above, but that shouldn't be an issue.

 

59 minutes ago, drac030 said:

EDIT: I also no not quite get the logic according to which the debugger disassembly window displays labels for zero-page locations. Like for LDA $08 it displays LDA WARMST, but when D != 0, the effective address is no longer $00:0008 or WARMST, so the debugger should not display the label but rather the numeric value of the argument instead. And it sometimes seems to do so, but sometimes it does not. Could you take a look at that?

 

image.thumb.png.bec6ba67708d2503b2dfe936b754cf90.png

The issue is the difference between disassembly with static and dynamic state.

 

The disassembly window disassembles using static state since it cannot know the full CPU state at each instruction, so it simply sees LDA dp and decodes the reference as a symbol assuming D=0. The places where the debugger is showing the next instruction -- the console and the bottom entry in the history window -- are able to use the current actual state, including the D register. In this case the disassembler suppresses symbol loop if the D register is non-zero. This is similar to how the debugger can only show the predicted dereference result for the preview instruction, because it also is based on the current memory state.

 

I could potentially have the disassembly monitor the current D state and refresh the disassembly whenever it changes between zero and non-zero. It would cause the entire disassembly window to flip whenever D was changed between those values, but given code like your case where D is being used as a frame pointer, it would not be returning to 0 frequently anyway. Predicting D as for M/X is probably too much given the ways that it can be updated, but probably not really needed either.

 

  • Like 1
Link to comment
Share on other sites

For a personal website, I created some videos with Altirra recently. It's perfect, without technical complications and really handy to illustrate a technical point with a nice video. But I thought to myself: you can't hear the keys! What a pity! Quel dommage !

 

Hence a suggestion for a future version of Altirra: would it be possible to add - as an option & with a separate volume control - the noise of the keys (keyboard, switches) produced by a real computer?

As a test, I quickly recorded with my iPhone the noise produced by a 800XL with an ALPS keyboard (the best of the five keyboards available). There is no need to use hundreds of audio files. For each model of computer requiring a unique set of sound samples, you have to take the variation with the best keyboard, that's all. Who wants to hear the sound of bad keyboards?

 

For computers, separate sound samples are required for:

  • Atari 400 (yes, that membrane thing is a keyboard)
  • Atari 800
  • Atari 1200XL (probably the best keyboard, BTW)
  • Atari 600XL/800XL (the same set of sounds)
  • Atari 65XE/130XE/800XE (the same set of sounds)
  • Atari XEgs

 

For keys & switches, separate sound samples are required for:

  • Power on switch
  • Standard keyboard keys (same sound for all of them)
  • Space
  • Return
  • Tab
  • Shift
  • Help/Start/Select/Option (same sound for all of them)
  • Reset
  • Keys specific to the Atari 1200XL (F1, Invert/ex-Atari, etc…)

 

If the idea is accepted, I can easily provide all the necessary sound sample files. I have a good quality Tascam audio recorder & all the necessary Atari computer models.

Sounds of Atari 800XL with ALPS keyboard.flac

  • Thanks 1
Link to comment
Share on other sites

6 hours ago, phaeron said:

The history frame is currently full and doesn't have room for another 16-bit data field.

I see. Well, so we will have to live with it as it is, I guess.

 

6 hours ago, phaeron said:

Just tried it here and was able to step over MVN 0,0 even with interrupts. What are you seeing in your case, is it executing only one round or is it doing more before stopping?

It behaves as if I was pressing 't', i.e. stops after every iteration:

 

Quote

Altirra> o
(1222: 46, 51) A=31F3 X=4C3E Y=865F S=01E3 P=01 (       C)  3F:136F: 8B                PHB
              B=3F D=01E4
Altirra> o
(1222: 46, 51) A=31F3 X=4C3E Y=865F S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=3F D=01E4
Altirra> o
(1222: 46, 51) A=31F2 X=4C3D Y=865E S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 52) A=31F1 X=4C3C Y=865D S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 53) A=31F0 X=4C3B Y=865C S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 53) A=31EF X=4C3A Y=865B S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 54) A=31EE X=4C39 Y=865A S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 54) A=31ED X=4C38 Y=8659 S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 55) A=31EC X=4C37 Y=8658 S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4
Altirra> o
(1222: 46, 56) A=31EB X=4C36 Y=8657 S=01E2 P=01 (       C)  3F:1370: 44 22 1E          MVP $1E,$22
              B=22 D=01E4

Interrupts are on.

6 hours ago, phaeron said:

I could potentially have the disassembly monitor the current D state and refresh the disassembly whenever it changes between zero and non-zero.

The point is that, as I wrote, it sometimes does (or did in the previous Altirra revision I had here) that automatically. In meantime, I discovered that when I refresh the disassembly window, it shows the symbols for D=0 and numeric offsets for D!=0.

 

Before manual refresh:

image.png.c633e3803b74f3c89692d26aa6331228.png

After manual refresh:

 

image.png.f2760259b7232ad7982f846f4d1b3948.png

(It is exact same code still stopped in the same place, just the window was drawn again).

 

So it seems that the only thing missing is the automatic redraw of the disassembly window once D changes.

 

Edited by drac030
Link to comment
Share on other sites

https://www.virtualdub.org/beta/Altirra-4.20-test5.zip
https://www.virtualdub.org/beta/Altirra-4.20-test5-src.7z

  • Debugger: (dp), (dp,X), and (dp),Y addressing modes now also suppress symbol lookup for non-zero D register, and there is now an option in the Disassembly window to control this behavior.
  • Horizontal and vertical mouse scrolling can now be bound in input maps. In particular, this allows two-finger panning on Precision Touchpads for uses like paddles.
  • Corrected the input map generator not binding mouse inputs for some light pen/gun types.
  • Added an option to draw touch points for pad/gun controls. In particular, this allows seeing the current touch point when driving such a control with a non-mouse input or when multi-touch input is involved.
  • Added emulation support for the Chalk Board PowerPad controller.

The PowerPad controller is an interesting controller. It is natively a multi-touch controller, which poses challenges for emulating it with standard input methods. Micro Illustrator is particularly unusable without it as it requires a minimum of two touches to use, one to set the current position and another to activate. To support this, the emulator supports pre-setting a secondary touch and activating it via a second button. With the default mouse-mapped input map, this is done by setting the contact point and radius with the middle mouse button and then activating it with the right mouse button. With the default gamepad mapping, up to four multitouch points are supported, with those points changed when pressing the appropriate button with left trigger (LT) held. Right trigger (RT) is mapped the same as the primary touch button for convenience.

 

The timing of PowerPad reads is currently untuned and currently instant, as I have no information as to how long the matrix scans actually take. The delays that appear are in the software, to avoid running afoul of the impedance-related signal limits on the controller port. A quirk of the PowerPad is that reading the pad slows down as the contact areas grow bigger, since it takes longer for the scan to return every individual contact switch to the computer. Every point is currently returned to the computer, as there isn't a mention in the docs of point filtering/coalescing. This means that in Micro Illustrator, drawing will be more responsive as the touch point is shrunk (mouse wheel). The default radius is about a finger width.

 

There are a few additional changes that I'm considering that haven't made it in yet. One is altering the default pad area to be square and configurable. Currently it is always mapped to the window, which is often non-square -- thus the contact oval that you will see right now until the window is adjusted. Combined with the previous changes to allow the display to be arbitrarily positioned, this would allow for more natural arrangement of the pad area vs. the display. The other change is support for actual multi-touch input for those with touch screens. Altirra currently has multi-touch support, but it isn't plumbed all the way through to be usable for PowerPad emulation yet.

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

On 2/20/2023 at 11:27 AM, ldelsarte said:

Hence a suggestion for a future version of Altirra: would it be possible to add - as an option & with a separate volume control - the noise of the keys (keyboard, switches) produced by a real computer?

Dear @phaeron,
Can I respectfully ask what you think about my suggestion (see previous message, above) to add actual keyboard sounds in Altirra?
Thank you

  • Like 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...