A2cloud error with proterm

[Cyril Thibout]

Hi Ivan

First thanks for the great job you did with the a2cloud stuff. I just started to test it.

In a Apple IIe with a SSC (terminal mode) in slot1 I managed to communicate to the A2Cloud on the Raspberry PI B
with a serial to USB cable connected to the lowerport of the raspberry PI.

I could access the virtual drive and launch PROTERM.

When I first launched proterm from the virtual drive I selected the following options :
- Modem : null modem RTS
- Super serial card
- No printer


However in the driver configuration of Proterm I must have messed up things
and now when I launch proterm I have the error message:

Volume not online
An error occured accessing
/A2CLOUD/pt3.dial

I re installed a2cloud on the raspberry with the a2cloud-setup but the error remains.

Where should I look at please ?


thanks

cyril

[David Schmenk]

Cyril. for a2cloud and proterm, you will need a second serial port connecting the Apple II and Pi. The reason is one serial connection will be the virtual drives, the second will be the terminal connection. It's not possible to have both the serial drives and terminal connection on the same serial port.

[Leandro Polimeno]

Hi,

I´m not Ivan but think i can respond ... when you have only 1 SSC and use it for remote volume when you try to access Pi via serial you loose the remote volume and Proterm still need it to load some modules. To do what you want you need 2 SSC, start Proterm via a local storage or use a program that load up entirely in memory

Regards,

Polimeno

[Cyril Thibout]

Hello

Thanks, I understand now.

I have two SSC but couldn't I just use one SSC for the internet connection without the vsdrive?

I have a CFFA3000 board and I don't really need vsdrive. On the CFFA3000 I have a Hard drive mounted on the the Compact Flash card.

So can I boot my Apple IIe on the A2CLOUD.HDV image and then lanuch proterm with only one SSC ?

Thanks

cyril

[Leandro Polimeno]

Cyril,

If you copy the A2Cloud image to CFFA, so YES !! Remember to close the ADTPRO daemon, 'who' provide the VSDRIVE, on Pi.

Look at https://groups.google.com/forum/#!topic/comp.sys.apple2/XqBmkevezuU for more information, in your case you still need to alter one config file on Pi, so it can provide acess to 'Linux world' through serial connection.

Regards,

Polimeno

[Cyril Thibout]

Hi
Could you please tell me how I can kill the adtpro deadmon on the Raspbian please ? Is there a way to disable it so that it doesn't start at the boot ?

And why should I alter one config file on Pi, so it can provide acess to 'Linux world' through serial connection ? I didn't find what you were referring to on https://groups.google.com/forum/#!topic/comp.sys.apple2/XqBmkevezuU

thanks !

cyril




Le mercredi 11 mars 2015 13:26:18 UTC+1, Cyril Thibout a écrit :

[Ivan X]

On Wednesday, March 11, 2015 at 2:33:43 PM UTC-7, Cyril Thibout wrote:
> Hi
> Could you please tell me how I can kill the adtpro deadmon on the Raspbian please ? Is there a way to disable it so that it doesn't start at the boot ?

Hi Cyril,

the ADTPro daemon only starts running when you plug a USB-to-serial adapter into the lower USB port, and it automatically is killed when you remove it. However, if you want to be sure, you can type 'adtpro-stop'.

If you use only one USB-to-serial adapter for comm and don't want virtual drives, you need to plug it into the upper USB port. You don't need to change any files on the Pi.

If you have a 3.5" drive or a mass storage card (TurboDrive, CFFA, Focus, etc), you can simply boot from the 800K A2CLOUD disk, and run ProTERM.

If you have only a 5.25" drive, you can instead use the "lite" 140K version of the disk, and use Z-Link rather than ProTERM.

(What you can't do without two adapters, however, is boot from the 5.25" drive and then run ProTERM from the the virtual drive, which is what you've been attempting.)

The A2CLOUD disks can be downloaded here:

http://appleii.ivanx.com/prnumber6/a2cloud-make-your-boot-disk/

Hope this helps.
Ivan.

[Cyril Thibout]

