Altirra 4.00 released

[phaeron]

17 hours ago, AtariGeezer said:

I have a possible feature request that others might like:

  How about Computer-Eyes?

 

A user could select a Video Source from a WebCam or other source, downscale a snap shot to an A8 graphics screen format using a grayscale or other skin tone color or cartoon-ish appearance and be able to save it to a picture file (A8/PC format).

Hardware info for the ComputerEyes device seems to be nonexistent, although it might be possible to RE the software, based on what I've seen of it so far.

 

There are two issues with using a live source:

• From past experience, the video capture API and capture drivers on Windows are broken AF.
• ComputerEyes is very slow at digitizing an image. Like the Digi-View, it works by sampling one column of pixels per frame, but additionally in order to take a multi-level image it has to sample the image at incremental thresholds. This means that a monochrome image takes 6 seconds and an 8-level image takes 40 seconds. Running this off of a live input isn't going to work well unless the source is a still image.

 

[Keatah]

What about using a JPG, BMP, or PNG as source input?

 

The hardest part (I assume) would be capturing the "flavour" of a ComputerEyes image. Artifacts, errors, interpolations, and stuff..

Edited May 8, 2022 by Keatah

[scotty]

I had ComputerEyes for the A8 way back in the day.  Had the Parrot to do audio as well.  WHen I later went to the Amiga, I got that table that had the camera looking down, and a 3 color wheel where you had to take 3 seperate pics of your item.  It was pretty cool, but I forget the name of it.  Pretty expensive back then.

 

[Mclaneinc]

At Maplin, we did a digitiser kit that scanned in and made a graphics 9 output, was very basic but fun.

[AtariGeezer]

10 hours ago, phaeron said:

Hardware info for the ComputerEyes device seems to be nonexistent, although it might be possible to RE the software, based on what I've seen of it so far.

If you need a schematic of one, I can whip one up in a few days from an original board...

[FULS]

Hi,

Out of curiosity, is it possible to hook the ComputerEyes device into two "2600-daptor ll" adapters and use it with Altirra?

One possible benefit would be turning on turbo mode of Altirra and the capture time would not take so long.

 

[Mclaneinc]

1 hour ago, AtariGeezer said:

If you need a schematic of one, I can whip one up in a few days from an original board...

Would help Avery...If you have time.

[AtariGeezer]

1 hour ago, AtariGeezer said:

If you need a schematic of one, I can whip one up in a few days from an original board...

Found one on Mathy's site: https://www.mathyvannisselroy.nl/computereyes.pdf

I'll compare it to mine to see if there are any differences.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.10-test12.zip
https://www.virtualdub.org/beta/Altirra-4.10-test12-src.7z

• Adds initial support for the ComputerEyes Video Acquisition System.
• Fixes H6-H9: not supporting append mode.
• Fixes very long delays or garbled instruction readouts when toggling the collapse modes in the history pane.

The ComputerEyes device needs a composite video input, of which there is currently one sub-device that sends a static test image. If no video device is attached, then the CE will act as with no video signal (no sync). The ComputerEyes device digitizes one column per threshold per frame, so an 8-level image will take 43 seconds to capture. It is capable of 16-level capture but you need V2.0 of the software to do it. Theoretically, VBXE would be able to display 320x240x16 grayscale from this.

 

A quirk of the CE software is that the bi-level Normal mode uses the maximum threshold, so the brightness needs to be adjusted up for multi-level and down for bi-level. I don't know why they didn't use mid-level threshold for bi-level.

 

21 hours ago, Keatah said:

What about using a JPG, BMP, or PNG as source input?

 

The hardest part (I assume) would be capturing the "flavour" of a ComputerEyes image. Artifacts, errors, interpolations, and stuff..

Image input would work fine, yeah. Character of the image is hard to emulate without seeing the device in action, though with the low resolution it likely doesn't matter much.

 

9 hours ago, FULS said:

Out of curiosity, is it possible to hook the ComputerEyes device into two "2600-daptor ll" adapters and use it with Altirra?

One possible benefit would be turning on turbo mode of Altirra and the capture time would not take so long.

No, USB controllers do not have nearly a high enough reporting rate. HID input devices typically report somewhere between 125Hz and 1KHz, and ComputerEyes needs a 15.7KHz reporting rate to work. The emulator also is not built to handle this kind of rate with real hardware since the performance hit of running the emulation that precisely against real time would be huge.

 

8 hours ago, AtariGeezer said:

