* unwrinkle the redraws
* make it work under MiNT
* add better support for greater than 16 color displays
(animated GIF, click to view)
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.
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.
- 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.
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.
It is available in mintlib:tschak909 wrote:with the DTR hang-up I was trying to implement a simple sleep, but there isn't an equivalent call in plain TOS.
Code: Select all
#include <unistd.h> usleep(100000); /* in microsecs */
For Modem2, that is controlled by WR5 of SCC Channel B:I'll need to understand how to do it for the other interface devices.
To enable DTR:
Code: Select all
*((volatile unsigned char *)0xffff8c85) = 5; /* select register 5 */ *((volatile unsigned char *)0xffff8c85) = 0xea; /* enable DTR */
Code: Select all
*((volatile unsigned char *)0xffff8c85) = 5; /* select register 5 */ *((volatile unsigned char *)0xffff8c85) = 0x6a; /* drop DTR */
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)
I guess in the interim, I can always do +++ pause ATH0<cr>
Thanks so much for helping.
- 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.
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.
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.
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.but it doesn't seem to make a dent in Aranym
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).
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.)
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.tschak909 wrote:It's hanging because RTS/CTS is enabled, and it's waiting for CTS to be ready to send the echo packet.
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.
ctr Type of flow control
-1: Don't change
0: No flow control [powerup default]
1: XON/XOFF (Control-S, Control-Q)
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().
this is a head scratcher...
You are right, i was confused by the Pure-C help, which states it is bit 2. But this is wrong.tschak909 wrote:According to: http://toshyp.atari.org/en/004011.html#Rsconf
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;
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.it works everywhere except Falcon. changing the serial port doesn't seem to make a dent.
Which Hatari version? It's possible that serial I/O is not emulated there at all.no serial I/O...wtf?