Altirra 2.40 Final out..

[flashjazzcat]

...is there any chance you will be giving the hotkey setup and debug windowing a fresh look-over soon?

 

Oh good lord... I just got things set up the way I like them using the current scheme.

[itaych]

As for talking to an external program... pass.

 

I understand your worries, but note that Plink was designed expressly for this purpose (Xming uses it with no problems). However, as Stallman famously quotes Hillel, "If I am not for myself, who will be for me?"

 

I have implemented a bare bones proxy application named tcp2con that does what I described. The source is attached. It runs Plink locally with given command options, and allows an external program to connect to it via TCP, linking the TCP socket to the program's stdio. With this, one can SSH from Ice-T under Altirra. (This can also work for a real Atari and APE, though I haven't tried that.)

 

The application is buggy (see below) and is not user friendly (arguments are hard coded!) so is recommended only to programmers at this point.

 

Here are the steps to use it:

1. Download Plink.exe and Putty.exe from the Putty download page (google it).
2. Modify the COMMAND_LINE in the attached source file to correspond to the location of plink.exe and your desired command line. For example: "c:\plink.exe -ssh username@10.0.0.2". Also change the listening port from 9001 if you like.
3. Build under Visual C++ (I used 2010 but this should work with others too) and run the program.
4. In PuTTY change the default Terminal type string to vt100. The default setting "xterm" will cause Linux to send control codes Ice-T does not recognize. Connection > Data > Terminal-type, fill in "vt100" then Session, click "Default Settings" and Save. Close PuTTY.
5. In Altirra disable "Emulate Telnet protocol". This is only needed because Altirra still sends CR NUL even when no Telnet negotiation takes place - this will hopefully be fixed soon. (Also note that in any case the "terminal type" option has no effect here.)
6. Load Ice-T or any other terminal program in Altirra and type: atdi localhost 9001 <return>. If all went well you should now see the login prompt of the destination machine specified in the COMMAND_LINE above.
7. Plink has two modes of operation. I have no idea why it decides to use one or the other. In one it requests the SSH password in a dialog box that pops up. In the other the request will be inline (in the terminal window). If the latter happens to you, note that you need to hit Ctrl-J instead of <return> after typing your password.
8. Enjoy! You're SSHing from an Atari!
9. However, when the session ends tcp2con will not clean-up properly and will hang (this is the aforementioned bug). You will need to kill and restart it if you wish to use it again.

I'd be happy if anyone with more Windows programming experience can help with the cleanup process. Basically there are two slave threads, one for each direction (tcp to process, process to tcp). The main thread waits for either thread to quit, then closes the socket and kills the process (if it's still up) and waits for the other slave thread to quit as a result. The first thread will quit if there is a TCP error (Altirra hangs up), but the second thread is supposed to quit when the Plink process quits or is terminated - I was expecting an error to be returned from the ReadFile call at line 220 - but it doesn't, and the main thread is waiting forever for that thread to end.

 

Phaeron: Once this bug is taken care of I think you can safely integrate this feature in Altirra. The code is straightforward, is only slightly modified from MSDN examples and seems to work well.

tcp2con.cpp.txt

Edited December 3, 2013 by itaych

[morelenmir]

Don't worry flashjazzcat!!! What I had suggested to Phaeron was not changing the way anything currently works, but just adding more to it.

 

As it stands the hotkeys for working inside the 'source viewer' in the debugger are hard-coded and Phaeron mentioned at some point he was going to overhaul the underlying code so these could be customized like they can in Altirra's other 'views'. I don't think (hope?!) if that were done it would change existing default hotkeys.

 

I also suggested the 'source viewer' window itself be integrated with the tabbed interface of the other debugging panes - or at least made so it remembers how big it was last resized to and where on the desktop it was last moved. It is quite tedious to have to resize and move it every single time you start a session of Altirra through a 'WUDSN/Eclipse' compile and debug command. Obviously not all cross-assemblers produce all the data files necessary to run a 'source level debugging' window and step through the code... But since you and some of the other chaps convinced me to start using MADS (which obviously does) over ATASM (which definitely doesn't!) I must admit I would hate to go back to being without it!!!

[phaeron]

 

I understand your worries, but note that Plink was designed expressly for this purpose (Xming uses it with no problems). However, as Stallman famously quotes Hillel, "If I am not for myself, who will be for me?"

 

I have implemented a bare bones proxy application named tcp2con that does what I described. The source is attached. It runs Plink locally with given command options, and allows an external program to connect to it via TCP, linking the TCP socket to the program's stdio. With this, one can SSH from Ice-T under Altirra. (This can also work for a real Atari and APE, though I haven't tried that.)