Found one on Mathy's site: https://www.mathyvannisselroy.nl/computereyes.pdf

I'll compare it to mine to see if there are any differences.

That's really helpful and confirms some things that I had suspected from RE'ing the software, particularly that there is indeed a one-shot to stretch horizontal sync pulses since 4.7µs is too fast for the CPU to catch. It also confirms some differences from the Apple II version, for which driver source is available and runs the CPU synchronously to the capture instead of asynchronously.

 

One thing in particular to confirm: which variable resistors in the schematic correspond to which controls. There are three pots in the schematic (VR1-VR3) but there are only two control knobs on the unit, one for Sync and the other for Brightness. I wonder if one of the knobs drives two pots or if one of them is an internal adjustment.

 

[Keatah]

4 hours ago, phaeron said:

mage input would work fine, yeah. Character of the image is hard to emulate without seeing the device in action, though with the low resolution it likely doesn't matter much.

I would guess the dithering patterns are important.

 

FWIW: There've been several jpg/bmp to Apple II Hi-Res converters done over the years. And each one gives different outputs. With sampling size or number of pixels being adjustable as well as the threshold of when an input pixel becomes a recorded/digitized pixel. And of course each program had multiple dithering algorithms to choose from.

 

I suppose dithering is more important on Apple II because of limited colors. And what colors can be placed next to each other is a big deal.

 

I know nothing of ComputerEyes on other platforms. But I recall the 1st Apple II version working through the analog joystick game port. It had knobs for sync and brightness.

[flashjazzcat]

I'm getting $C8 in KBCODE for SHIFT+CTRL+0 (numeral zero) instead of the expected $F2. Tried different keyboard scan modes (I usually use 'raw') but can't figure out what's up, or whether it's something to do with the keyboard itself (I tried two, both Logitech). The same code works on a real Atari and reacts to SHIFT+CTRL+0.

[phaeron]

4 hours ago, flashjazzcat said:

I'm getting $C8 in KBCODE for SHIFT+CTRL+0 (numeral zero) instead of the expected $F2. Tried different keyboard scan modes (I usually use 'raw') but can't figure out what's up, or whether it's something to do with the keyboard itself (I tried two, both Logitech). The same code works on a real Atari and reacts to SHIFT+CTRL+0.

This is likely due to an annoying default in Windows where Ctrl+Shift+0 is by default bound to a key to switch between input languages. It appears that on Windows 10, this can cause the emulator to only receive the character event without the key down event, resulting in a regular 0 getting typed instead. You can see this with the HOSTKEYS logging channel enabled. The offending setting is in Settings > Devices > Typing > Advanced Keyboard Settings > Input Language Hot Keys on Windows 10, or the Text Services and Input Languages control panel in earlier versions:

 

 

Supposedly, changing Switch Keyboard Layout to Not Assigned will clear this shortcut... but I already had it set to NA with no additional keyboard layouts installed, and had to remove one and then delete it to clear the problem. So... YMMV.

 

I am tempted to use a raw keyboard hook to bypass these "helpful" shortcuts....

 

[flashjazzcat]

9 hours ago, phaeron said:

This is likely due to an annoying default in Windows where Ctrl+Shift+0 is by default bound to a key to switch between input languages.

That's exactly what it was. The procedure for turning this off is the same in Windows 11 and everything works fine now. Thanks so much!

 

[flashjazzcat]

15 hours ago, phaeron said:

Supposedly, changing Switch Keyboard Layout to Not Assigned will clear this shortcut... but I already had it set to NA with no additional keyboard layouts installed, and had to remove one and then delete it to clear the problem. So... YMMV.

Yeah: it randomly stopped working later in the day and now pressing CTRL+SHIFT+0 generates no input in the emulator whatsoever. Argh...

 

[phaeron]

11 hours ago, flashjazzcat said:

Yeah: it randomly stopped working later in the day and now pressing CTRL+SHIFT+0 generates no input in the emulator whatsoever. Argh...

Sigh, looks like Windows 10+ has a bug where the text services framework re-registers a hook for this on secure desktop switch even if it isn't supposed to be bound. Like all other bugs in Windows, very low chance of ever getting fixed.

 

I think for a start I'm going to add Ctrl+Shift+Alt+0 as an alias for this key, that at least seems to bypass the offending hotkey hook. Raw Input is able to see the key before the hook, but that then requires manually converting to characters.

 

[Ricky Spanish]

Does supersalt play nice with Altirra ? Tried it, got these:

Specs:

Base system    NTSC 1200XL (256K)
Additional Devices    1050 disk drive (full emulation), R-Time 8
OS Firmware    Atari 1200XL OS rev. 11 [1A1D7B1B]
Mounted Images    Disk: OSS BASIC XE - Extension.atr [6F91375D]
Disk: basic_programs.atr [37AB3B3E]
Cartridge: SuperSALT.rom.bin.zip!SuperSALT.rom.bin [0D99E328]

 

[phaeron]

5 hours ago, Ricky Spanish said:

Does supersalt play nice with Altirra ? Tried it, got these:

SuperSALT requires a special testing box to loop signals back into the computer's inputs. It's expected that you get errors running it without the box.

 

[Scott Savage]

On 4/24/2022 at 1:13 AM, phaeron said:

 

The Votrax chips are complicated to emulate ....

 

When I created the Speakjet, the hardest part was the phoneme frequency table.  It took months to tweek to get it to sound right.

[VinsCool]

Hey there, it's been a while since I last posted in this thread.

 

So tonight while I was playing in some of my experimental stuff involving a MIDI controller and Raster Music Tracker, I accidentally discovered what appears to be a POKEY emulation bug involving the 16-bit timing using the AUDCTL Join Channel bits, while also outputting volume on the LSB 16-bit channel (something lovingly nicknamed Reverse-16 Output).

 

How could I describe it and still make sense?

Well to make a short description, modulating the 16-bit frequencies, while outputting the sound in the LSB channel outputs a unique kind of tone, and it does have a lot of nice musical application with enough dedication, notably, creating a harmonic tone in a pulse/distortion motion, that would also be exactly 1 octave higher than the actual 16-bit tone underneath, so this is a somewhat predictable effect, making use of the 2 pair of 16-bit channels.

 

Well, here's when things took me by surprise: I noticed the sound output from the ch1+2 and ch3+4 pairs is very different to each others!

Specifically, only the ch1+2 pair does seem to sound correct, the other would seem to output the exact same pitch that would be in the MSB 16-bit channel output, and it would also crackle a lot whenever a single POKEY register would receive new data, for some reason.

 

I spent a bit more time earlier tonight to see if this was a normal occurrence, or if I was responsible for the bug in question, and to my surprise, this appears to be a bug present in Altirra for a really long time!

I tested versions from the most recent test build, all the way back to 2.80, and as far as I could tell, the behaviour in question (that is, the ch1+2 and ch3+4 pairs having a big disparity in sound output) seems to have been introduced in version 2.90.

Version 2.81, 2.80, and most likely further down, did not actually feature this difference, both pairs of channels will sound identical, but unfortunately the emulation accuracy of the Reverse-16 sound is also lower.

 

Also, I did test the exact same setup on real hardware, using both my PAL and NTSC Atari 800xl, and they do not suffer from the disparity-- each pairs of Reverse-16 channels will always sound identical.

Same for the Atari800 emulator, it sounds pretty much exactly the same as hardware, in this specific setup.

 

TL;DR: The Reverse-16 output is most likely incorrectly emulated between channels, where CH1+2 is the only one sounding proper, while the other pair is very off.

What is expected to happen is that regardless of the 16-bit pairs, the sound should be identical, as far as hardware comparisons went to confirm this was not something I caused myself earlier.

 

---

 

Anyway, how to reproduce the effect in question?

Written below is a simple way to hear what is going on, and this was also how I tested for the disparity going on for every version/platform I tested it, including RMT (where I initially noticed it):

 

- Using POKEY Explorer is the fastest and easiest way to showcase the bug, so first, simply load the .xex in Altirra/hardware/etc 

- Next, set the 4 AUDF channels to the following frequencies, in this order: $FF, $01, $FF, $01
- Now, press the J and K keys, this will activate the Join Channels 16-bit mode to both pairs, still running in 64Khz mode

 

Once these initial steps are complete, do the following, and you will immediately notice what I am talking about:

 

- Firstly, increment the volume level in channel 1 using the 2 key to a audible level
- Next, start decrementing the channel 1's AUDF value using the Q key
- What will then happen is the Reverse-16 sound in action, and this should sound exactly as expected

The pitch will go higher, while also the pulse wave will change its shape to modulate a different timbre as the frequency is being shifted.

- Once you are satisfied of what was heard, lower the ch1 volume back to 0 using the W key, in order to test the ch3 for the same setup

- Now, increment the ch3's volume level the same as before, using the 6 key

