Altirra 2.40 Final out..

[itaych]

sending CR-NUL-LF instead of CR-LF seems totally broken to me considering that sending CR-LF is the recommendation in the RFCs

 

On a similar note I've recently been discussing the Linux X/Y/Zmodem implementation with its author, Uwe Ohse, asking him why in a couple of places the Zmodem sender sz (which imitates Chuck Forsberg's original) does things not according to the document standard, breaking Ice-T's receiver. He had a few choice words on the subject, which I believe should be a guiding light to inspire us all in these difficult situations:

 

"I do not think the specification is worth anything.

 

Regards, Uwe"

 

[itaych]

There's a problem with the Disk Drives > Mount folder as virtual SpartaDOS disk (maybe DOS too) feature. Once a file is loaded by the Atari, if the file is changed by the host system and the Atari tries to load it again, things go berzerk: either the Atari will read garbage from the file or Altirra will crash.

 

Here is a step by step of what I did:

1. Drag the SpartaDOS cartridge image SDX445_sdx128.car to Altirra. This boots SDX. (Let me know if you need this file.)
2. Mount drive 1 as a SpartaDOS virtual disk pointing to a directory containing one file named ICET.XEX (version 2.8.0 alpha 5, see the Ice-T 2.76 thread).
3. Load the file: X ICET.XEX and wait for Ice-T to load.
4. Coldstart the Atari, you're back to SDX.
5. In Windows, replace ICET.XEX with a different version (alpha 4 from the same thread).
6. Load the file: X ICET.XEX. Altirra crashes - the minidump is attached (remove .txt from file name).

AltirraCrash.mdmp.txt

[flashjazzcat]

I once experienced issues using SDX format, but I use DOS 2 format in this exact way every day without issue.

[itaych]

Agreed, I've just tried to reproduce this issue with MyDOS and DOS format with no problems. So I guess the issue lies in SDX virtual disks only.

 

However, writing files to these virtual disks (from the Atari) doesn't seem to work for me, regardless of format.

[flashjazzcat]

However, writing files to these virtual disks (from the Atari) doesn't seem to work for me, regardless of format.

That's because they're read-only.

[itaych]

In that case the Disk Drives dialog should prevent you from setting them to R/W.

[flashjazzcat]

And I suppose some explanatory gloss in the dialog, lest someone tries to set it read/write, can't, and then assumes the drop list is broken.

[phaeron]

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

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

 

Telnet uses CR-NUL and supports terminal type negotation, fixed virtual disk crash, debugger keyboard shortcuts are now configurable. Because of the last change, this version uses a different keyboard shortcut store, so keyboard shortcuts will be reset to defaults.

 

The virtual disk issue occurs when Altirra doesn't notice that the file has been updated in time. When this occurs, it's too late to correct the problem as DOS has already read and cached the directory entry for the file. This is ordinarily caught by a directory watcher, and since I wasn't able to reproduce the problem I had to diagnose it just off the minidump. I could see this issue happening if the files are coming from a source that doesn't reliably send directory change notifications, such as a network path.

 

Telnet appears to be a poorly standardized protocol. For instance, RFC 1123 says that CR-LF should be the default line ending... but of course, Linux telnet defaults to CR-only. Then there's RFC 1091, which points to RFC 1010 (now the IANA database) for the list of standardized terminal type names... but unsurprisingly, while DEC-VT100 is listed as one of the standard terminal type names, Linux neither accepts nor sends it and uses vt100 instead. Yay for standards.

 

The wonderful thing about specifications is that (a) people suck at writing them and (b) nobody follows them. Most specs are terrible in that they often don't cover corner cases, such as what should happen when a requirement is violated, and even frequently omit the most basic of information such as what byte order is used. This leads to horrors like FTP, where the directory listing format is literally whatever the server OS's 'dir' or 'ls' command produces. Then you get ones that are just difficult to read, like the XML spec, which is laid out in random order and constantly references concepts before they are defined. But hey, it's extensively hyperlinked, so you can play Choose Your Own Specification Adventure. On the other hand, the PNG specification is one of the better specifications I've read.

