Altirra 3.90 released

[kenjennings]

15 minutes ago, phaeron said:

Double-checked on an 800XL that yes, you should see the text here.

 

The reason this happens is that hires graphics are special in GTIA: they bypass the priority and palette lookup circuits and go directly to the output logic at the end, where they switch the luminance between the normal output and PF1. The priority logic only works at color clock speed (160 resolution) and only sees PF2 for the hires playfield regardless of the individual pixels. The result is that nothing ever blocks the hires layer, it tunnels through anything and everything and stamps PF1 luminance wherever it is active.

 

As far as I know, Atari800 has also supported this effect forever -- at least as far back as Atari800WinPLus. If you aren't seeing it then either something weird is making the program run differently or you are using an old version of Atari800.

 

Ok, my own stupid programmers' trick.  THANKS.  ?    Solution is to remove the text when not needed.

 

I'm running atari800 4.2.0 on linux which is the last version I found on   https://github.com/atari800/atari800/releases

 

[drpeter]

Avery, I realise it may be something of a niche usage, but I wonder if you might consider implementing an option to emulate the GTIA quirk being discussed over on the 'Images Generated by RastaConverter' thread.

 

In a nutshell, on some real hardware, after it has warmed up for a variable period of time, the in-scanline delay between the trigger for GTIA preparing a player for display and the actual display of the left margin of said player is extended to one colour clock earlier, i.e. 6 colour clocks rather than 5.

 

As you know, Altirra currently emulates suppression of an attempt to display a player by completion of a write to HPOSPx within this 5 colour-clock window.

 

RastaConverter not infrequently throws up screen kernels that include a write which completes exactly 6 colour-clocks before the new player position.  In Altirra, display of the player at this new horizontal position will not be suppressed, but on many instances of 'warmed up' real hardware it will be, leading to artefacts in the RastaConverter image.

 

For those working with RastaConverter without access to the (probable majority) of real hardware that demonstrates this effect, there's currently no way of checking how their images will appear on all examples of real hardware.

 

Many thanks for considering this request.

[phaeron]

3 hours ago, drpeter said:

Avery, I realise it may be something of a niche usage, but I wonder if you might consider implementing an option to emulate the GTIA quirk being discussed over on the 'Images Generated by RastaConverter' thread.

 

In a nutshell, on some real hardware, after it has warmed up for a variable period of time, the in-scanline delay between the trigger for GTIA preparing a player for display and the actual display of the left margin of said player is extended to one colour clock earlier, i.e. 6 colour clocks rather than 5.

 

As you know, Altirra currently emulates suppression of an attempt to display a player by completion of a write to HPOSPx within this 5 colour-clock window.

 

RastaConverter not infrequently throws up screen kernels that include a write which completes exactly 6 colour-clocks before the new player position.  In Altirra, display of the player at this new horizontal position will not be suppressed, but on many instances of 'warmed up' real hardware it will be, leading to artefacts in the RastaConverter image.

 

For those working with RastaConverter without access to the (probable majority) of real hardware that demonstrates this effect, there's currently no way of checking how their images will appear on all examples of real hardware.

 

Many thanks for considering this request.

This is a tough one.

 

It's definitely the case that GTIA has some marginal timing that manifests as system-dependent and temperature dependent behavior like this. On my 800XL, no effects -- 20 mins later and neither the artifact test program nor the DGF test does anything. I _have_ seen effects like this on the 130XE, to the point of actually watching the effect noisily crawl up the screen as the timing threshold shifts gradually. But it's kind of hard to precisely pin down an issue that occurs randomly on one particular system, only in summer, around 15 minutes after power-up. In any cases that are ambiguous Altirra matches my 800XL, which has the more stable timings of the two computers.

 

For this particular case I'll have to check Acid800 as it extensively tests HPOSPx/SIZEPx/GRAFPx timing and I don't remember if it was one of the test cases that has a 1-cycle leeway. I don't think this was needed for HPOSPx even on the 130XE. PRIOR was one register where some changes had a 1cc delta, and I've seen color register changes happen 1cc late as well. One of the sticking points is whether the problem occurs prior to collision detection as that's observable by the running program; I'm guessing this should be pre-collision as the shift registers are prior to the priority logic and the artifacts are too long, but I'd need to repro this locally first hand to confirm.

 

Since the problem isn't actually specific to any computer model, probably the best I could think of would be to add an option for alternate GTIA timing, which would just flip all of the timings to the opposite end of the range. Been thinking of this for a while, but I can't say when it'd be implemented. In the meantime, there's really no way around this from the RastaConverter side other than to just blacklist any sequences that would be ambiguous.

 

[drpeter]

16 minutes ago, phaeron said:

