PLATOTERM for Atari ST - A PLATO terminal for IRATA.ONLINE - 0.5 Beta

[tschak909]

Last major feature in, dial directory, now it's all about:

* unwrinkle the redraws
* make it work under MiNT
* add better support for greater than 16 color displays

(animated GIF, click to view)

dial_directory.gif

[ThorstenOtto]

The sources on your website don't seem to contain the last changes yet. Did you forget to push them? So there is a mismatch now between the source archives and the binaries.

New findings: https://github.com/tschak909/platoterms ... ain.c#L159. That immediately terminate the program, and neither restore the palette, nor the iorec pointer. Immedate crashes afterwards.

https://github.com/tschak909/platoterms ... #L348-L349

You are drawing to the menu bar there. That is another nogo.

[tschak909]

Oh no, *blush* I did forget to push the 0.8 changes. I will re-cut the release, tonight

I removed that exit call,

As for drawing to the menu ptr, I had no choice, no space on screen, I can't sacrifice a part of the terminal area for a status bar.

-Thom

[tschak909]

There, the latest changes are in.
-Thom

[ThorstenOtto]

But drawing to the menu bar will not work in Magic or any multi-tasking-aes, and IIRC in geneva there is an option to hide the menubar, or even to display it somewhere else. What you eventually could do is to add an string object there, then redraw it using menu_bar()

other things:

• https://github.com/tschak909/platoterms ... #L104-L108
  
  There is no check whether you overflow platoData or io_buffer. Also, io_buffer seems unneccesary to me, since the same data is also written to the other buffer.
  
• https://github.com/tschak909/platoterms ... #L144-L146
  
  There are 5 errors here:
  
  • Ongibit()/Offgibit accesses the Port A in the soundchip, which is also used for other purposes.
  • The loop is nonsense. Luckily, gcc detects that and completely optimizes it away.
  • To hang up, you should leave the DTR signal in disabled state
  • The DTR signal you want to lower there is only for the MFP. You should not access that when bios-device 1 is configured to use some other interface.
  • The line there is not present on Falcon. You would reset the DSP instead.

Another thing: if i understand it correctly, as long as no network support is present, it currently only works with connecting the serial output to some other PC, and have tcpser run there. You should mention that in the readme.txt i think.

[tschak909]

with the DTR hang-up I was trying to implement a simple sleep, but there isn't an equivalent call in plain TOS.

With some MODEM devices, if you leave DTR disabled, the modem will not accept any commands, so the standard approach that I've always used is to lower DTR for e.g. 100ms, and then bring it back up.

I'll need to understand how to do it for the other interface devices.

-Thom

[tschak909]

As for the buffer, now that I re-arranged some things, the secondary buffer is no longer needed, and I am going to remove it.

[tschak909]

Also, worth noting, a fantastic WIFI modem option can be found here:

https://www.cbmstuff.com/proddetail.php?prod=WiModem232

-Thom

[ThorstenOtto]

with the DTR hang-up I was trying to implement a simple sleep, but there isn't an equivalent call in plain TOS.

It is available in mintlib:

Code: Select all

#include <unistd.h>
usleep(100000); /* in microsecs */


You could also implement it using clock() if usleep() is not available in your library.

I'll need to understand how to do it for the other interface devices.

For Modem2, that is controlled by WR5 of SCC Channel B:

To enable DTR:

Code: Select all

*((volatile unsigned char *)0xffff8c85) = 5; /* select register 5 */
*((volatile unsigned char *)0xffff8c85) = 0xea; /* enable DTR */


To drop it:

Code: Select all

*((volatile unsigned char *)0xffff8c85) = 5; /* select register 5 */
*((volatile unsigned char *)0xffff8c85) = 0x6a; /* drop DTR */


For Serial2, that is similar, just uses SCC Channel A (use address 0xffff8c81 instead). Serial2 is only available on TT and some MegaSTEs. And to add to the confusion, that device is called Serial1 on Falcons, which don't have a 2nd MFP. But as recently verified, that channel is not usable on Falcons without hardware modifcation. So actually, the only available serial interface on Falcon is Modem2.

Another Problem is that there is no way to read the old contents of WR5, so you have to set also the other parameters.

Of course, those routines must be run in supervisor-mode. And you should be sure that the hardware is available.

For Serial1 (the interface driven by the 2nd MFP of a TT), i haven't found any information yet. Maybe that is not controllable by software, and always active.

(Edit: in freemint, the corresponding ioctl() only handles the normal mfp, so it really seems to be not possible)

[tschak909]

can't use mintlib, as it blows up the binary by over 50%. I will implement something using clock().

I guess in the interim, I can always do +++ pause ATH0<cr>

Thanks so much for helping.

-Thom

[ThorstenOtto]

And some more: in your recent version, you changed the layout of the config structure. Since that is directly read/written to the config file, the strings are now messed up if you start the new version with an old config file. You should find a way to make that independent of the program version. For the same reason, using the object indices as "selected_entry" will cause trouble if the RSC file later changes. As a workaround for now, you could add a version number to the file, and reject it if does not match the program version.

[ThorstenOtto]

And after some more tests:

• Still does not work for MiNT. With the original version (leaving in the code that modifies IOREC), it even manages to make ARAnyM coredump. When i disable that code, it hangs on startup (but its possible that this is just because aranym emulates a Falcon and it is using the wrong serial port)
  