[Keatah]

Thanks for making this emulator. While I don't understand or know all the finer points of what makes it so good, I do understand the effort and attention to detail.

[itaych]

The telnet is awesome, you nailed it

 

I do think however that if the user requests "None" in the terminal type then it should behave as before, i.e. refuse to negotiate. The result should be that in Linux echo $TERM returns "network" (now it returns a blank string).

 

The "dec-vt*" options should probably be moved to the bottom of the list as Linux doesn't accept them (try running Emacs).

 

Regarding the virtual disk behavior, I retried the same sequence I described previously. Now Altirra doesn't crash but still at some point when loading the file after it is modified, it seems to act as if the file just contains zero bytes. (Ice-T has a multi-stage loader. After one of the intermediate stages runs and returns, the rest of the file has zeroes.) This causes Ice-T to load in a broken state. I did see this bug before but thought it and the crash were the same bug. Once the file seemed corrupted (only to the Atari of course, it was perfectly intact on the PC) I copied it to a Sparta format ATR. That ATR is attached here (rename .zip to .7z) because I found no simple way to transfer the file back to the PC for analysis. The file should be compared to the 2.8.0 alpha 5 Ice-T executable.

 

BTW there is nothing special with my setup, this is Win 7 32-bit with everything on the local hard drive.

temp.7z.zip

Edited November 28, 2013 by itaych

[phaeron]

Think I figured it out -- there was a bug that sometimes prevented changes to the root directory from triggering some required invalidations:

 

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

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

 

If the issue persists, please post a log from the VDISK channel created from the repro steps (command "lfe vdisk" in the debugger to enable it). This shows what the virtual disk system is doing.

 

Note that with SpartaDOS, it's really only safe to update files on the host side when all files are closed. This is because the complexity of SDFS and SpartaDOS's caching requires that the sequence number on the volume be bumped, which pretty much invalidates the entire volume. This will be triggered whenever any file inside any directory that SpartaDOS has seen has changed, since the directory entry itself has to be invalidated. SpartaDOS checks for volume sequence bumps frequently, but expect it to be pretty upset if it sees a volume update while it has a file open and it hasn't updated the volume itself. You can get away with a bit more with Atari DOS and a virtual DOS mount, since DOS 2 filesystems are much simpler and Atari DOS doesn't cache much at all.

 

As for how to get files off, the easiest way is to use the disk explorer from the Disk Drives dialog and simply drag the files out of the live SDFS volume.

[itaych]

I'm not changing any file that is still open. Load a file, reboot, replace the file, load file. Anyway the bug seems fixed so I guess the issue is closed. Thanks!

 

Did you notice my comments regarding Telnet in my previous post? I edited them in after posting so you may have missed them.

[Creature XL]

Saw the source code for the first time

You are a real coder. Such a big program without (nearly) any comments ( just checked the debugger code)

Edited November 30, 2013 by Creature XL

[phaeron]

Fix for disabled terminal negotiation:

 

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

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

 

 

Saw the source code for the first time

You are a real coder. Such a big program without (nearly) any comments ( just checked the debugger code)

 