the best I could think of would be to add an option for alternate GTIA timing, which would just flip all of the timings to the opposite end of the range

That's the kind of thing I was thinking of...

 

Thanks again.

[ijor]

On 5/24/2021 at 4:39 AM, phaeron said:

Since the problem isn't actually specific to any computer model, probably the best I could think of would be to add an option for alternate GTIA timing, which would just flip all of the timings to the opposite end of the range.

 

May be just for the record because not sure this changes much of the essence here ... Note that this doesn't depend entirely on GTIA. It is also affected by the clock skew. GTIA's internal logic is mostly synchronized to the clock directly coming from the oscillator or Freddie (F01 and F02 signals in the GTIA schematics). OTOH, all programmable registers (like PRIOR) are synchronized to the main system board phi2 clock (S2B signal). There is quite a long way from one clock to the other passing from GTIA, ANTIC, and some external logic, plus SALLY if present. This unavoidable produces some clock skew that is very relevant to these synchronization timing issues.

 

I don't know if somebody measured this clock skew and made statistics. But it might be slightly different across different models because the logic is slightly different, especially if SALLY is present or not. Probably, and this is not much more than just a guess, this difference is minor in comparison to temperature variations, though.

Edited May 27, 2021 by ijor

[VinsCool]

Hey there.

I think I accidentally found a POKEY audio bug that I first believed to be caused from something entirely different.
To make it simple, I noticed that playing audio with 16-bit precision with a simple instrument envelope cause the sound to skip frames of sound at random moment, and only when 16-bit audio was played.

This began a little while ago testing RMT2LZSS, a program by rensoup that converts Raster Music Tracker modules into executables with LZSS compression.

For the longest time, I believed there was a bug in that program, which would often lead to random audio skips, but I verified on real hardware tonight and noticed everything worked as expected.
Altirra, on the other hand, would always have audio skips at random moments, but only during 16-bit audio playback, specifically.

The first few frames of every 16-bit notes are likely to skip and output no sound at all, but this seems to be random, so I could not even predict or find a pattern from it.

Below I'll attach a recording from Altirra, and another from hardware, the executable I used that showed the behaviour, as well as a SAPR dump of the data that was converted.
The executable plays 2 patterns of nearly identical data, except one is running in 16-bit precision, and the other, 8-bit like normal.
Only the 16-bit section would exhibit the audio skips happening randomly in Altirra, while the hardware recording showed nothing as such.

Further specifications: I used a NTSC machine, and Altirra was running in NTSC too. The Altirra SAPR I got for debugging purpose runs in Altirra and also produce the same results-- random audio skips when the sound plays in 16-bit mode.
The hardware sound was recorded using Audacity with my USB audio input-output adapter, and I recorded the emulated sound from the built-in WAV recorder in Altirra, so I doubt the sound buffer may responsible of this.

I am not sure if this is caused by a configuration from my end, and if it is, I apologise for any potential false report.

I have good reasons to believe there may be something, because, again, everything was correct from a real machine.

Thank you  

 

Test 6.obx Test 6.sapr

[pmgraphics]

I just started using 3.90. In previous versions of Altirra I would often use save and load state. I almost never had an issue. In v3.90 I find the save state often crashes when loading it.

 

I'm using the x64 version playing jumpman, an atr file that I have used with other Altirra versions where the save state worked fine.

[phaeron]

2 hours ago, pmgraphics said:

I just started using 3.90. In previous versions of Altirra I would often use save and load state. I almost never had an issue. In v3.90 I find the save state often crashes when loading it.

 

I'm using the x64 version playing jumpman, an atr file that I have used with other Altirra versions where the save state worked fine.

There's a bug in the save state loading code for that version that I fixed in 4.00-test, so you shouldn't have this issue on the test version. I need to backport the fix -- 99% sure 3.91 is going to happen, but I need to set up the branch+build and cherry-pick fixes to go into it.

[pmgraphics]

3 hours ago, phaeron said:

There's a bug in the save state loading code for that version that I fixed in 4.00-test, so you shouldn't have this issue on the test version. I need to backport the fix -- 99% sure 3.91 is going to happen, but I need to set up the branch+build and cherry-pick fixes to go into it.

Is there a link to the 4.00-test? the link at the start of this thread doesn't work.

[phaeron]

1 hour ago, pmgraphics said:

Is there a link to the 4.00-test? the link at the start of this thread doesn't work.

You have to dig backwards from the end of the thread to find the latest test release:

https://atariage.com/forums/topic/308053-altirra-390-released/?do=findComment&comment=4804676

 

As for the links, they will not work clicking directly on them because this website is HTTPS and the target is HTTP; you'll have to manually open the link.

[pmgraphics]