That's perfect Ivan!
Exactly the answer I was waiting for
thanks again

cyril

[Cyril Thibout]

Hi again

I tested it and it works ... but just a bit though :(

I can log in from the Apple II but once logged I get weird display and ther is no carriage return when I press the apple II return key


Should I set the DIP switches on the SSC accordingly to the proterm parameters (speed, number of bits ,etc...) ?
thanks

cyril

[Ivan X]

You shouldn't need to change any dip switches. You probably need to set vt-100 emulation in z-link., and set its connection parameters to 4800 bps. Instructions are on the a2cloud web site under "connect to your apple II".

[Hugh Hood]

Cyril:

I realize that you were able to log in to the Pi from the Apple II (which
suggests that your ProTERM setup is working), but you may wish to double
check that Super Super Card Switch 2-6 (Interrupts) is ON.

Otherwise, ProTERM will not communicate properly, as it relies on
interrupts.

{See page 281 of the PT3.1 Manual for details - Notice how all the switches
are in the ON position except the first (Switch 1-1) and the last (Switch
2-7}.

As Ivan posted, the positions of the baud, data format and parity switches
really shouldn't matter, as ProTERM sets things like baud, data format and
parity by accessing the 6551 registers directly rather than by using the SSC
firmware.




Hugh Hood





in article e37a124f-e886-443a...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 3/13/15 9:03 AM:

[Cyril Thibout]

Hi Hugh

I checked the dip switches and 2-6 was already ON on the SSC. Actually all the switches are on ON except 1-1 and 2-7

the SSC is on the TERMINAL mode and in slot 1

in proterm I set the parameters exactly as shown in the Ivan first Video at http://appleii.ivanx.com/prnumber6/category/a2cloud/

I can communicate with the Raspberry, enter the login and password but after a few seconds the keyboard stops answering and some weird caracters appear on the apple II screen

Where can I get the Proterm 3.1 manual please?
thanks

cyril

[Hugh Hood]

Cyril:

Thanks for checking those things I suggested.

The .pdf version of the ProTERM 3.1 manual is here:

<http://lostclassics.apple2.info/download/InTrec/InTrec_A2-PT31.pdf>

>
> some weird caracters appear on the apple II screen
>

I would double check to ensure ProTERM is using the proper terminal
emulation. If the PI is sending VT100 commands to ProTERM and ProTERM is not
set for VT100 emulation, you will get some strange results. Emulation can be
set either in the 'Dial' settings, or in the Online Parameters.

One other thing to try (which may not matter at all depending on how you are
handshaking between the SSC and your USB-Serial converter on the PI):

Unless you are using your SSC for another purpose, you may also wish (as the
ProTERM manual recommends - page 281) to turn the SSC jumper block to the
MODEM position to allow the CTS/RTS handshaking signals to be passed through
as is. Look at Figure 4-6 on Page 43 of the SSC Manual and see how the CTS
and RTS signals are jumpered together when in TERMINAL position. Of course,
this will require a different cable.

Keep trying. You _will_ get this to work. :-) Let us know what you find
out.





Hugh Hood



in article 5318631b-108b-4823...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 3/16/15 5:07 PM:

[Ivan X]

Cyril, can you clarify: when you say you can log in from the Apple II, do you actually get to enter your username and password, or is it always strange characters from the moment you connect?

[Cyril Thibout]

TO IvanX:
YES I can log from the AppleII. I enter pi/apple2 and I am logged in the linux session.

then I can launch some basic linux commands such as ls or pwd but very soon the lines are scrambled.
after two or three commands the return key desn't answer at all. It really looks like a synch issue.



and yes for Hugh, I am in VT100 in proterm

thanks for your help

[Cyril Thibout]

Hi

According to what I wrote (answering Ivan and Hugh) what do you thing I should look at now please ?

thanks

cyril

[Hugh Hood]

Cyril:

OK, let's see. The short lines (logon / password) come through fine but
commands that send a lot of data to the Apple II (e.g. 'ls') scramble things
up.

This reminds me of what I've seen when one side (e.g. Apple II) is using
software flow control (XON/XOFF - <ctrl-Q> / <ctrl-S>) and the other side
(e.g. Raspberry Pi) is either using hardware flow control (RTS/CTS) or no
flow control at all, and some type of emulation is running that interprets
control characters.

I've seen the <ctrl-Q> / <ctrl-S> characters put the emulation into an
unrecoverable 'scrambled' state, and I _think_ that is the symptom you are
describing.

So,...

1. Make sure (OA-I - Install) your ProTERM modem is set to: Null Modem
Driver (RTS/CTS). (I _think_ that the plain Null Modem Driver may default to
XON/XOFF flow control, and you do NOT want that).

AND,

2. Make sure that in the 'Online Parameters' screen (OA-O) that the fields
'Flow Off:' and 'Flow On:' are both blank. If they contain ^S and ^Q,
respectively, you are using software flow control and you don't want that in
this case. See pages 75 and 217 in the ProTERM 3.1 Manual. This can also be
set in System Parameters if you are 'dialing' rather than just toggling
'online' with (SA-T).


Let us know what happens. Happy modeming. :-)