- And just like before, lower the ch3's AUDF using the T key, and listen carefully the sound that will be output

 

From this point onward, 2 things may happen:

- The sound produced is exactly the same in either ch1+2 or ch3+4 pairs --EXPECTED

Or

- The sound produced in the ch3+4 pair is very garbled each time a tiny change is applied, and appears to be identical to the underneath 16-bit tone if it was output the intended way --INCORRECT

 

The second one is exactly what happens in Every Altirra versions I tested, all the way down to the version 2.81, at this point, the 2 channels pairs will sound the same, but with lesser accuracy to what it should sound like on hardware.

 

---

 

And that's about it, if reading this much text sounds a bit boring, here's the RMT capture I made when I first noticed the behaviour:

 

 

While it is not truly the Altirra emulator, I can say for sure this is 100% identical to what the stand alone emulator also did, before I went ahead and gave a more indepth testrun.

Also, for further precision, the Altirra emulation core running through the plugins used in this recording came from the version 4.00.

 

So yeah, like I said above, what is expected, and should happen, is that the ch1+2 and ch3+4 output must be identical, fact backed up with hardware tests a few minutes later.

Thanks for reading a bit of rambling, I hope this may help tracking down why this is happening.  

 

[Mclaneinc]

 

Nothing wrong with a wall of text if it precisely describes what it wrong and needed to reproduce... Nailed that..

 

Also, I love reading reports like this, I have zero clue as to the issue, but it's the fact that people get to this high level of finding possible bugs, I'm sure most of us would not recognise there being an issue with pokey, we just listen to the whizzes and bangs in the games and are happily devoid of their being a problem. So it's amazing when folks get to this level and means us that have little or no idea having the best playing environment, while those that do use the machine to the utmost get an even better playground to experiment on.

 

Mind you, it helps that Avery is as precise as he is in the first place to have pretty much only really obscure bugs to fix..  ? ? all around..

Edited May 29, 2022 by Mclaneinc

[Keatah]

9 hours ago, Mclaneinc said:

So it's amazing when folks get to this level and means us that have little or no idea having the best playing environment, while those that do use the machine to the utmost get an even better playground to experiment on.

Yes that's a key point because it's really the way it is. All the little fixes gradually add up to a tweaked and polished accurate experience for us users.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.10-test13.zip
https://www.virtualdub.org/beta/Altirra-4.10-test13-src.7z

• The default keyboard layouts now have Ctrl+Shift+Alt+0 aliased to Ctrl+Shift+0, to work around the bug with Windows 10 text services randomly eating it.
• Fixed a bug in the debugger's .printf command with %d/%i and very large numbers.
• Fixed performance analyzer not seeking to the correct instructions when the history pane has Collapse Loops disabled.
• Added still image device to complement the video generator for ComputerEyes input.
• Made a couple of experimental changes to reduce latency. The video output path tries harder to avoid buffering frames ahead of the display code, the display code uses double buffering instead of triple buffering, and the D3D11 path requests 1-frame latency on both the swap chain and device as appropriate.
• Fixed a couple of issues with reinitializing linked timers that were causing glitches, including the above noted issue. The primary culprit was a 3-cycle skew adjustment to the ch1+2 path that hadn't been applied to the ch3+4 path.

You may encounter ghosting when using images to feed ComputerEyes. The reason for this is that, for some reason, the software uses a different horizontal offset that's about 9 pixels off for high thresholds than for low thresholds. No idea why, unless it's compensation for (very) slow response in the sample-and-hold circuit.

 

[VinsCool]

1 hour ago, phaeron said:

Fixed a couple of issues with reinitializing linked timers that were causing glitches, including the above noted issue. The primary culprit was a 3-cycle skew adjustment to the ch1+2 path that hadn't been applied to the ch3+4 path

Wonderful, this seems to work perfectly now!

Thanks a lot for such a quick bugfix!

[flashjazzcat]

2 hours ago, phaeron said:

The default keyboard layouts now have Ctrl+Shift+Alt+0 aliased to Ctrl+Shift+0, to work around the bug with Windows 10 text services randomly eating it.

This works perfectly - many thanks.

[Mclaneinc]

Could someone check if the latest beta is saving any added devices?

 

Mine isn't, be it computereyes or a type of drive, it's gone after Altirra is closed.

 

Ignore, just saw it was set to a temporary profile by accident.. Schoolboy error..

Edited May 30, 2022 by Mclaneinc