Jump to content
phaeron

Altirra 3.90 released

Recommended Posts

2 hours ago, VinsCool said:

I just noticed something interesting a bit earlier tonight.

image.thumb.png.58ad246f0de9674a99ae8c4c9b1b57ef.png

On top is a capture from latest Altirra 4.0-test using the WAV recorder feature, and below is the exact same audio recorded from my PAL 800xl 

 

Is it possible that Altirra is emulating audio but outputs the waveforms upside down? Or is it my recording setup that fooled me there?

Not like this is a major difference, but comparison side by side got me surprised, because I never noticed this was a thing until now since I happened to compare 2 audio recordings for a friend of mine.

Yes, this is possible. It makes no difference in the sound output because both the real hardware and Altirra's output are AC coupled and any DC bias will cancel out over time, but there may be an odd number of minus signs between the two. Altirra's output is calibrated against an NTSC 800XL; I haven't scoped the other systems, which may not even have the same polarity. For now you can invert the waveform; I may flip the output post-4.00 to make it easier for analysis if it turns out that hardware systems are consistent in polarity.

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
1 minute ago, phaeron said:

Yes, this is possible. It makes no difference in the sound output because both the real hardware and Altirra's output are AC coupled and any DC bias will cancel out over time, but there may be an odd number of minus signs between the two. Altirra's output is calibrated against an NTSC 800XL; I haven't scoped the other systems, which may not even have the same polarity. For now you can invert the waveform; I may flip the output post-4.00 to make it easier for analysis if it turns out that hardware systems are consistent in polarity.

 

Interesting! That makes sense, it's likely this is sort of happening just because, I guess,

I can check outputs from my NTSC machine some time later to see if it also does the same, I am actually curious to see if this was random, or if there is a pattern to it.

 

As long as things sound the same to the ears I am okay with either side, haha.

Share this post


Link to post
Share on other sites

Just a simple (non-hostile) question. Is it it at all possible to set your compiler to make WinXP32 compatible executables? I know it's not supported anymore, but is there any way possible? New code compile under old tool chain... Fix bugs, etc.

Thanks.

 

Edited by Kyle22
missed a space.
  • Like 2

Share this post


Link to post
Share on other sites

Would it be possible to build Altirra as a Windows 10 IOT core app?  (free OS - replaces the old Windows CE for the embedded world)

 

https://docs.microsoft.com/en-us/windows/iot-core/windows-iot-core

https://docs.microsoft.com/en-us/windows/iot-core/develop-your-app/buildingappsforiotcore

 

Then it could be run on ARM devices (Rasp Pi 3B at least is supported by IOT-Core) but also on devices like this one:

https://www.amazon.com/Lightweight-Stick-Windows-Intel-x5-Z8350/dp/B099JXXMQ1?th=1

 

That last device has full Win10 on it anyway, so I guess IOT-core would not be needed, but I sure like the idea of a device that plugs into a TV and boots straight to Altirra to do 8bit emulation - something like a bare bones "8-bit Mini".

Edited by rocketfan

Share this post


Link to post
Share on other sites
On 10/29/2021 at 6:58 PM, Kyle22 said:

Just a simple (non-hostile) question. Is it it at all possible to set your compiler to make WinXP32 compatible executables? I know it's not supported anymore, but is there any way possible? New code compile under old tool chain... Fix bugs, etc.

No, sorry. For 4.00 I updated to a newer version of the compiler that no longer supports XP. There are also changes to the code base that use Vista compatibility or drop workarounds for XP bugs (particularly in the rich edit control). It is no longer an option simply to use the older compiler.

 

I might do a bug fix release for the 3.x line containing critical bug fixes, but not feature backports.

 

5 hours ago, rocketfan said:

Would it be possible to build Altirra as a Windows 10 IOT core app?  (free OS - replaces the old Windows CE for the embedded world)

No. IoT Core requires a UWP app, which would require a full rewrite of the UI as well as some underlying code as well. The rewrite would then only work on Windows 10 which would mean either a very large jump in minspec or supporting two significantly different builds. UWP has been a disaster for the Windows ecosystem and I don't intend to support it.

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites
On 10/30/2021 at 6:08 PM, rocketfan said:

...but I sure like the idea of a device that plugs into a TV and boots straight to Altirra to do 8bit emulation - something like a bare bones "8-bit Mini".

 

Nice idea... bad pathway.

 

Share this post


Link to post
Share on other sites
22 hours ago, phaeron said:

IoT Core requires a UWP app, which would require a full rewrite of the UI as well as some underlying code as well.