Hugh Hood





in article ff5ce84f-c7a3-4ad7...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 3/20/15 9:26 AM:

[Cyril Thibout]

Hi Hugh

thanks for this info
1- I already do use the proterm null modem RTS/cts with SSC in slot 1 configuration
2- I already set the Proterm flow off/on parameters to blank. The speed is 4800 and emulation set to DEC-VT100
3- after we passed the login/password stage even a simple command such as a carriage return scrambled the screen. there is no CR, I remain on the same line afer the linux prompt
4- the ssc is set in TERMINAL mode
5- all the switches are on ON except 1-1 and 2-7
6- I get the same trouble with another SSC

thanks

cyril

the SSC is on the TERMINAL mode and in slot 1

[Hugh Hood]

Cyril:

Thanks for working through those steps for me. We can now eliminate several
things as being the source of the issue.

Since short lines cause no issue, I suspect that the issue is related to a
buffer overflow / corruption of some sort.

So,

The only issues that I can suggest now are:

1. USB to Serial Adapter on the Pi.
-----------------------------------
- is it performing properly?
- is it using the proper driver?

2. Serial Cable Between Adapter and SSC Card
---------------------------------------------
- is it wired correctly?


These are trickier things to troubleshoot. Do you have another USB/Serial
Adapter (perhaps another brand/chip set) and driver to try?





Hugh Hood



in article 80f46c9f-8f9a-41f5...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 3/23/15 7:38 AM:

[Cyril Thibout]

Hugh

1- I use this Serial to usb cable : http://fr.startech.com/Cartes-Additionelles-et-Peripheriques/Cartes-serie/Cable-adaptateur-USB-vers-serie-parallele-1s1p-09-m~ICUSB2321284

2- to connect this cable to the Apple II I use a DB25-DB9 adaptor beneath the Apple II such as http://www.fnac.com/mp24314610/Microconnect-db9-db25-f-m-at-xt-ps-2-adapter-0-0m-ada9f25/w-4?ectrans=1&gclid=CK-v0O2Lv8QCFcPJtAoduEEALA&mckv=qVkwOmP7_dc&oref=b0e0a796-3cf2-63a5-3d2d-478a3e34ac64&Origin=CMP_GOOGLE_MP_MICRO&pcrid=50448017663

3- I have no problem with all this set with ADT

4- I had no problem with this set with A2cloud for the Vsdrive (when the usb cable is connected to the lower port of the raspberry PI)

thanks

cyril

Le mercredi 11 mars 2015 13:26:18 UTC+1, Cyril Thibout a écrit :

[Hugh Hood]

Cyril:

Thanks for the additional information on your USB-Serial Adapter. It appears
to use the MosChip - MCS7715 chipset, with which I am not familiar. I see
that it adds not just an RS-232 port, but also a parallel port.

I looked at the driver software bundle that comes with the adapter. It
appears that the Linux version (the other being Windows) of the driver must
be compiled before it is installed on the Pi, but I assume you have already
done that and installed it on the Pi.