I do have a fairly spartan commenting style, although I tend to comment interfaces a bit better in professional work than in my hobby projects. The 6502 code has more comments (src/Kernel/*). The debugger architecture is in some desperate need of refactoring, though.

[Creature XL]

I do have a fairly spartan commenting style, although I tend to comment interfaces a bit better in professional work than in my hobby projects. The 6502 code has more comments (src/Kernel/*). The debugger architecture is in some desperate need of refactoring, though.

 

Good to know about the refactoring the debugger.I f I actually want to implement (small) features I find useful, I better wait until the code is refactored

However, really adding stuff is not happening soon

 

@comments: in my professional code I comment a lot, well, I get paid for it

And I start doing it for my hobby projects as well. Thinking of improving/fixing "MJO" (my first big Atari program)? better not "HitC" on the other hand is well structured and commented - at least for the most part.

 

But that's off topic. I better post bugs and feature requests for the debugger in this topic

Edited November 30, 2013 by Creature XL

[Mclaneinc]

I'm from the time when real coders did it Q&D (quick and dirty)

 

Well that was what they called it here...Mind you I was so poor at coding I rarely used labels, all direct.

[xxl]

Disk Drive/ emulation level / US - Happy.

why it's work under Altirra but not on real Atari? hang if US is ON - tested SIO2SD & aspeqt

Read Status and Read Sector in loop.

test.atr

[phaeron]

Two things I can see immediately:

 

Your command timeout is too long. Devices have to ACK or NAK a command within one VBLANK (16ms), and that means you should wait at most for two changes in RTCLOK+2. The US Doubler scheme requires that the device autodetect the baud rate being used by the computer, and since AspeQt can't do this, it simply switches the baud rate back and forth on framing errors to try to lock onto the correct speed. This means you should expect a high rate of command failures when communicating over an SIO2PC like device.

 

The second issue is that it looks like the xBIOS code is still not waiting for the transmission to complete correctly:

 

    2278:139:  6 | A=10 X=ED Y=00 (   I  ) | 0BB0: 8E 0D D2          STX SEROUT
    2278:139: 10 | A=10 X=ED Y=00 (   I  ) | 0BB3: 8A                TXA
    2278:139: 12 | A=ED X=ED Y=00 (N  I  ) | 0BB4: 18                CLC
    2278:139: 14 | A=ED X=ED Y=00 (N  I  ) | 0BB5: 6D FC 0B          ADC $0BFC
    2278:139: 18 | A=DA X=ED Y=00 (N  I C) | 0BB8: 69 00             ADC #$00
    2278:139: 20 | A=DB X=ED Y=00 (N  I  ) | 0BBA: 8D FC 0B          STA $0BFC
    2278:139: 24 | A=DB X=ED Y=00 (N  I  ) | 0BBD: 60                RTS
  2278:139: 40 | A=DB X=ED Y=00 (N  I  ) | 0B04: 88                DEY
  2278:139: 48 | A=DB X=ED Y=FF (N  I  ) | 0B05: 10 F7             BPL $0AFE
- 2278:139: 56 | A=DB X=ED Y=FF (N  I  ) | 0B07: 20 83 0B          JSR $0B83
    2278:139: 70 | A=DB X=ED Y=FF (N  I  ) | 0B83: AD 0E D2          LDA IRQST
    2278:139: 78 | A=FF X=ED Y=FF (N  I  ) | 0B86: 29 08             AND #$08
    2278:139: 82 | A=08 X=ED Y=FF (   I  ) | 0B88: D0 F9             BNE $0B83
  + Last 3 insns repeated 40 times
    2278:144: 76 | A=00 X=ED Y=FF (   IZ ) | 0B8A: A9 13             LDA #$13
    2278:144: 80 | A=13 X=ED Y=FF (   I  ) | 0B8C: 2C A9 23          BIT $23A9
    2278:144: 88 | A=13 X=ED Y=FF (N  I  ) | 0B8F: 8D 0F D2          STA SKCTL
    2278:144: 94 | A=13 X=ED Y=FF (N  I  ) | 0B92: 8D 0A D2          STA SKRES

 

Technically, you can't write to SEROUT and then immediately begin polling the SEROC IRQ ($08) -- you have to wait for SEROR IRQ first ($10) and only then poll SEROC. Usually you can get away with this in an interrupt-based routine due to IRQ servicing latency, but in a polled routine there's a chance you can outrun POKEY.

[itaych]

Hi, me again.

 

While playing around with the Telnet client today I ran into another problem with it. It's probably yet another weird edge case - basically I telnetted to the Telnet Server service running on my own Windows machine, it used to work but now the NUL characters break it completely. Again it seems that PuTTY is the golden standard and has no such problem, but instead of investigating the issue I had another idea.

 

The PuTTY suite (which is open source) includes a utility called Plink. What it does is open a connection for you - be it Telnet, Raw, Rlogin, SSH, or even to the computer's serial port - takes care of all translations for you and all you need to do is send and receive bytes via stdin and stdout.

 

Let's suppose Altirra accepted a new command, say, ATDP args. The args will be sent as is to the Plink command line (like ATDP -ssh user@10.0.0.1). Once Plink is launched you output CONNECT 9600 and then connect the Atari's virtual serial port to the Plink process's standard i/o. You do need to monitor for '+++' but otherwise Altirra is just a transparent pipe; and when Plink quits output a NO CARRIER. I think that's pretty much it (you don't even have to do the Telnet negotiation, it's all taken care of) - that's all you have to do to get not only a perfect Telnet client but also SSH and others I noted above and most importantly this seems like a future-proof solution: when Telnet has gone the way of the dodo you're not going to be pestered by people like myself who are still playing with their Ataris and will want SSH and Plink will surely support additional future standards too.

 

If Plink needs a password or wants to report a connection error it pops up its own dialog so you needn't worry about error messages (e.g. "NO ANSWER") or password dialogs.

 

This idea is intended to augment, not replace the existing Telnet functionality - no need to require that the user download a separate utility to communicate - but let him have the option should he desire it.

 

Pretty please? Sugar on top?

[phaeron]

Alright, tracked down the issue with Microsoft Telnet Server. It requires support for Telnet binary transfers and breaks in strange ways if it isn't available. I managed to get it to break the same way with a regular Telnet client by turning off binary support. Telnet Server seems to be marginal in the way it handles a lot of things, including that if you negotiate a VT100 terminal it is very inefficient with the way it does screen updates. Altirra now negotiates two-way binary mode if it receives a request to enter it on the local side. During verification I also found a bug that was causing dropped calls from ForemXEP, which requires the ability to poll control line status prior to XIO 40.

 

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

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

 

There is now also a logging group called "modemtcp" that will report Telnet negotiations.

 

As for talking to an external program... pass. Did that with VirtualDub and it was a big pain in the butt, with the anonymous pipes and a helper program to deal with the mess with inheritable handles. I also found that about half of the programs that were supposed to work in stdio mode and had options to do so were actually broken, because someone just threw it through MinGW on a cross-compile and didn't add or enable the proper code to disable translation on stdin/stdout.

[itaych]

Thanks - the update works. The reason I was trying this at all was to access the Windows command prompt in Ice-T and execute Plink from within, thus being able to SSH with Ice-T as the terminal. It worked, but not very well (weird EOL conversions, misplaced echoes, text not being sent until I press Return...). I then made a similar attempt with Netcat, which seemed to break things similarly. I'll keep trying and post if I have any luck finding some combination that works

Edited December 2, 2013 by itaych

[The Usotsuki]

msys openssh?

[Mclaneinc]

msys openssh?

 

Bless you, here, have a tissue...

[puppetmark]

Thanks for adding Dragon Cart support to Altirra! Very much appreciated. I think that will help get some more development under way. At least, it might peak some curiosity in trying to see what the cart is capable of. I see that the implementation is pretty rough at the moment, but if I can help somehow, just let me know. I have all the technical data literature for the CS8900A and I can test / compare the emulator to the real cart if that helps.

 

Thanks again!

Edited December 3, 2013 by puppetmark

[morelenmir]

Hey guys! I have been away for a good while. Its been a pretty miserable couple of months for me and, as ever Altirra has cheered me up somewhat this evening!

 

My thanks as ever Phaeron for the updates!!! I would have offered them sooner but for some reason I was not receiving update emails from atariage on the Altirra threads. Not your fault of course!.

 

All the Telnet stuff is fascinating. I got really interested in this way back in march 2012, but at that point I think you said you were not going to be focussing on it for a while. Glad to see the comms code get dusted off.

 

On that note, you were talking about the interface a bit ago - is there any chance you will be giving the hotkey setup and debug windowing a fresh look-over soon?