@kas1e & pjs

The PORT, KEYFILE and MAXSB all need to have the keyword specified to work (that's what the /K in the AmigaDOS command template means).

The PORT argument only needs to be specified if the ssh port is changed from the default 22.

@kas1e

Quote:

Running "ls -la" in either ~ or /bin (both have quite a large amount of files in them) is near instantaneous on my Tabor machine (I don't have my Sam460 connected so can't test there ATM).

@pjs

Quote:

Does the ssh server allow other authentication types? If so SSHTerm will use them first instead of public key authentication.

In ssh2-handler I made the KEYFILE option force use of public key method if it is supported by the server, but this code doesn't seem to have made it into SSHTerm for some reason.

I have my ssh servers set to only allow public key authentication as this method is more secure than the other ones.

Version 1.1 of SSHTerm is now available at github:

https://github.com/salass00/sshterm/releases

@flash

You can compile gcc 6.4.0 from adtools:

https://github.com/sba1/adtools

Just replace "bin/gild checkout gcc 8" with "bin/gild checkout gcc 6" if you are following the instructions there.

@BobSacamano

Is this with Andrea Palmate's newer port? If so, you could try one of the older versions from os4depot.

Newer versions of Battle for Wesnoth have much more graphical effects and animations so they are more CPU intensive.

@Raziel

That's about how big the stack is according to the crashlog, but it seems not to be enough.

@samo79

Quote:

According to the disassembly it is allocating more than 682kb of stack, causing an overflow as the program stack is not big enough.

Try giving it a bigger stack and running it again.

@corto

When using bl you need to save and restore the link register or the blr won't return to correct point in the program (kas1e gets away without because of the call to exit which never returns).

Basically you need to do:


Since the function call is at the end and the stack is not used you could also get away with just:

@Mazze

Unless I've calculated wrong it's -300 for Strlcpy() and -306 for Strlcat(). Strlen() does not have an LVO and is only available to PPC programs.

It is also unlikely that there are any m68k programs using the Strlcpy() and Strlcat() functions as they are not available in earlier AmigaOS versions than 4.0.

@LiveForIt

Quote:

I'm not very familiar with the animation.datatype API but judging from the adtFrame and adtNewFormatFrame structs you should be using IDoMethodA() instead of DoDTMethodA().

DoDTMethodA() is a thin wrapper on top of DoGadgetMethodA() which expects the field immediately after MethodID to be a pointer to a GadgetInfo structure that it will initialize before passing the message on to IDoMethodA().

Since in struct adtFrame/adtNewFormatFrame this slot is taken up by the alf_TimeStamp field it means that this value ends up being overwritten before the message gets to the animation datatype subclass.

Resizing of the terminal window is now mostly supported. What is missing still is code to request a new size from the remote host.

In implementing this I ran into a few problems that should be fixed now.

First off GM_LAYOUT which notifies the termgclass that it now has a new size is called from the context of input.device even if LAYOUT_DeferLayout is TRUE. This caused problems with the newlib memory allocation routines because they rely on the pr_CLibData field which does not exist for a task. After trying a few different workarounds the easiest solution I found was to just use a custom memory allocator, which for now is based on dlmalloc (same as newlib.library one) but a little simpler.

One of the other solutions I tried was to use clib2-ts, but clib2's UTF-8 support is too lacking and it made the executable a lot bigger, so I scrapped that idea.

The other problems were cosmetic in that libtsm would add empty lines when the window was made bigger, when it could have simply moved in lines from the scrollback buffer, and also when the window was made smaller these empty lines would not get removed resulting in unnecessary scrolling.

I've fixed those problems as well now, however it took a very long time as I made quite a few mistakes along the way and every time it would crash it would hard lock the computer without producing any useful GR or stack trace because the crashes were in GM_LAYOUT on input.device context.

@kas1e

There is some h/w acceleration if you use amigaos surfaces to draw into. It is just solid coloured shapes though, and if you enable anti-alias only drawing of rectangles is h/w accelerated.

Probably much more could be done by writing a compositor using Warp3D Nova, though I haven't really looked into it yet (right now I have other projects that I want to work on).

The amigaos surfaces are created using the cairo_amigaos_surface_create() and cairo_amigaos_surface_create_from_rastport() functions (in <cairo/cairo-amigaos.h>).

Scrolling now uses a separate refresh type, which uses ScrollRasterBF(), and is much faster because of it, and really responsive on the Sam460 I use for testing.

BTW, assuming that you have a new enough z.library (V53.5) and AmiSSL (V4.3) installed it even works under 4.1 update #6 (I just tested it).

I had to make some small extensions to the libtsm API, but it is now possible to attach a scroller to the termgclass terminal display and use it to scroll within the libtsm scrollback buffer.

It is a little slow on my Sam460 at the moment given that it's redrawing every cell of the terminal display, but I'm hoping that I can make the incremental scrolling faster by using ScrollRasterBF() and only redrawing the new lines and any damaged window regions that are exposed by the operation (if the window is partially covered up by another one).

@smf

I haven't decided yet.

While the idea of releasing a program on AmiStore for a small fee does have some appeal to me, not least because I could use the money, it might be too much of a niche product for that to be worth it though.

@kas1e

Since get_id() is defined as an inline function with code directly in the <thread> header file I don't think it can be replaced without modifying the header file itself.

@kas1e

Unless you need to support tasks for some reason, it is better if you use getpid() (or IDOS->GetPID(NULL, GPID_PROCESS)) instead of IExec->FindTask(NULL).

It returns a numeric ID for the current process that is guaranteed to be unique and is supposed to be used for this purpose.

Marking text with mouse and copy to clipboard with RAMIGA+C (or Edit->Copy from menu) is now supported and paste operation is currently being worked on.

Initially marking text was extremely slow due to the libtsm functions involved forcing an update of the entire terminal display, but after rewriting the aging code so that it only updates the cells that have changed it is very fast and uses very little CPU.

Menus are also now implemented, as is iconification for the terminal window (very easy to do now that I'm using window.class).

@kas1e

Quote:

No, that is not what I meant because I had not even looked at that part yet, but that makes it even worse.

This code is clearly not written to be portable to different CPU architectures (not ones that don't allow unaligned accesses anyway).

The best solution that wouldn't require any hacks would be to remove __attribute__((packed)) from all the structures and then rewrite the loader so that it reads one field at a time (this could be done with helper functions that could also handle the endian conversion). Then no unaligned memory accesses would be necessary.

@kas1e

You could reduce the optimization level for a specific function using __attribute__((optimize("O2"))) (assuming that -O2 works correctly).

The vertices structure looks like it's also unaligned so some kind of fix is needed there as well.

The rewrite of the keyboard input handling is done now, and it's using the new tsm_vte_handle_keyboard_amiga() function.

Not all of the special keys are implemented but of some that are they are working much better now (i.e. correctly).

A new problem that I have yet to get to the bottom of though, is that every time I type a letter the cursor moves to the start of the command line prompt which means that if I write "exit" it comes out as "tixe" instead.

Edit: The problem was because I was lazily assuming that the output data would always be NUL-terminated as with libtmt. With single characters it isn't so a stray '\x01' character was always sent as well.