Obviously, you have this adapter working with ADTPro/VSDrive, but that may
have more to do with the genius of David Schmidt than with the adapter and
its driver. Schmidt's error-correcting serial protocol seems able to
overcome a multitude of serial communications sins, even including lack of
proper handshaking.

{I wouldn't be surprised if the next version of ADTPro works with (2) soup
cans and a semi-taut string! - Please forgive my humor, Cyril}.

Anyway, at this point, my best suggestion is to try another brand of
USB-Serial adapter (plus its driver). The adapters using the FTDI chipset
always get the best reviews for reliability. In fact, David Schmidt
recommends the FTDI chipset <http://retrofloppy.com/products.html#USBMAC>,
though Ivan (A2Cloud) Drucker reports good results with the genuine (not
cloned) Prolific chipset.

In each instance, the proper driver software will need to be installed on
the Pi.

I realize you would rather not buy something that may not fix the problem,
but the unreliability that you are experiencing _is_ caused by something and
I'm thinking that it is the adapter and/or its driver software. The internet
is filled with reports of USB-Serial adapter users experiencing serial
reliability issues due to the particular brand of chipset / driver used.
Unfortunately, there is inconsistency in their reviews.

I'll grant you that this is a frustrating problem, but we seem to have
exhausted the other possibilities.

Regards,




Hugh Hood




in article 3153c566-5416-4f38...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 3/23/15 1:23 PM:

[Ivan X]

On Tuesday, March 24, 2015 at 12:03:36 AM UTC-4, Hugh Hood wrote:
> Cyril:
>
> Thanks for the additional information on your USB-Serial Adapter. It appears
> to use the MosChip - MCS7715 chipset, with which I am not familiar. I see
> that it adds not just an RS-232 port, but also a parallel port.

Nice detective work, Hugh. I actually have experience with a MOS USB-to-serial (in my case, I tried a dual-headed RS-232 model). The driver is already included in Raspbian (and therefore Raspple II), so it doesn't need installing; however, I found it to be unreliable, so I suspect this is your issue, Cyril. (I guess it's possible it works with VSDRIVE because ADTPro/VSDRIVE has error correction and retransmission, whereas terminal communications do not.)

The Prolific PL2303 based adapters and FTDI based adapters also have included drivers, so no additional installation is required. I've never tried the FTDI, but I think others have; personally, I've had success with three different brands that use the Prolific PL2303 chipset. A perfectly functional and inexpensive legit Prolific model is the TRENDnet TU-S9, which has an Amazon link here: http://appleii.ivanx.com/prnumber6/a2cloud-what-you-need/

(I believe the FTDI is preferred by many and recommended by DaveX because the Prolific has notoriously flaky driver support in Windows, especially when used with the widely circulated bootleg/clone models; however, my understanding and experience is that the Linux drivers are more dependable, even when used with the clone models. I've also had success with the Mac drivers for the different Prolific models I've tried.)

[Steven Hirsch]

On 03/24/2015 06:09 AM, Ivan X wrote:

> (I believe the FTDI is preferred by many and recommended by DaveX because
> the Prolific has notoriously flaky driver support in Windows, especially
> when used with the widely circulated bootleg/clone models; however, my
> understanding and experience is that the Linux drivers are more dependable,
> even when used with the clone models. I've also had success with the Mac
> drivers for the different Prolific models I've tried.)

Based on experiences using this type of adapter for "DriveWire" interface of a
Tandy Coco, I would tend to stick with FTDI. Quite a number of folks have
reported dropped data and errors from Prolific based converters.

[Cyril Thibout]

Hi again

Thanks for all the time you spent trying to solve this problem. I just purchased a FTDI based usb/rs232 converter to follow your advice and will let you knwo the outcome very soon !

thanks again

cyril



Le mercredi 11 mars 2015 13:26:18 UTC+1, Cyril Thibout a écrit :

[Cyril Thibout]

Hi all

I finally switched my previous rs323/usb converter to a ne ftdi one and everything now works as planned !!

thanks for all your time. Now I have a full linux station inside my Apple IIe

cyril

[Hugh Hood]

in article c800b9bc-b8c8-47cd...@googlegroups.com, Cyril
Thibout at in...@pulsar-informatique.com wrote on 4/6/15 8:28 AM:

Cyril:

I'm glad you were persistent and that everything worked out as it should
have.

I wasn't looking forward to falling on my own sword for having given bad
advice. :-)





