Altirra 2.40 Final out..

[phaeron]

http://www.virtualdub.org/beta/Altirra-2.50-test3.zip

http://www.virtualdub.org/beta/Altirra-2.50-test3-src.zip

 

Includes XInput support, so Xbox 360 controllers no longer suffer from having their triggers tied together and the guide button can also be bound. XInput 1.3 is needed for the guide button. The input map UI now also identifies the axes and buttons.

 

http://atariage.com/forums/topic/218532-our-sillyventure-2013-demo-entry/?do=findComment&comment=2864590

 

Said demo in original form worked on Altirra but not real hardware..

 

I couldn't actually get any of the versions to fail, but from what I gather, it was a bug that caused a dependency on memory state, which in turn means the method of loading the EXE matters. In any case, doesn't seem to be a hardware emulation issue.

 

I have a few bug reports..

H: handler (1): When opening a file in append mode (aux1=9) if the file doesn't exist a File Not Found error (170) is returned; the correct behavior is that a blank file should be created and no error is returned.

H: handler (2): In MyDOS, attempting to copy a file from H: to an emulated D: drive fails with Error 165. There is no problem accessing the file, I can even drop to BASIC and write a program that will copy the same file, but MyDOS won't do it.

R: handler: The R: device completely dies if you make an outbound connection then cold-start while still connected. The only workaround I've found is to quit and reopen Altirra.

 

I fixed the first H: bug and the R: bug. In the latter case, it was just that the modem was still in online state -- you could dislodge it by +++.

 

The error 165 problem appears to be a bug in MyDOS's DUP.SYS. Here's what the CIO trace looks like:

 

 

CIO: IOCB=1, CMD=$03 (open), AUX1=$04, filename="H1:OREGON.BAS"
CIO: IOCB=1 (H:), CMD=$07 (get characters), buffer=$4377, length=$78a8
CIO: IOCB=2, CMD=$03 (open), AUX1=$08, filename="D2:"

 

The invalid filename error is actually coming from MyDOS itself, on the D: device. It works if you specify a full destination path.

 

I fixed the Telnet escape problem, too -- was actually supported, but a buffer overflow check was inverted. No terminal negotiation yet, but just didn't feel like doing the UI for that tonight.

 

Feature Request:

When a crash is detected, an option is supplied so that error information is sent to you Phaeron. This may include a copy of all the settings, the emulator version, the programs in memory / disks loaded etc. It would need permission to send you the information, and if the net is available from the machine running the emulator, it sends all the details to you.

 

You can then filter according to the latest version and then be able to categorise the issues.

 

And who exactly would be writing and maintaining the server backend for this? Do I look like a server programmer?

 

I'd probably want to start with a local database for this first, both because it's easier and also because that avoids the headache of having a server flooded with chaff reports. If you've ever worked on a program in Windows before turning off werfault.exe, you know what I mean.

 

[itaych]

I fixed the first H: bug and the R: bug. In the latter case, it was just that the modem was still in online state -- you could dislodge it by +++.

 

Thanks for the fix. It seems that +++ would indeed work, but nothing else worked - that is, the communications line became unresponsive and would not transmit data.

 

I fixed the Telnet escape problem, too [..]

I checked and the problem is not fixed, and indeed according to the changelog you only fixed it for outbound data. What about the inbound direction? It needs to be handled in the same way, i.e. ignore anything after an FF except for another FF (in which case Atari gets a single FF).

 

Cheers

[itaych]

The error 165 problem appears to be a bug in MyDOS's DUP.SYS.

 

Is anyone still maintaining MyDOS and able to fix this?

[atx4us]

http://www.virtualdub.org/beta/Altirra-2.50-test3.zip

http://www.virtualdub.org/beta/Altirra-2.50-test3-src.zip

 

Includes XInput support, so Xbox 360 controllers no longer suffer from having their triggers tied together and the guide button can also be bound. XInput 1.3 is needed for the guide button. The input map UI now also identifies the axes and buttons.

Maybe I'm over looking something simple. Is there a way to adjust the sensitivity of the Xbox 360 left analog stick when used as Paddle controllers? I was trying out Arkanoid and the Paddle controller seems to behave as an analog controller but it is much too sensitive to be useful.

 

In case someone reading this didn't know, the F1 and F2 (toggle flags) in the Input Mappings refer to the left and right thumb buttons of the Xbox 360 analog sticks.

[phaeron]

 

I checked and the problem is not fixed, and indeed according to the changelog you only fixed it for outbound data. What about the inbound direction? It needs to be handled in the same way, i.e. ignore anything after an FF except for another FF (in which case Atari gets a single FF).

 

Different problem -- didn't notice it because I was pushing a sequence that didn't have more than one $FF in a row. Try now:

 

