Re: [Simulavr-devel] New to the list

[Johan Karel Maria Dams]

Hello.


> Working on a server from remote workstaion could also be done with all the X
> applications, if you have a X server installed on the client system.
> Use cygwin or exceed or any other tool for that. The X data transfer could
> be tunneld also on ssh connections simply with -X option on ssh (unix) or
> with tunnel option on putty windows client.

I know, we do this inside the lab. We have a development server for our 
Robotics projects on which all students compile their projects. This way 
we know for sure everyone is using the same tools etc...

The problem is that our server is on our intranet without a public IP address.
The only way to get there from the outside is to ssh 
into another server first (outside my control) and then ssh from there 
into our server.
I did not have time yet to check out how to get X forwarded like that... 
but I hope it can be done relatively easy.

> simulavrxx provides a gui environment via a normal standard socket
> connection. So you are also able to start a gui on local client and run the
> simulator on a server anywhere. The connection could also be tunneld through
> the ssh connection for security reasons (no idea why we need ssh for
> connecting to a simulator :-).

This would, in our situation, require some port forwarding. I don't have 
access to that server sadly. (Otherwise I would install simulavr there in 
the first place :-)

> All memory regions are transparent to the gdb protocol. So there is no
> special io-registers side hack. I have never used info io-registers with gdb
> but i looked inside the registers with the normal memory operations. I will
> take a look for this item, if I could find any problem I will search for a
> solution. Maybe this is a side hack in gdb, because no special io-registers
> are implemented in simulavrxx. This memory region is used as any other!

ok.

I probably want to make an application like simulavr-disp of the old 
version. I guess this should not be too difficult to interface with 
simulavrxx?

> simulavr is not maintained anymore. If there is anyone interested in, feel
> free to help. But for my opinion it make more sense to complete simulavrxx
> and port it to more platforms then invest time in the very old structure of
> simulavr.

Agreed. Simulavrxx does seem to be better in the long run. Right now I'm 
still using the old one, but I will try to move on to simulavrxx asap.

> Nice to here :-) Feel free to ask for any technical aspects of the project.
> But keep in mind: simulavr is not on my personal list, there
> are a lot of reasons I wrote simulavrxx new from scratch. I cant give
> you any information on the old implementation, sorry.

I was planning on adapting simulavrxx for our personal needs and further 
develop it. I will not develop the old simulavr further, just using it 
now until some issues are resolved.


Best regards,
Johan