47 minutes ago, phaeron said:

You have to dig backwards from the end of the thread to find the latest test release:

https://atariage.com/forums/topic/308053-altirra-390-released/?do=findComment&comment=4804676

 

As for the links, they will not work clicking directly on them because this website is HTTPS and the target is HTTP; you'll have to manually open the link.

Got it downloaded. Chrome blocked any access to the link. I used old IE.

[glurk]

I have an Altirra / debugging question, maybe it's a feature request?  I don't know.

 

Is there any way, using the debugger, to get a "bitmap" display of a program's memory use?   Don't care about the actual byte values, etc...  Just want to get a quick birds-eye view of what RAM is being used, and what is maybe not being used at all.  Because I have a 48K 800, and I'm pretty certain that some programs are using high XE/XL RAM "just because" and are leaving whole pages of lower RAM unused.

 

I know this can be done with breakpoints and etc.  But I'm hoping for something quick and easy, like a simple bitmap display of a memory map.   Nothing complex and (maybe?) easy to implement?  I don't know.  It's certainly possible something like this is already there and I just don't know about it.  So, I'm just asking for anyone who might know.

[Wrathchild]

4 minutes ago, glurk said:

But I'm hoping for something quick and easy

Use the help commands to examine the heat map options

[pmgraphics]

19 hours ago, phaeron said:

There's a bug in the save state loading code for that version that I fixed in 4.00-test, so you shouldn't have this issue on the test version. I need to backport the fix -- 99% sure 3.91 is going to happen, but I need to set up the branch+build and cherry-pick fixes to go into it.

I test 4.00-test with save states, and after about 15-20 save states, the last save state that I made crashes when I load it. The issue still exists, it's just not has prominent as in 3.90. The emulator is locked up with a blue tint overlaying the display.

[phaeron]

15 minutes ago, pmgraphics said:

I test 4.00-test with save states, and after about 15-20 save states, the last save state that I made crashes when I load it. The issue still exists, it's just not has prominent as in 3.90. The emulator is locked up with a blue tint overlaying the display.

That's a different issue, that's an in-emulation crash. What medium are you running Jumpman from (disk, cart...)?

[pmgraphics]

I'm running jumpman from an ATR file attached to disk1

[Mclaneinc]

@pmgraphics You can use Chrome to get the files, right click on the link and choose Open in Incognito Window

Edited May 31, 2021 by Mclaneinc

[phaeron]

It's been a while.

 

http://www.virtualdub.org/beta/Altirra-4.00-test35.zip

http://www.virtualdub.org/beta/Altirra-4.00-test35-src.7z

• Debugger: Add 'dbx' command to display an expression as a block of bytes (useful for decoding memory through an expression); fixed focus issue with address box and actually implemented history drop-down.
• XEP80: Fixed fill EOL command using $1B instead of $9B.
• R-Time 8: Fixed bug where debugger reads could change device state.
• Happy 810: Fixed a bug with RAM mirroring; added some firmware image detection.
• Modem: Fix for an infinite loop on an attempt to hang up with unread data after the remote side had already shut down its side of the connection; don't wait for received data to drain if remote closes while modem is still ringing. Thanks to Triads for helping me track these down and getting me the memory dump that showed what was happening.
• Cassette: Fixed toggle buttons in Tape Control not showing their state in dark mode; added /tapepos switch; fixed broken load progress bar when loading CAS files (this was hard to see, except for a huge tape in debug builds).
• 5200: Block bogus Shift/Ctrl button states which were leaking through.
• Release script rewritten in Python -- log is much cleaner, program is now version stamped for test builds with test# and build number, .exe is auto-checked for Windows 7 compatibility, and 100% less batch file.
• Source archive format switched from .zip to .7z (7-zip) for much better compression. Binary releases will continue to be .zip for now.

Now, just to warn -- there may be some bugs lurking in tape support, because I did a major rewrite of it to support this:

 

 

This tape image is from An Introduction To Programming, which is one of the Atari-published educational tapes that has a program-controlled speech track. Above you can see the end of the standard 600 baud, 128-byte blocks containing the BASIC program, followed by the pulses used by that program to sync the visuals against the audio.

 

The Tape Editor is intended to support two main use cases: being able to make small edits to a tape image for diagnostic purposes, and as a debugging aid. To support this, the tape image code was written to have a proper piece table to support copy/paste and undo/redo. To be clear, it's not recommended that you actually try to save tapes out of this editor for a couple of reasons: there is no tape format that saves all of the information from Altirra's internal tape format, and the editor is missing some critical functions like being able to remark blocks as decoded data for the CAS format. Thus, you can't really make useful CAS files with this yet, and roundtripping through  a wave file is not guaranteed for data (and will lose audio). The intent is to be able to debug turbo tapes with this, though, so I'll be adding some more functionality to it. I don't expect it to be a primary tool for authoring tapes, though, as a specialized tool like Turgen System is more appropriate for that.

 