...

Phaeron: Once this bug is taken care of I think you can safely integrate this feature in Altirra. The code is straightforward, is only slightly modified from MSDN examples and seems to work well.

 

I'm sorry, but this is far from what I would consider a shippable implementation. This particular MSDN sample is known to be problematic, as the long list of comments at the bottom of the article indicates. The practical problems include:

• It uses inheritable handles. This is known to be unreliable and causes random bugs due to other handles unintentionally getting cloned into the child process. For instance, a shell extension can open a file, which then gets cloned into the child and consequently causes that file to stay locked. You can get away with this in a small console application, but not in a GUI application.
• It uses blocking I/O on the read pipe handle. This means that the worker thread servicing the read pipe cannot exit until the child exits, which leads to deadlocks. Solving this properly requires overlapped I/O.
• It doesn't monitor the child process for abnormal exit or have a way to signal the child process to exit (send Ctrl+C signal).
• IIRC, there are additional problems with this method revolving around sporadic truncated output when the child exits that require some awkward workarounds (something like a 1 byte pipe).

VirtualDub's implementation is three times as long as this and only handles one-way buffered communication, not two-way interactive as Altirra would require. It also requires an intermediate console helper to fix the inheritable handle problem.

[itaych]

Fair enough. This will remain an external helper app for anyone who wishes to use it. I've fixed the hang bug and added command line parameters, so it's a lot more user friendly now. Since it is not Altirra specific but useful for users of APE as well as Altirra, I have moved it to the Ice-T thread. The relevant post is here.

[flashjazzcat]

Got some odd results using SDX folder imaging while developing today which are presumably caused by cached sectors not being invalidated when a file changes. Target file is closed when changed, but only by rebooting SDX could I be sure I was loading the freshly compiled build of the application. I'll do some more tests tomorrow.

[flashjazzcat]

Noticed this rather odd trail left by the raster beam while single-stepping:

 

Edited December 11, 2013 by flashjazzcat

[Xuel]

Looks like you have interlace enabled, so you're seeing two different frames interlaced, one before the drive menu is erased and one after.

[flashjazzcat]

Looks like you have interlace enabled, so you're seeing two different frames interlaced, one before the drive menu is erased and one after.

Brilliant! You're absolutely right. I'd never have thought of that.

[flashjazzcat]