Hugh Hood

[David Laffineuse]

Hello everyone,

I would like to piggy-back on this discussion to seek assistance with the A2CLOUD setup on my //e as well. I have been able to set this up successfully on my //c but it is proving to be a lot more difficult on the //e.

I have two SSCs (one in slot 1 and one in slot 2), each set up as 'terminal', and connected to the RaspberryPi (RPi) via straight-through cables and USB-to-Serial converters. The SSC in slot 1 (SSC1) is connected to the lower USB port of the RPi and the SSC in slot 2 (SSC2) is connected to the upper port (only 2 USB ports on the RPi model that I have). At this point I can only get Virtual Drives to work via SS1 and the lower USB port if the upper USB plug (the one that is connected to SSC2) is disconnected. If I connect it, then the Virtual Drives no longer work. Likewise, on the //e, I have never been able to get a functioning terminal window via SSC2 and the upper USB port (whether or not the lower port is used). I launch Z.LINK, configure it to look at slot 2, set it to VT-100, etc. and it just doesn't respond. I tested both SSCs and they work. I have tried all the permutations that I could think of but I just can't get terminal emulation to work on the //e.

At this point, and with the clue that plugging in the second USB-to-Serial converster into the upper USB port crashed virtual drives on the lower port, I am wondering if the RPi USB enumeration scheme is not to blame. Here I am thinking that whatever USB device the RPi detects first is assigned ttyUSB0 and the next one is assigned ttyUSB1. If A2CLOUD always expects ttyUSB0 to be the lower port and ttyUSB1 to always be the upper port, then it could be problematic.

Any help that you could provide is greatly appreciated. This has been a puzzling experience on the //e.

Thanks!

David

[Hugh Hood]

in article 98d57bbe-94da-497b...@googlegroups.com, David
Laffineuse at laffi...@gmail.com wrote on 10/5/15 11:50 AM:

David:

I might suggest that you reference pages 280 etc... in the ProTERM 3.1
manual to see the recommended method of setting up your Slot 2 Super Serial
Card for terminal communications with the RaspberryPi.

You will notice that the jumper block is pointed to 'modem', that the dip
switch for interrupts is enabled and that a special hardware handshaking
null modem cable is diagrammed.

The link is here:

<http://lostclassics.apple2.info/download/InTrec/InTrec_A2-PT31.pdf>

You can probably make it work with the jumper on terminal and a
less-than-optimal cable, but ProTERM will require interrupts, and I'm not
sure that your current settings have that.

Something else ... But probably not.