OK, Got it and thank you for the explanation.

Share this post


Link to post
Share on other sites
On 10/30/2021 at 11:54 PM, phaeron said:

requires a UWP app

 

Here are some UWP acronym expansions.

 

UWP = Ultimate Windows Piss
UWP = Users Want Pwned
UWP = U Will Pay
UWP = United Windows Pissants
UWP = UnWanted Programs
UWP = Ultra-Weird Protocol
UWP = Unlimited Wank Productions
UWP = Uncle Wayne Puked
 

  • Haha 3

Share this post


Link to post
Share on other sites
On 10/30/2021 at 10:54 PM, phaeron said:

I might do a bug fix release for the 3.x line containing critical bug fixes, but not feature backports.

Please name it version 3.1415926535897932384626433...

  • Haha 3

Share this post


Link to post
Share on other sites

Slightly confused, saw on a news site that 3.91 was released and yes there is a 3.91 on Virtual dub with files dated yesterday but we have been testing version 4.00 up to now???

 

Ignore, explained above.. Had missed that post by Avery..

Edited by Mclaneinc

Share this post


Link to post
Share on other sites
4 hours ago, Mclaneinc said:

Slightly confused, saw on a news site that 3.91 was released and yes there is a 3.91 on Virtual dub with files dated yesterday but we have been testing version 4.00 up to now???

Yeah, I pushed out 3.91 yesterday as part of release work but ran out of time. It is the "pour out one last one for XP" release, containing bug fixes only:

[bugs fixed]
* AltirraOS: Adjusted internal variable usage of P: handler for better compatibility with programs that jump into it without opening P: (Monkey Wrench II).
* AltirraOS: Fixed E: Put Byte routine sometimes returning Y=2 instead of Y=1.
* AltirraOS: Implemented XL/XE NOCLIK variable.
* AltirraOS: Fixed minor rounding error in ATN() constant from assembler.
* AltirraOS: Fixed bugs with E: move left and delete char at column 0 with LMARGN=0.
* AltirraOS: Added workaround to SIO for devices sending two ACKs instead of ACK+Complete (fixes Indus GT diagnostics zero adjust).
* Display: Fixed failure to switch to exclusive full-screen mode in D3D9 with bloom enabled.
* Display: Reduced banding in PAL high artifacting mode.
* Input: Fixed Shift key interfering with controllers in 5200 mode.
* SaveStates: Improved reliability of save states.
* Serial: Fixed hang when dropping modem connection with unread data.
* Serial: Fixed initial socket data sometimes not being read from modem until first byte is sent.
* UI: Fixed a crash in dockable pane code with mixed DPI monitors.

All of it is backported changes, so there is no advantage to running it over 4.00-test. If you were wondering why I started adding an extra digit to the version number why still counting up by .10s, this is why.

 

Needless to say, anyone who's had experience here can guess that 4.00 is coming soon, I just need to do some menial work like updating the RSS feed for the release channel and updating the website to no longer have screenshots from back in the days of Windows 7 classic theme. But web work is so booooooring.

 

  • Like 3
  • Thanks 3

Share this post


Link to post
Share on other sites

Ah, 4.00 due soon...Excellent...Nice early Xmas present..

 

PS, can I pick your developer brain pls, I'm using Vice, a Commodore 8 bit emulator and I'm suddenly getting it saying that there's no disk in harrdisk3\DR3 and various other false HD locations when I try to  mount a d64 image or any type of rom etc. I searched and saw it was known MS item but no ways to fix it. Have you ever come across this before. I've seen it a couple of times on some emulators. 

 

Just trying to get rid of it as it does it every time you use the emu, sorry its OT but your knowledge of all things Windows is amazing.

Edited by Mclaneinc

Share this post


Link to post
Share on other sites

what am I doing wrong?

I set up altira 3.91 on windows 8.1 and set up device 850 interface with raw connection I connect at 9600 just like my real 850... and then... I get darn near whole dropped lines of characters...

on the real thing with a usr courrier, also with a trailblazer back in the day, and using a null modem between the 850 and an st or any other device... I might get a dropped character every blue moon, some 850's would be rock solid others might drop a character here and there... does this come down to my needing the actual 850 rom installed in altirra.... I have always used bobterm for the higher speed connections.