[dely]

Wonderful news. Can't wait for full featured Tape Editor! Thanks.

[+gnusto]

14 hours ago, phaeron said:

added /tapepos switch

 

Huzzah! Thanks Phaeron. Now I can insta-load from all those popular multi title euro cassettes.

[jindroush]

Curious problem:
I'm salvaging the dumps of czech translation of Neverending Story game. While translating, the original translator made a bug which made game impossible to finish. I have two different dumps of the game, both having the same problem - one is the diskette dump (loading from ATR), the other one Turbo 2000 dump (loading from WAVs)

To get to the problematic place in game, I have all the necessary game commands stored in text file and I can ALT-SHIFT-V paste them to the game, and then F1 to get to the place.

I did this with 3.20 and ATR version, it works as expected.
But with TURBO version, it seems to drop keystrokes randomly.
Downloaded 3.90, same problem.
In 3.20 I tried to play with Configure System / Keyboard but to no avail.

Is there any explanation why this may happen? In fact I suspect that something may be different with keyboard setup (POKEY registers?) being in different initial state after SIO / Turbo.
This is nothing extra important but it's just puzzling me why this would happen at all.

[Mr Robot]

46 minutes ago, jindroush said:

...

Now there's a name I've not seen for a while!

 

[phaeron]

3 hours ago, jindroush said:

I did this with 3.20 and ATR version, it works as expected.
But with TURBO version, it seems to drop keystrokes randomly.
Downloaded 3.90, same problem.
In 3.20 I tried to play with Configure System / Keyboard but to no avail.

Is there any explanation why this may happen? In fact I suspect that something may be different with keyboard setup (POKEY registers?) being in different initial state after SIO / Turbo.
This is nothing extra important but it's just puzzling me why this would happen at all.

 

The paste function uses heuristics to determine when it is safe to push new keys to the emulated system, since there is no direct way to tell if the OS is ready for another key. These include checking the CH and KEYDEL variables as well as monitoring for speaker activity. If the OS keyboard handler is no longer being used then these heuristics may fail and depend on what is in those memory locations; there is a limit timer to prevent it from stopping entirely but it may end up pushing keys too quickly for the program to handle, as fast as 1/frame. The difference between the ATR and the turbo tape version may relate to what is in those memory locations.

 

[+MrFish]

3 hours ago, Mr Robot said:

Now there's a name I've not seen for a while!

 

 

[jindroush]

10 hours ago, phaeron said:

 

The paste function uses heuristics to determine when it is safe to push new keys to the emulated system, since there is no direct way to tell if the OS is ready for another key. These include checking the CH and KEYDEL variables as well as monitoring for speaker activity. If the OS keyboard handler is no longer being used then these heuristics may fail and depend on what is in those memory locations; there is a limit timer to prevent it from stopping entirely but it may end up pushing keys too quickly for the program to handle, as fast as 1/frame. The difference between the ATR and the turbo tape version may relate to what is in those memory locations.

 

Hrm, I checked the game, both versions do this:
 

    8ED8: A9 DA             LDA #$DA
    8EDA: 8D 08 02          STA VKEYBD
    8EDD: A9 8D             LDA #$8D
    8EDF: 8D 09 02          STA VKEYBD+1


    8DDA: 8A                TXA
    8DDB: 48                PHA
    8DDC: A5 0A             LDA DOSVEC
    8DDE: 10 1B             BPL $8DFB
    8DE0: A5 0C             LDA DOSINI
    8DE2: D0 17             BNE $8DFB
    8DE4: AD 0F D2          LDA SKSTAT
    8DE7: 29 20             AND #$20
    8DE9: F0 10             BEQ $8DFB
    8DEB: A9 04             LDA #$04
    8DED: 85 0C             STA DOSINI
    8DEF: AE 09 D2          LDX KBCODE
    8DF2: 30 07             BMI $8DFB
    8DF4: BD FF 8D          LDA $8DFF,X
    8DF7: 30 02             BMI $8DFB
    8DF9: 85 0A             STA DOSVEC
    8DFB: 68                PLA
    8DFC: AA                TAX
    8DFD: 68                PLA
    8DFE: 40                RTI

Note that DOSVEC and DOSINI are just labels and are not used for their original use.
So this is clearly their own code which directly touches POKEY registers - but for some reason while pushing keystrokes for ATR version Altirra does it much slower (visibly) than for the turbo version. Is there any recommendation what can I do (some Altirra setting or something), or just "use the source, Luke"?