http://www.virtualdub.org/beta/Altirra-2.50-test4.zip

http://www.virtualdub.org/beta/Altirra-2.50-test4-src.zip

 

Was fun testing this, btw... last time I used two emulators with BASIC, which was painful. This time I fired up and connected to a VM with Ice-T, which worked great until I found that typing C code is inconvenient on a keyboard with no brace keys:

 

 

Maybe I'm over looking something simple. Is there a way to adjust the sensitivity of the Xbox 360 left analog stick when used as Paddle controllers? I was trying out Arkanoid and the Paddle controller seems to behave as an analog controller but it is much too sensitive to be useful.

 

In case someone reading this didn't know, the F1 and F2 (toggle flags) in the Input Mappings refer to the left and right thumb buttons of the Xbox 360 analog sticks.

 

Currently, no, the absolute mapping modes always go rail to rail -- full left to right on the stick maps 0 to 228. If Arkanoid is mapping a smaller range then I can see that being a little restrictive. The relative mapping modes can be scaled, but that will feel a lot different than absolute since you'll be pushing the paddle instead of placing it directly. For kicks you can bind one of the analog sticks to the 2D rotation X/Y inputs on the emulated paddle -- this will make it so that a rotation on the stick rotates the paddle.

 

F1 and F2 (flag 1 and 2) don't necessarily have to refer to the thumb buttons. It's set up that way in the default mappings because there's an Input State controller that has bindings to the thumb buttons in toggle mode, but you can drive the flags from any other input. For instance, you can bind them in non-toggle mode to the trigger button inputs, in which case they'll work like shift buttons -- you can overload buttons based on whether one or both triggers are held down.

[itaych]

In Ice-T braces are Ctrl-9 and Ctrl-0.

 

To test the new version I hit Ctrl-C when in a Ubuntu Linux telnet shell. Doing this causes the host to respond with FF F2 over the network, and then the expected ^ C characters and then the command prompt. The FF F2 is supposed to cause no effect, but Ice-T receives the F2. The F2, as any other value received here (except FF), should be ignored and not passed to the Atari.

[itaych]

Another issue is the handling of the 0D (CR) character in Telnet mode. According to the RFC (854, page 10) if a CR alone is transmitted (and not as part of a CR LF sequence) it should be converted to CR NUL. This applies to both directions. This means that:

In the inbound direction, when receiving an 0d pass it to the Atari but also raise a flag; for the next byte received, if it's 00 then suppress it and do not pass it to the Atari. Drop the flag. (but if the byte is 0D raise the flag again, of course.)

In the outbound direction, if a 0D is sent by the Atari, send it out, but raise a flag. Upon the next byte sent from the Atari, if it's a 0A send it as is; if it's anything else, send a 00 and then that byte. Drop the flag. (but if the byte is 0D raise the flag again.)

 

The problem with the present state is that the Atari receives NUL bytes which are supposed to be ignored at the Telnet level.

 

Sorry to be so pedantic, my desire is to have Ice-T be able to do binary file transfers.

Edited November 15, 2013 by itaych

[Mclaneinc]

I love this detail of emulation, I don't have a clue what is being talked about to be honest (well I understand a little but I adore the perfection going on, every little bit & byte has its place and being put there.

 

What does throw me a little is why people want the poor old Atari to do all these wonderful things in these days of fibre optic links and i7's, the answer obviously is because it can but at times I almost feel sorry for the old fella Atari, its been the best and now retired and now some young whipper snappers are forcing it back out to work doing stuff it was never built for

 

Mind you, that's what the UK governments are doing to our senior citizens to life imitates art I guess

[phaeron]

Okay, I have a pretty good idea of what's going on in both cases, but both are pretty nasty.

 

The $F2 problem isn't an escaping problem. It's actually a problem with Out-of-Band (OOB) data being sent via the TCP Urgent mechanism. The problem is that the $FF is being sent OOB, which Altirra currently drops, resulting in the $F2 data mark command being received as data instead. The Winsock documentation is not at all clear about how OOB data interacts with async notifications and SIOCATMARK seems to be unusable, so I think I'm going to need to turn on SO_OOBINLINE to fix this. This will prevent the telnet logic from fast-forwarding on a sync, but it's not like I was handling that either.

 