The RaspberryPi, I believe, starts up with the serial terminal set for
115,200 baud. Normally, ProTERM on a IIe maxes out at 19,200. (That can be
increased to 115,200, but I won't complicate things here).

Since, however, you can make the Pi work with your IIc, I suppose you have
already throttled the terminal baud down to 19,200 thanks to the excellent
work of Ivan Drucker's scripts.

Anyway, rest assured that you can make this work. Try a few of these things
and report back. Persistence will pay.

Regards,

[Hugh Hood]

David:

One more thing --

The null modem 'cable' shown on page 285 of the ProTERM 3.1 manual does NOT
hardware handshake. It should get you going, however.

Later, you will want to modify that so that it does hardware handshake,
generally by swapping RTS/CTS. But, one thing at a time. You are still at
the 'proof of concept' stage. No need to tweak it yet.





Hugh Hood

[David Laffineuse]

Thank you very much for the advice. Persistence did indeed pay off because after several days of tinkering and troubleshooting the setup finally works. An SSC in slot 1 for virtual drive access, connected to the lower USB port of the RPi. And an SSC in slot 2 for terminal emulation, connected to the upper USB port. Z.Link and Proterm configurations fought back a bit more but I eventually solved the problems and they are now working reliably enough. I used straight through cables for both SSCs (and the recommended Proterm switch settings) but I will experiment with a null modem cable and the 'modem' jumper block setting for SSC2 to see if that solves some of intermittent issues that I have noticed in terminal emulation mode.

Thanks again.

David

[Ivan X]

I don't know if any of the USB-to-RS232 adapters on the market support hardware handshaking, however. Does anyone know?

[Ivan X]

On Monday, October 5, 2015 at 12:50:01 PM UTC-4, David Laffineuse wrote:

> At this point, and with the clue that plugging in the second USB-to-Serial converster into the upper USB port crashed virtual drives on the lower port, I am wondering if the RPi USB enumeration scheme is not to blame. Here I am thinking that whatever USB device the RPi detects first is assigned ttyUSB0 and the next one is assigned ttyUSB1. If A2CLOUD always expects ttyUSB0 to be the lower port and ttyUSB1 to always be the upper port, then it could be problematic.

It's always going to be unpredictable which USB port is assigned to ttyUSB0 and ttyUSB1 if both are present at startup. (Otherwise, ttyUSB0 is the first adapter attached, and ttyUSB1 is the second.) For this reason, I created aliases called ttyUSBlower and ttyUSBupper, which should always map to the corresponding port, regardless of which ttyUSB# has been assigned to it. (These aliases are only available when using A2CLOUD on the Pi; otherwise you have to just go by sequence of insertion.)

Thanks for identifying that on a //e with two super serial cards, virtual drives run on slot 1, so communications need to happen on slot 2. I'm guessing that VSDRIVE's slot scan picks the lowered number slot first, even though on a IIgs or IIc it picks the modem port.

Ivan.

[Hugh Hood]

Ivan,

It seems the FTDI chip supports it, but it's up to the adapter manufacturer
to implement it.

Where is Schmidt when we need him? :-)






Hugh Hood




in article 1ae1fc84-86ed-4dc8...@googlegroups.com, Ivan X at
ivanx%ivan...@gtempaccount.com wrote on 10/7/15 8:16 AM:

[David Schmidt]

On 10/7/2015 9:31 AM, Ivan X wrote:
> Thanks for identifying that on a //e with two super serial cards, virtual drives run on slot 1, so communications need to happen on slot 2. I'm guessing that VSDRIVE's slot scan picks the lowered number slot first, even though on a IIgs or IIc it picks the modem port.

VSDrive (which uses the same communications backend as ADTPro) will
always pick slot 2 for machines with built-in serial ports (IIc, IIgs,
Laser 128, Franklin 500) as part of its automatic port enumeration. In
the case of multiple SSCs, the logic counts down from slot 7 and
remembers the _last_ SSC it found - which in your case would be slot 1.

[David Laffineuse]