I also noticed another issue. bobterm normally lets me link and unlink to the 850 loading the handler without issue, it's a feature of the way bobterm handles the 850 polling methods... in altirra it seems I must power cycle everything to get the polling done, it does a weird partial beep repeatedly until it fails. I can do a full cold reset of all in altirra then it works, but still never a stable 9600 connection. I understand that many people didn't have a properly wired and shielded cable back in the day and couldn't do 9600 because of that, but almost anyone using a proper cable didn't have such problems or would sync up with whatever device after a few tries with their issue going away as the device trained on the 850.

 

Hopefully there is a simple answer, being set at 4800 seems a step backwards to me, 9600 and sometimes 4800 was the norm using my 850's and once I went with the blackbox/mio it was always 19.2k or 9600 depending on who was calling or what device was on the machine. Those seem to work properly in altirra so it's not likely a problem within those common shared points.

 

I understand simulating a lost character here and there might be in order but whole line appear to be overkill... I will try again later with the hopes that there might be some reason or network connection issue but my reasoning was it would fail using other devices just the same if that were the case.

Share this post


Link to post
Share on other sites
5 hours ago, _The Doctor__ said:

what am I doing wrong?

I set up altira 3.91 on windows 8.1 and set up device 850 interface with raw connection I connect at 9600 just like my real 850... and then... I get darn near whole dropped lines of characters...

on the real thing with a usr courrier, also with a trailblazer back in the day, and using a null modem between the 850 and an st or any other device... I might get a dropped character every blue moon, some 850's would be rock solid others might drop a character here and there... does this come down to my needing the actual 850 rom installed in altirra.... I have always used bobterm for the higher speed connections.

I also noticed another issue. bobterm normally lets me link and unlink to the 850 loading the handler without issue, it's a feature of the way bobterm handles the 850 polling methods... in altirra it seems I must power cycle everything to get the polling done, it does a weird partial beep repeatedly until it fails. I can do a full cold reset of all in altirra then it works, but still never a stable 9600 connection. I understand that many people didn't have a properly wired and shielded cable back in the day and couldn't do 9600 because of that, but almost anyone using a proper cable didn't have such problems or would sync up with whatever device after a few tries with their issue going away as the device trained on the 850.

 

Hopefully there is a simple answer, being set at 4800 seems a step backwards to me, 9600 and sometimes 4800 was the norm using my 850's and once I went with the blackbox/mio it was always 19.2k or 9600 depending on who was calling or what device was on the machine. Those seem to work properly in altirra so it's not likely a problem within those common shared points.

 

Hardware handshaking is the first thing that came to mind since the 850 can't really do it properly with the way it needs to drop out of concurrent mode to handle signals, but I don't think BobTerm supports RTS/CTS anyway.

 

Altirra doesn't emulate signal loss or noise on the serial port, but it does emulate bytes getting dropped because the computer wasn't ready to receive it -- since without handshaking those bytes are arriving whether the computer is ready or not. I did some tests and didn't see issues with BobTerm at 9600 baud with the built-in and SDX RS232-loaded handlers in the default state. It does drop characters if smooth scrolling is enabled, but that's expected as the smooth scroll is too slow to keep up with 9600 baud. One thing is that you'll want to ensure that throttling is enabled; if you check the disable throttling box, it is possible for the emulated R: handler to receive data >9600 baud. This is not possible with a 6502-based handler, which is the more accurate mode. The emulated R: handler mode, where the emulator just installs an R: hook instead of sending R: handler code and actually emulating the 850 commands, is more forgiving of throughput issues since it can hold off the modem in response to the R: buffering situation. Thus, you'll want to try both R: modes and see if one of them responds better than the other, which may give a clue as to what's going on.

 

850 R: handler loading is kind of finicky. IIRC, there are a couple problems with it, one being that the 850 firmware is configured to stop responding to some of the SIO commands involved in the load without a power cycle, and the other being that the US Doubler get high speed index command overlaps with one of the 850's loader commands. The latter can lead to SDX inadvertently disabling some forms of the handler load when it does its disk drive scan. It's been a while since I looked into BobTerm's 850 handler loader, but I think it hardcodes some of the 850 loader parameters instead of issuing the primary command to get them. This causes issues since Altirra's R: handler payload is smaller than the 850's. Padding it out might solve the issue but I haven't gotten around to digging out the 850 firmware's version to measure it. There isn't an option to load 850 firmware into the emulator as there's no hardware level emulation of it -- the way that the 850 operates serial-wise and would need low-level emulation like the full disk drive emulators to work.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, phaeron said:

 

Hardware handshaking is the first thing that came to mind since the 850 can't really do it properly with the way it needs to drop out of concurrent mode to handle signals, but I don't think BobTerm supports RTS/CTS anyway.

 