• One of your last changes makes sure that the original vdi palette is restored before opening a dialog. Thats nice, but you should also switch back to the current palette when the dialog is closed, otherwise the redraw (that inevitable results from form_dial(FMD_FINISH) will use the wrong colors.
  
• If you can't find a better way to handle the palette issues, i think it would be best to ensure that after a clear_screen, VDI color indices 0 and 1 are what they are supposed to be, white and black. That will avoid lots of flicker, and make sure that the menu bar is usable.
  
• When you open a connection to a host, then quit the program and restart it, you will get lots of garbage on the screen. That is because after a restart, your program is in TTY mode, but the host will send you PLATO commands.
  

[tschak909]

ok, so.. I will add code that checks for mint, and leaves the iorec alone.

will add code to restore palette upon dialog close (will put that right into my dialog handler.) I didn't because my screen clear routine re-maps the palette when it runs...

The code works on a real falcon using serial port 2, apparently (Pete Fletcher tested on his 030 running plain TOS 4.04), so I guess I will add a section to the settings dialog box that allows you to set the serial port.

Again, thanks for digging into this. I owe you at the very least, a hug. if not a beer.

-Thom

[tschak909]

Revised prefs form:

newprefs.png

-Thom

[tschak909]

I've wired up a serial port selector, which ultimately calls Bconmap(); but it doesn't seem to make a dent in Aranym... The changes have been pushed up to repo.

-Thom

[ThorstenOtto]

Yes, that looks quite nice. But you have to change io_hang_up also, that should only be done with device #6. And BTW that line is low-active, so your calls to Ongibit()/Offgibit should be the other way around.

Next step would be to try using gemdos devices (u:\dev\modem1 etc.) instead, that should solve the problems with mint i think, and also make use of the better drivers of hsmodem.

but it doesn't seem to make a dent in Aranym

Yes, that still does not work. Even if i disable certain things (like patching iorec, and the initial emptying of the serial buffer), it either crashes the emulator, or the program crashes with an illegal instruction. But that might be a problem of aranym, or my setup (i don't have a real serial interface on my pc and can only do limited testing with help of a modified tcpser), so this should better be checked on real hardware first.

[tschak909]

ok, will have to look into using GEMDOS devices...

[ThorstenOtto]

You could use the attached version as a start. It does not crash anymore, but is also not yet fully functional (but again, that might be due to my rather strange setup). Currently it starts up normally, but then hangs after displaying the Atari logo from the splash screen. In SingleTOS (without HSMODEM drivers), it works as before.

What also should be done, is to only allow to configure the devices that are actually present.

There is another small thing that i found: in the splash screen, there are commands that cause the protocol to send responses back. Since you are not connected at that point they are just sent to the modem in command mode, which might confuse it. And they are also echoed back on the screen (this are the two "c" that you see after start). Same happens if you click in the window before being connected, which causes mouse events to be sent to the host, and echoed back.

In general, such responses should not be sent until you are connected (and maybe also not when you are in TTY mode).

[tschak909]

The hang, and the additional characters you see, are because of the PLATO echo packets embedded in the splash screen. I keep them in there in development, because it's a good way for me to debug the serial I/O. It's hanging because RTS/CTS is enabled, and it's waiting for CTS to be ready to send the echo packet. I will remove the echo packets from the splash stream before 1.0.

I see the code, will experiment and see what I can make work. Thanks so much.

And yes, for the release, mouse packets will not be sent unless you're in PLATO mode, (I'll go ahead and add that switch once the touch support is finished, I keep it open, again, so I can see the data that goes out.)

-Thom

[ThorstenOtto]

It's hanging because RTS/CTS is enabled, and it's waiting for CTS to be ready to send the echo packet.

Em, no. Rsconf(baud, 2, .....) selects xon/xoff flow control. And it should not block anyway, there are only a few bytes written, and those will even fit in a small ring buffer. During tests i also commented out sending any data completely, so this was is not the reason for the hang.

BTW manually typing in any AT commands after start does not work anymore, because RETURN is now translated to a PLATO key. I think the check for TTY mode has to be done first.

[tschak909]

According to: http://toshyp.atari.org/en/004011.html#Rsconf

ctr Type of flow control
-1: Don't change
0: No flow control [powerup default]
1: XON/XOFF (Control-S, Control-Q)
2: RTS/CTS
3: RTS/CTS and XON/XOFF

and this plays out, as I see RTS/CTS being waggled on my real hardware.

I have checked in a change to do TTY character checking, first, in keyboard_main().

-Thom

[tschak909]

I am testing the io.c over here in my Hatari env, and it works everywhere except Falcon.. does not work with the default serial port setting. changing the serial port doesn't seem to make a dent.

this is a head scratcher...

-Thom

[tschak909]

Interestingly enough, somebody handed me a hard disk image and a hatari config with 68000 MiNT, confiigured on a standard ST with a full 14MB of RAM. It boots, and am able to load PLATOTERM, but no serial I/O...wtf?

-Thom

[ThorstenOtto]

According to: http://toshyp.atari.org/en/004011.html#Rsconf

You are right, i was confused by the Pure-C help, which states it is bit 2. But this is wrong.

I've changed also the corresponding gemdos code to

Code: Select all

      flags &= ~(TF_STOPBITS|TF_CHARBITS|T_EVENP|T_ODDP|TANDEM|RTSCTS);
      flags |= TF_8BIT | TF_1STOP | RTSCTS;


it works everywhere except Falcon. changing the serial port doesn't seem to make a dent.

The new code for using gemdos handles is probably not active there, unless you installed HSMODEM. And don't forget that only modem2 is really usable there.

no serial I/O...wtf?

Which Hatari version? It's possible that serial I/O is not emulated there at all.

[tschak909]

Oh it is. I am using Hatari 2.1.0, and have been using it for development from day 0, it emulates serial correctly on the ST, Mega ST, STE, Mega STE, and TT models, just not the Falcon.

-Thom