The CR stuffing issue is a problem for a few reasons. With regard to CR handling over Telnet, it turns out that RFC 854 is superceded by RFC 1122, which notes compatibility issues over CR NUL vs. CR LF and recommends that CR LF be the standard default as well as either being equivalent for input. That would be the easier way to go but unfortunately prohibits binary transfers. Going with CR NUL, on the other hand, forces one of two ugly downsides. One way to go would be to force all CRs to be stuffed as CR NUL, but not only does that turn CR+LF into an incorrect CR NUL LF pattern, but it also breaks using Telnet to connect to non-Telnet servers (which happens all the time). The other way is to have the telnet logic buffer one character past CR, which allows the stream from the Atari side to be sent pristine but makes interactive operation unusable. Neither is very palatable. A possible alternative would be to bypass CR stuffing using the binary transmission option from RFC 856, but I'm not sure how compatible that will be.

[snicklin]

And who exactly would be writing and maintaining the server backend for this? Do I look like a server programmer?

 

I'd probably want to start with a local database for this first, both because it's easier and also because that avoids the headache of having a server flooded with chaff reports. If you've ever worked on a program in Windows before turning off werfault.exe, you know what I mean.

 

 

To simplify matters, maybe an email could be sent with the files as attachments? Then you have an email program which is configured to filter emails into different folders dependent on the contents. You would need to include a few certain keywords in the mail, i.e Program name, emulator version etc.

 

That saves needing a server, you use someone else's email server. Then you just download when you want to. With regards to chaff, you could assume that everything is chaff. Then if a few people have said, "Altirra doesn't work well with XYZ", you then look up all the reports from XYZ from the latest version of the emulator (or recent ones) to see what is going on.

[itaych]

The $F2 problem isn't an escaping problem. It's actually a problem with Out-of-Band (OOB) data being sent via the TCP Urgent mechanism.

 

Wow, this is weird stuff. Now that I look at it, the Wireshark analysis says that the FF is sent in a "Malformed Packet"! It also happens that way when connecting with Tera Term, but not with the command line Microsoft Telnet, though I can't see anything in its negotiation that would tell the remote side to disable the OOB feature. Anyway it sounds like you've found a solution, let's hope it works.

 

Going with CR NUL, on the other hand, forces one of two ugly downsides.

 

As far as I can tell, it seems that you agree with my idea for handling the incoming data, and are considering options for the outgoing direction.

 

In my previous post I told you how I think it should be handled, it is different from the two options you described and there is no buffering or delaying required, plus a CR LF would not get a NUL stuffed in between. The downside is that if a NUL must be transmitted after a CR, it wouldn't be sent immediately but only when the Atari decides to send the next byte, which may be a significant amount of time later. However I don't think this should be a problem; today when the user presses Return just a CR is sent, and if the remote were waiting for the subsequent NUL we'd all notice it because your session would hang. So what I think is happening is that the remote side is not waiting for the NUL but is able to ignore it if received. If this is correct then my solution would work because in normal operation a NUL would be sent by the Atari after the user presses the next key after Return - that would be ignored by the remote. Binary transfers would be fixed because if the Atari ever needs to send a CR NUL in the context of a binary upload it would be correctly converted to a CR NUL NUL.

 

I've done this experiment: From Altirra, connected to a Linux host over Telnet, type "cat" <return>, then Ctrl-space (which sends NUL) twice. The first one is not echoed, because the Linux Telnet server was waiting for a NUL after the CR. The second one is echoed as ^@. When trying the same with Tera Term the first Ctrl-space is echoed, because Tera Term sent a NUL after the CR. This is strongly in favor of my proposed solution.

 

Of course this is all moot when connecting to a non-Telnet destination; isn't that exactly what the "Emulate Telnet protocol" option is for? When that option is disabled there should be no conversion of anything. Which, BTW, wasn't the case last time I checked - transmitted FF bytes (from the Atari) would be swallowed by Altirra - have you addressed this?

 

Thanks

Edited November 16, 2013 by itaych

[phaeron]

You're not supposed to use a telnet client to connect to non-Telnet servers, but that doesn't stop people from doing it. Point is, this often works for things like SMTP and HTTP because the Telnet clients default to CR/LF endings, and that's the current recommended behavior. Sending CR/NUL is valid but lacks these benefits.

 

I changed the output escaping to use eager CR -- try this version:

 

http://virtualdub.org/beta/Altirra-2.50-test5.zip

http://virtualdub.org/beta/Altirra-2.50-test5-src.zip

 

(This build also has a fix for VBXE extended color, for others watching.)

[itaych]

The incoming end seems to be handled well now, and the OOB issue is taken care of. Great!

 

However the outgoing is now broken: With the new version I can't type more than one consecutive Return! The second and all subsequent Returns look like they just send a NUL and no CR.

 

If you are worried that some hosts will break on receiving a CR NUL, what you could do is default to sending regular CR, but if the remote host performs a Telnet negotiation (the FF xx commands at the beginning of a session) then you can switch to CR NUL mode (as I described), knowing that this is no SMTP or whatever. Any server that can perform a Telnet negotiation should be able to require or at least quietly ignore these NULs.

