A600HD, 1 meg of ram, AMOS, and networking...

My problem is kinda obscure, but then again, when my problem isn't that obscure, I can usually figure it out myself... So, gentlemen (and ladies, if any) I need advice.

Back in the days of yore, I had an A500 with a 512k ram expansion, which spent most of it's day running an AMOS application, (essentially, a home automation user interface with bells and whistles) connected by null modem to a PC, and regularily exchanging messages. Said AMOS application would suck up most of RAM and resources of the machine. Eventually that A500 died.

Now I managed to get my hands on A600HD, with a 512k RAM expansion, giving me 1 meg of RAM total, again. I also happened to have a PCMCIA network card, which works fine in that particular Amiga.

I want to modify my AMOS program so that it would exchange messages not over the serial port, but over the net instead, since the backend was written for OS/2 back then and I'd need to rewrite it anyway to resurrect this application. This, however, presented me numerous complex problems:

1) 1 meg of ram is not much. There's no hope whatsoever to get an accelerator or a simple expansion board. I got AmiTCP 2.3 working, however, this leaves me with 512k free memory, leaving me with nothing to debug the program. (the compiled version works fine with AmiTCP loaded, though). There is no way to go back to the non-Pro AMOS to cut back on ram either, cause I need the new instructions. The communication needs are very minor - I just need to send text lines back and forth, and there's no real need for speed at all. Which tcp/ip stack implementation and which version takes up the least ram?

2) I have found at most four ways to make an AMOS program communicate over the net:

• Open an ARexx socket and make an ARexx script do the net communication and send messages to the AMOS Program, with rxsockets.library. This did not work with AmiTCP 2.3 and I'm not sure I have the ram for a newer version.
• Get the Amiga to mount a shared NFS or Samba drive and read-write files on it. I dropped that one cause it looked like it'd suck up even more memory than any other one. Could it be that I'm wrong somehow?
• Try the GUI extension for AMOS Pro (GuiExt162.lha on aminet) which includes some TCP communication commands. Unfortunately, for some reason I can't get the program to compile properly with this. Can anyone tell me what do I need to do beside adding it into the extension list? I don't really need a 'system friendly' application which is that extension's patches to the compiler are all about, so I'd rather not mess with a patched compiler at all.
• Use the procedures found in BSDSocket.lha (see aminet) to communicate to bsdsockets.library directly from the AMOS program and forget about anything else. This would work best! However, the procedures given in this file make use of some unknown AMOS extension, and I can't for the life of me figure out which one it is. It provides some instructions to coax double word numbers into two-byte and four-byte strings, which is needed to make calls to bsdsockets.library. Can anyone shed any light on that?

These problems can possibly be solved easily throuh emulation, yes. However, I'd rather go back to serial port communications, than go straight on to emulate stuff. I'd rather not try to rewrite this in Blitz either.

[patrik]

@Mihara:

The A600 has 1MB chipram as shipped from the factory. You can fit another 1MB in the trapdoor-slot underneath the computer which will give you a total of 2MB chipram.

As you have got AmiTCP2.3 working by yourself it seems you are rather handy and should have no problems with AmiTCP3.0b2 which is the latest AmiTCP released under GPL. It is a bit troublesome to install as the install-script creates a bit faulty startnet-script, but it is mentioned in the notes in the archive what it does wrong.

Anyhow, this version is much more compatible with TCP/IP apps and should work with rxsocket.library.

Woo. Thank you for mentioning that. Really, that helped a lot. I found that the memory expansion board I knew it had in the trapdoor slot was turned off! Now have 1.5 megs chip ram after loading AmiTCP 2.3, which means I can probably install something more flexible without it choking.

Any advice on the software problems, though?

Oh, and which TCP stack should I install to get most apps working and still not chew up the memory too quickly? Which one is most popular and why?

[patrik]

@Mihara:

AmiTCP is a very good choice as long as you have knowledge enough to manage it. It also is the fastest and least memory-eating stack. As far as I know, there is no real difference in memory consumption between AmiTCP 2.3 and the latest AmiTCP 4.3.

Though the old AmiTCP 2.x stacks have some compability issues and the best thing would be if you could get hold of the commercial version 4.1, 4.2 or 4.3 of AmiTCP, but they arent sold any longer and are thus hard to come by.

Anyhow, 3.0b2 is a big step from 2.3 and works with the majority of the user-apps as it is more or less the same as AmiTCP 4.0, so you should give that one a try.

Otherwise as far as compability goes, it is very compatible as it was the first widely spread TCP/IP stack on the Amiga.

All modern TCP/IP stacks on the Amiga generally interface with user-apps in the same way - they create bsdsocket.library which the user-app then opens, so except from a few quirks in some versions of some TCP/IP stacks they are the same from the programmers point of view. There is ofcourse also the amigados TCP: handler you can communicate via, but that is also supplied by most TCP/IP stacks.

Regarding the AMOS programming, the BSDSocket.lha package sounds like the best concept if you could get it to work.

Originally Posted by patrik

AmiTCP is a very good choice as long as you have knowledge enough to manage it.

Well, as long as there's manuals for it, somewhere, I usually can figure it out... Thanks.

Originally Posted by patrik

Regarding the AMOS programming, the BSDSocket.lha package sounds like the best concept if you could get it to work.

AMOS itself includes no instructions to convert anything bigger than bytes into string variables. (If it's bigger, chr$ returns an error, if I remember right.) Which is probably why this package used some unknown extension to do it. Unfortunately, nowere it says which one it is - not in the readme, nor on the alt.religion.amos newsgroup where it was first concieved and published, nor anywhere else on the net I could get at within the last fifteen hours. (Figuring out what exactly these instructions are supposed to be doing took quite some time.) None of the extensions I could find on aminet seems to offer anything like that. (though I might have missed some if it wasn't obviously named - been at it for the last couple of days straight, deep hack mode...)

If all else fails, I could probably make up some crazy procedure with binary operations and chr$, since speed is not an issue when forming library calls to open sockets, however, finding that extension would be a better solution.

@patrick

Just in case you're still watching this thread. I got AmiTCP 3.0b2 working just fine, however, it hogs the cli window it starts in, (which is the one opened for startup-sequence) despite being 'run amitcp:amitcp' and whatnot. It's definitely the AmiTCP process itself that's doing it cause once I 'rx "address AMITCP; KILL;" the window closes by itself.

Searches don't give me conclisive information on what to do with this, (except one odd advice to run it from WBStartup with IconX, which I'd rather not use, since I'd rather not loadwb at all later on, this thing is meant for unattended startup anyway) neither do the docs.

Any clues?

[TjLaZer]

If you wanna get that underbelly ram expansion to 1MB just go looking for some old ass PC video cards. Like 1MB or 2MB ones and see if you can find the chips in a socket. That is how I found some for my A590 and A601 cards.

[patrik]

@Mihara:

Good work!

The cli window hogging is solved if you, in the AmiTCP:bin/startnet script redirect both input and output from/to NIL: for the "run AmiTCP:AmiTCP" and "run AmiTCP:bin/inetd" lines by changing them to "run <>NIL: AmiTCP:AmiTCP" and "run <>NIL: AmiTCP:bin/inetd".

Btw, you probably already know this, but to run the inetd superserver is optional and if you dont need its functionality, you would save you some precious ram by skipping it.

You might already have done so, but to stop it from poping up an extra window for login, you should remove the "AmiTCP:bin/login -f patrik >"con:*/*/*/200/AmiTCP-IP Login/AUTO/CLOSE/WAIT"" line it has added in the "AmiTCP/IP" section of your S:User-Startup script and instead add "AmiTCP:bin/login -f patrik" at the end of your AmiTCP:bin/startnet script. Ofcourse replace "patrik" with your default user .