Altirra doesn't emulate signal loss or noise on the serial port, but it does emulate bytes getting dropped because the computer wasn't ready to receive it -- since without handshaking those bytes are arriving whether the computer is ready or not. I did some tests and didn't see issues with BobTerm at 9600 baud with the built-in and SDX RS232-loaded handlers in the default state. It does drop characters if smooth scrolling is enabled, but that's expected as the smooth scroll is too slow to keep up with 9600 baud. One thing is that you'll want to ensure that throttling is enabled; if you check the disable throttling box, it is possible for the emulated R: handler to receive data >9600 baud. This is not possible with a 6502-based handler, which is the more accurate mode. The emulated R: handler mode, where the emulator just installs an R: hook instead of sending R: handler code and actually emulating the 850 commands, is more forgiving of throughput issues since it can hold off the modem in response to the R: buffering situation. Thus, you'll want to try both R: modes and see if one of them responds better than the other, which may give a clue as to what's going on.

 

850 R: handler loading is kind of finicky. IIRC, there are a couple problems with it, one being that the 850 firmware is configured to stop responding to some of the SIO commands involved in the load without a power cycle, and the other being that the US Doubler get high speed index command overlaps with one of the 850's loader commands. The latter can lead to SDX inadvertently disabling some forms of the handler load when it does its disk drive scan. It's been a while since I looked into BobTerm's 850 handler loader, but I think it hardcodes some of the 850 loader parameters instead of issuing the primary command to get them. This causes issues since Altirra's R: handler payload is smaller than the 850's. Padding it out might solve the issue but I haven't gotten around to digging out the 850 firmware's version to measure it. There isn't an option to load 850 firmware into the emulator as there's no hardware level emulation of it -- the way that the 850 operates serial-wise and would need low-level emulation like the full disk drive emulators to work.

 

It's answers like these where the emulator author goes way beyond the call of duty that make me appreciate @phaeron and Altirra so much. It is clear that a) he has spent plenty of hours of studying the machine, their peripherals and their firmware and b) he also put in the hours to try and determine how the devices cooperate and what happens if they don't so he can determine if it's the emulator's fault or the hardware's. I cannot think of many people who would do this instead of answering something like "lolz, I don't know why your combination of emulated machine and peripherals don't work, don't use it" or "it's free software, patches welcome".

 

Also, a plea to everyone to stop bothering him with supporting older O/Ses like WinXP or different ones like Linux/Mac. From personal experience of maintaining a very low dependency program (it only uses a couple of standard libc and math functions) and all the pain this causes (for example: crashes only on osx, works on other configurations), I can't really imagine what happens on a full blown GUI program which is tied to Windows specific APIs. I personally have to keep an ancient version of MinGW which I never update just to provide builds that work on WinXP. This is not very easy if you have to keep multiple versions of Visual Studio installed and all supporting components (at some point I thought I had a XP toolchain on VS19 but this "magically" disappeared from an update, therefore the binary I built would not work on other machines and I had no idea).

 

Building and maintaining released software is hard. Doing that for multiple platforms is a full time job. Please be reasonable.

  • Like 3
  • Confused 1

Share this post


Link to post
Share on other sites

Don't worry @ggn anyone who has been following Altirra for any length of time has seen just how much Avery brings to this and how he goes out of his way to explain problems and we appreciate every minute of that time and try and not bother him for stuff that he had long since alerted us of the plan to end support for an item. Of course, sometimes a question will pop up because we may not have seen a post or some clarification may be needed, but these are normally rare.

 

In my post above I asked him about an issue I was having with an emulator purely because he has shown just how knowledgable he is, and it might have been something he came across himself. I never demand an answer and nor would I, I respect the man too much to be anal like that and it's an OT question which does not deserve a reply and I respect that he's a busy guy, it was just an innocent query.

 

So to be fair, Avery has stopped people in their tracks when there's been an objectionable question or remark towards him or his work, whilst the rest of the group just sit in awe of just what he does, I think any regulars have more sense and manners to make demands on him and his time.

  • Like 3

Share this post


Link to post
Share on other sites
6 hours ago, ggn said:

It's answers like these where the emulator author goes way beyond the call of duty that make me appreciate @phaeron and Altirra so much.

Yes. I recall several years back asking about exact colors & artifacting for StarRaiders, Flight Simulator, and Ultima. Soon enough Altirra had some changes and new options to dial it in exactly as we remembered it.

  • Like 1

Share this post


Link to post
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...