Well, finally got my new Linux Mint 16 install up and running, and I still can't get Altirra to use a CF card as a hard disk image. Never mind write capability, I can't even get the same read functionality I enjoy in Windows 7. Puzzling. Other than that, everything works great in Wine, once I'd sorted out Wine's audio settings (until I'd done that, Altirra was running REALLY slowly).

Edited December 15, 2013 by flashjazzcat

[phaeron]

Added SIO-level 850 emulation and a 6502-based relocatable R: handler:

 

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

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

[w1k]

why OK button doesnt work if i want change IP?

[phaeron]

That's the network address, not IP address -- you need to enter 192.168.104.0. The IP stack running in the emulator will be what determines the IP address, not the emulator itself.

[w1k]

submit OK button is impossible..

[jacobus]

Phaeron

 

Not sure if this has been asked before, but would it be possible to set the speed of the emulator from within an Atari program itself? I'd love to be able to set the emulator to full speed during the initialization phase of my program and then return it to regular speed for normal operation. I was thinking about one of the "unused" bytes such as 563 or 651 (decimal) - Altirra could watch for either a specific value, or a series of values to trigger the speed change. On real hardware, this would have no effect of course, but under emulation it would save lots of time!

 

Altirra is a fantastic program! Many thanks!

[phaeron]

Grab bag update:

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

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

 

This fixes another D3D11 related crash, adds a workaround for a display rotation problem on tablets, improves responsiveness to touch input and adds a bottom-up swipe gesture for the on-screen keyboard, fixes Micropainter load with SIO patch enabled, adds the ability to mount an .ARC file as a SpartaDOS disk and format new disk images as SDFS, fixes a regression with Alt+key shortcuts also dropping down menus, and expands the Help file to include better device-specific help.

 

Regarding controlling the emulator speed from an Atari program... currently, no. I don't like to expose emulation features to the emulated program that aren't related to hardware -- the point is to emulate actual hardware, not virtualized hardware that's just reminiscent of it. Allowing the emulated program to request warp speed on demand is counter to this philosophy. If it was something like emulating 65C816 accelerator hardware that had a speed switch in it, I'd be more amenable to that. '816 accelerators are all over the place with regard to availability and functionality, though, so I haven't gone anywhere on that front yet.

 

Now, what I have considered is exposing this kind of functionality for debugging purposes, as there are just some things that the emulator can't do by itself poking at the black box that is 6502 code. Besides speed alteration, there a few other things that would be nice to expose, like reporting dynamically loaded modules so the debugger can match symbols to relocatable code. I've been thinking of a combination of cartridge port and SIO device interfaces for this kind of functionality. Regardless, though, it's unlikely that I would ever enable this by default as it would cause compatibility issues and might possibly not even be safe depending on whether any of the functions could break out of the sandbox.

[Mclaneinc]

Have to say I love the idea of Jacobus, demo's etc could look amazingly fluid etc but I also respect the core ideal for the emulator that you stand behind, obviously we don't want something that would cause incompatibility, you and only you decide what goes in.

 

Another Western year comes to an end and Altirra goes from strength to strength...Thank you..

[w1k]

crash if i want run IP65_RealDOS_30

 

 

files.zip

[Rybags]

I tend to agree, speedup as in emulating more cycles per scanline that exist other than doing 65816 @ emulated 7/14 MHz is taking away from the spirit of things and has potential for people to start writing stuff that just doesn't work on real hardware.

 

Turbo mode is a different kettle of fish though, I use it often if doing little Basic programs to generate data or convert graphics, or on those occasions where I want to do a quick assembly the old fashioned way.

 

What might be an idea is to have another device handler patch similar to existing P:, H: etc that create virtual devices beyond the usual.

The thinking I have is allow emulated programs to send certain commands through to the emulator as if the user entered the commands themselves.

Such inclusions might be turbo on/off, and ability to set certain traps or start traces or dump parts of memory to file.

[Roydea6]

Altirra Crash Double click Icon

Altirra Crash -portable

Altirra Crash -help

Altirra Crash -resetall

 

AltirraCrash.zip

[phaeron]

Should be fixed now:

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

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

[NRV]

The last versions show a small row of "one pixel noise" at the end of every line in the original ProjectM 2.0 demo (I downloaded it from the original thread just to be sure that is not a local problem).

So is this the correct behavior or some small bug? I remember that at some point you talked about a small one cycle difference between some machines, but don't know if that has something to do with this.

 

Regards.

[jacobus]

Regarding controlling the emulator speed from an Atari program... currently, no. I don't like to expose emulation features to the emulated program that aren't related to hardware -- the point is to emulate actual hardware, not virtualized hardware that's just reminiscent of it. Allowing the emulated program to request warp speed on demand is counter to this philosophy. If it was something like emulating 65C816 accelerator hardware that had a speed switch in it, I'd be more amenable to that. '816 accelerators are all over the place with regard to availability and functionality, though, so I haven't gone anywhere on that front yet.

 

 

Thanks for responding and making this clear - I guess I'll have to optimize my code the hard way! :-)

 

I tend to agree, speedup as in emulating more cycles per scanline that exist other than doing 65816 @ emulated 7/14 MHz is taking away from the spirit of things and has potential for people to start writing stuff that just doesn't work on real hardware.

 

Turbo mode is a different kettle of fish though, I use it often if doing little Basic programs to generate data or convert graphics, or on those occasions where I want to do a quick assembly the old fashioned way.

 

I use the Turbo extensively for compiling - what I had in mind was an ability for the Atari application to active turbo mode, rather than creating a faster (under emulation) Atari.

[flashjazzcat]

Just press and hold F1 when loading or executing lengthy processes. That's what I do when developing/debugging/optimising.

[+therealbountybob]

One Altirra gripe I have is that when playing/testing something using ctrl for fire (yes I could re-map it) and I want to use F1 to speed up intermittently - it's a pain that Ctrl-F1 toggles the screen settings. Perhaps the Warp Speed could be moved to another F key