Edited November 19, 2013 by itaych

[itaych]

When Telnet protocol is disabled ("Emulate Telnet protocol" is unchecked), please do not perform outgoing translation, i.e. do not convert FF to FF FF or CR to CR NUL. Leave them as is. Thanks

Edited November 19, 2013 by itaych

[phaeron]

Argh... try this version:

 

http://www.virtualdub.org/beta/Altirra-2.50-test6.zip

http://www.virtualdub.org/beta/Altirra-2.50-test6-src.zip

 

Delaying switch to CR/NUL until Telnet negotation occurs was the same idea I had... will have to try implementing that.

[itaych]

Excellent! This is rock solid as far as I can see.

 

I have a few other notes. It'll probably take you a few minutes to fix these:

1. The Hayes compatible modems were never case sensitive in their command set. I think 'atdi' should work just like 'ATDI', just as my modem never had a problem with 'atdt'.
2. Make port 23 the default if not specified in the ATDI command. This is primarily intended as a Telnet client so why not?
3. H: device: IO Commands 33/35/36 (delete/lock/unlock file) all work well but do not return an error if they fail (e.g. trying to act on a nonexistent file, delete a locked file, etc).
4. H: device: IO command 32 (rename file) works well but always returns an error code 146 regardless of success or failure.

Thank you once again!

[phaeron]

Fixed:

http://www.virtualdub.org/beta/Altirra-2.50-test7.zip

http://www.virtualdub.org/beta/Altirra-2.50-test7-src.zip

 

There may still be some OS error codes that aren't mapped and give the generic error (255) -- let me know if you run into such a case.

[itaych]

1. Renaming a file now never returns an error. Trying to rename a file that doesn't exist does nothing, yet returns success.
2. Renaming a locked file succeeds when it should fail.
3. R: still waiting for terminal type negotiation. Hope you haven't forgotten that one

Other than that everything looks great!

[bfollett]

I was just trying to run Telengard in Altirra and it crashed no matter what configuration I tried, so I tried it in Atari800win and it booted right away. Just wondering if you wanted to look into why. I've attached the atr file from Atarimania.

 

Bob

Telengard.atr

Edited November 22, 2013 by bfollett

[Roydea6]

Enable Basic ..

[bfollett]

Enable Basic ..

Hmmm, I'd tried enabling Basic and it still crashed, but I must have tried it in combination with some other incorrect setting like OSB or something else because it still crashed. But, per your suggestion, I tried it again and it worked with the XL bios.

 

Thanks,

 

Bob

[drac030]

PCLINK does not work completely correctly when any clock speed higher than 1,77 MHz is selected. Reading to the Atari side works, but writing to the PC side creates 0-length files at the destination. All the SIO otherwise works. SDX, standard SIO driver (DEVICE SIO in CONFIG.SYS).

[itaych]

Hey. I've been at work the last few days taking advantage of the fixed Telnet, and implemented Xmodem upload in Ice-T. Unfortunately, while it works for direct (non-Telnet) connections it fails over Telnet when transmitting a file containing a CR LF sequence. When comparing a Wireshark analysis of Ice-T+Altirra to a working case (Tera Term in Telnet mode), it seems that the correct behavior for outgoing data is to add a NUL after every CR, regardless of whether it is followed by a LF.

 

This is also shown when running vttest (you may need to 'sudo apt-get install vttest'): select option 6 (terminal reports) then option 2 (Linefeed/Newline test). PuTTY seems to be the only Telnet client that gets it right: only when sending CR NUL LF does the host receive CR LF properly.

 

As we agreed before, this behavior should only be enabled following a successful Telnet negotiation, so there's no worry about breaking a non-Telnet host. And just to clarify, I'm only talking about the outbound direction here, the inbound character handling seems to be perfect at this point.

 

I will email you an updated Ice-T later today so you can test the Xmodem for yourself, though I'm fairly certain that if you can get vttest to pass then the problem will be solved.

 

Thanks for being so patient with this..

Edited November 24, 2013 by itaych

[+Stephen]

Awesome! I was hoping you were doing this in order to add upload capability

[phaeron]

More H: issues fixed, PCLink fwrite() race condition fixed:

http://www.virtualdub.org/beta/Altirra-2.50-test8.zip

http://www.virtualdub.org/beta/Altirra-2.50-test8-src.zip

 

Haven't forgotten about term negotiation, haven't gotten to around to it. I'll have to research the CR-LF issue more -- sending CR-NUL-LF instead of CR-LF seems totally broken to me considering that sending CR-LF is the recommendation in the RFCs, so I want to check how this is handled in the wild.