FYI, I also observed (but cannot reproduce reliably) some strange issues with the network connection and with having two Raspis (both setup with RASPApple but with different host names, one connected to a //e and the other to a //c) on the same network. At one point my virtual drive access on the Apple //e was still not working and being out of ideas as to what to try next, I disconnected the ethernet cable from the Raspi...the result was working access to the Virtual Drives. Another time the virtual drive access was not working again so I disconnected the other Raspi on the same network and virtual drive access started to work. That's pretty much when I started pulling my hair out ;-).

[Ivan X]

> FYI, I also observed (but cannot reproduce reliably) some strange issues with the network connection and with having two Raspis (both setup with RASPApple but with different host names, one connected to a //e and the other to a //c) on the same network. At one point my virtual drive access on the Apple //e was still not working and being out of ideas as to what to try next, I disconnected the ethernet cable from the Raspi...the result was working access to the Virtual Drives. Another time the virtual drive access was not working again so I disconnected the other Raspi on the same network and virtual drive access started to work. That's pretty much when I started pulling my hair out ;-).

Don't know for sure why it would affect serial communications, but It might be unhappy having two instances of AFP (Netatalk), SMB (Samba), mDNS/Bonjour (avahi-daemon), and AppleTalk (Netatalk) all trying to do the same thing with the same machine names (even after you changed the host name, there are other settings files for each of these services).

These commands will turn them off, so you can try them on one Pi to see if that fixes anything:

netatalk-stop: stop the netatalk service until reboot
netatalk-start: start the netatalk service
netatalk-restart: restart the netatalk service
netatalk-off: disable the netatalk service (even after reboot)
netatalk-on: enable the netatalk service

appletalk-off: disable AppleTalk networking (even after reboot)
appletalk-on : enable AppleTalk networking

bonjour-off: disable advertisement of shared folders to OS X
bonjour-on : enable advertisement of shared folders to OS X
(these are automatically set by the netatalk commands above)

Samba is disabled by default, and is enabled by typing "a2server-setup" and answering that you want Windows file sharing when prompted; if you've enabled it, there's no single command to turn it off, but you can do so by using "a2server-setup" again and answering "no".

For reference, these commands are shown when you type "a2server-help" or visit:
http://ivanx.com/a2server/a2server_commands.html

Ivan.

[Ivan X]

> Samba is disabled by default, and is enabled by typing "a2server-setup" and answering that you want Windows file sharing when prompted; if you've enabled it, there's no single command to turn it off, but you can do so by using "a2server-setup" again and answering "no".

I take it back, there's also:

samba-off: disable Windows file sharing (even after reboot)
samba-on: enable Windows file Sharing
samba-stop: stop Windows file sharing until reboot
samba-start: start Windows file sharing
samba-restart: stop and restart Windows file sharing

gsfiles-share: disable the GSFILES shared volume
gsfiles-unshare: enable the GSFILES shared volume
a2files-share: disable the A2FILES shared volume
a2files-unshare: enable the A2FILES shared volume

You'd think I'd remember this sort of thing, but, no, apparently.

[David Laffineuse]

I will give those a shot, thanks! On another note, have you ever tried to do a terminal emulation (VT-100) via USB-to-Serial between an Apple //e and a Mac OS machine (10.10.5 in this case). I have an SSC in slot 2 set to modem with a null modem cable to the usb-to-serial. I followed some instructions that I found on http://www.club.cc.cmu.edu/~mdille3/doc/mac_osx_serial_console.html but I can't seem to make it work.

[Hugh Hood]

David:

The guy on the Carnegie Mellon computer club site has done great work with
this, particularly after the change Apple made post-Tiger to how serial
terminals and getties were started up under OS X.

For reasons not important here, I've stuck with Tiger for _most_ Mac OS X
tasks and use the VT-100 terminal emulation with my Macs all the time for a
number of tasks, including Zmodeming files back and forth.

OK, to your question -- why isn't it working?

Have you tried using 'cu' instead of 'tty' yet? I know that even on my Tiger
system that using 'cu' instead of 'tty' made all the difference, and I think
it had something to do with it making the hookup a 'local' connection not
dependent of the status of the DCD line.

From _his_ article:

> If you're using the "tty" device and it's not working, definitely try the "cu"
> device (replacing tty.<device name> with cu.<devicename>, thus using the "cu"
> call-out device instead of "tty" terminal device). This was first reported
> when using somewhat unusual hardware as a Hackintosh, but more recent reports
> suggest this is now the norm. Perhaps it depends on the usb-to-serial driver
> used? I'm seeking input on this, so send me email with datapoints.
>

FWIW, I found this to be the case several years ago on my Tiger systems.

<http://a2central.com/2126/apple-ii-to-mac-intelligent-serial-terminal-file-
transfers/>


Yeah, I _really_ need to update that article, or at least include a link to
Mr. Carnegie Mellon!

Give it a try and let us know.

Regards,





Hugh Hood




in article 4af0f3ae-e30b-4da6...@googlegroups.com, David
Laffineuse at laffi...@gmail.com wrote on 10/9/15 10:57 PM: