TIPI Usage and Support

[+arcadeshopper]

1 hour ago, wolhess said:

Today I had some problems with my BBS system to write a message. After I made a fresh SD card and copied all the files back the BBS works fine also with long messages. The problems comes only when I had a power loss without doing a shutdown.

 

this is possible to resolve without a reimage..  but files may get corrupt if they are open when power is lost 

[+Vorticon]

19 hours ago, wolhess said:

on the Ti I use only the back arrow FCTN+S.

I tried FCTN-S and CTRL-Q and while they do erase characters, the cursor itself moves to the right instead of to the left. It took me a while to realize that

That's an old behavior legacy Basic's... Is there a way to configure the tipi telnet to move the cursor to the left when backspacing?

[+9640News]

11 minutes ago, Vorticon said:

I tried FCTN-S and CTRL-Q and while they do erase characters, the cursor itself moves to the right instead of to the left. It took me a while to realize that

That's an old behavior legacy Basic's... Is there a way to configure the tipi telnet to move the cursor to the left when backspacing?

It sounds like Fctn-S and Ctrl-Q may be sending more than one character to the server instead of being interpreted as a single byte.  Unless you are in a half-duplex mode which I do not think is even in Matt's TIPI Telnet client and rare to be seen from other telnet servers, it is the Telnet server itself that receives the character and then echos it back to you where the display routines control the cursor movement.  I'm guessing one character that is sent is a non-displayable character, then you have the other character.  I think some of it depends upon the particular keyscan mode one is in how things get interpreted.

 

I know it can be complex as I had to write some specific code to handle the arrow keys for up/down/left/right for the Geneve keyboard in MDOS mode with MyTerm so the servers on the other end would respond correctly.

 

Beery

 

 

 

 

 

[wierd_w]

RE: BBS filesystem issues due to power loss

 

Since the hat is stackable, I would suggest getting an RPI UPS.

 

Something like this, or similar.

 

Then your pi can detect that main +5v has stopped supplying, and initiate a graceful shutdown.

Edited August 28, 2020 by wierd_w

[Omega-TI]

Personally, if size is not an issue, you could get more bang for less bucks by getting << one of these >> and run that Pi for a LOT longer!

 

[wierd_w]

Yeah, but then you have to hope that the UPS can send some kind of signal the Pi can recognize, so that it can gracefully shut down.

 

This is a BBS, after all. Leaving it unattended is kinda the use case.  It needs to react to having the power go out, but do so in a safe and consistent manner.  The various UPS pi hats out there can send a useful signal over one of the GPIO pins to the Pi to alert it that it has started using battery, and is supplying power.  This can trigger a graceful shutdown script.

 

 

That one was just very well made; there are some that run on just some AA batteries!  Any that supply a suitable "Now using batteries!" message would work.

[+arcadeshopper]

3 minutes ago, wierd_w said:

Yeah, but then you have to hope that the UPS can send some kind of signal the Pi can recognize, so that it can gracefully shut down.

 

This is a BBS, after all. Leaving it unattended is kinda the use case.  It needs to react to having the power go out, but do so in a safe and consistent manner.  The various UPS pi hats out there can send a useful signal over one of the GPIO pins to the Pi to alert it that it has started using battery, and is supplying power.  This can trigger a graceful shutdown script.

 

 

That one was just very well made; there are some that run on just some AA batteries!  Any that supply a suitable "Now using batteries!" message would work.

yeah any linux machine can be configured to autoshutdown with a modern ups and a usb cable 

 

Greg

[curtludwig]

The power draw off a PI is pretty small, we're talking a max of say 2a @ 5v so maybe 10w at the most. Get a buck converter that has USB ports and 35ah wheelchair battery from Harbor Freight. That'll give you 20+ hours of run time without damaging the battery for less than $100

[+jedimatt42]

12 hours ago, Vorticon said:

I tried FCTN-S and CTRL-Q and while they do erase characters, the cursor itself moves to the right instead of to the left. It took me a while to realize that

That's an old behavior legacy Basic's... Is there a way to configure the tipi telnet to move the cursor to the left when backspacing?

 

11 hours ago, BeeryMiller said:

It sounds like Fctn-S and Ctrl-Q may be sending more than one character to the server instead of being interpreted as a single byte.  Unless you are in a half-duplex mode which I do not think is even in Matt's TIPI Telnet client and rare to be seen from other telnet servers, it is the Telnet server itself that receives the character and then echos it back to you where the display routines control the cursor movement.  I'm guessing one character that is sent is a non-displayable character, then you have the other character.  I think some of it depends upon the particular keyscan mode one is in how things get interpreted.

 

I know it can be complex as I had to write some specific code to handle the arrow keys for up/down/left/right for the Geneve keyboard in MDOS mode with MyTerm so the servers on the other end would respond correctly.

 

Beery

 

 

 

 

 

 

My telnet code doesn't move the cursor... it sends a backspace. The program you are interacting with on the other end of the telnet session is responding to the backspace with something weird. What are you running? Bash?  A few years ago, backspace worked correctly in bash on Raspbian.   

 

https://github.com/jedimatt42/tipi/blob/1ea33e66d7209a47d5defbbee2fe5d7da24af3aa/examples/telnet/terminal.c#L538

 

The code is written to send a standard backspace on left-arrow.  My TI keyboard has a backspace button which is the same as FCTN-S.

 

The code reads the 4A keyboard in mode 5. 

 

Notice how the telnet code is in the github repo under examples.  That expresses the value of this code to me. it is meant as an example so people can see how to use the socket layer. You could consider the source a giant config file, and edit it. 

 

Linux has an stty erase 0x08 command that can be used to reconfigure some thing... I would try that first. 25 years ago, I used ^h on some systems as a backspace. hmm... I tried and it just doesn't work. There is no local echo, so this will take debugging.

 

 

 

[+jedimatt42]

5 hours ago, jedimatt42 said:

 

 

My telnet code doesn't move the cursor... it sends a backspace. The program you are interacting with on the other end of the telnet session is responding to the backspace with something weird. What are you running? Bash?  A few years ago, backspace worked correctly in bash on Raspbian.   

 

https://github.com/jedimatt42/tipi/blob/1ea33e66d7209a47d5defbbee2fe5d7da24af3aa/examples/telnet/terminal.c#L538

 

The code is written to send a standard backspace on left-arrow.  My TI keyboard has a backspace button which is the same as FCTN-S.

 

The code reads the 4A keyboard in mode 5. 

 

Notice how the telnet code is in the github repo under examples.  That expresses the value of this code to me. it is meant as an example so people can see how to use the socket layer. You could consider the source a giant config file, and edit it. 

 

Linux has an stty erase 0x08 command that can be used to reconfigure some thing... I would try that first. 25 years ago, I used ^h on some systems as a backspace. hmm... I tried and it just doesn't work. There is no local echo, so this will take debugging.

 

 

 

 

 

Yep, so I pressed backspace after the 'o' in hello, and then sent the output to hexdump... the backspace took, the 'o' is gone, but the display decoding is all buggered. So.. not sure how to capture what is being sent, other than turning on byte level tracing of TIPI messages... so... maybe someday...  I'd rather finish working the API for ForceCommand, which encapsulates the terminal handling code, and fix it there, and then rebuild a working telnet on top of that API... 

[Nick99]

At last, I have updated my SD cards to the 2.5 version. 

I have to TIPI-systems, one TI-99/4a and a Geneve, before the 2.5 update I renamed one system to TIPI2 by following the steps mentioned somewhere on this thread.

The problem now is that I can´t do this rename process, when I start the PI it boots and suddenly the screen get black and the TV says it has no input signal, therefore I can´t do the rename process on the PI.

Also, due to the same situation I can´t change the TIPI password.

 

What to do?

 

My Imac seems to not allowing me to connect and give commands on Terminal to the TIPI on my network, so I will probably have a hard time to manage it that way.

 

A few weeks ago I saw (if I remember correct) that someone on this forum could connect to the PI with the TI-99 and config the system, or was that on the TIPI-emulation thread?

 

Please enlighten me with your TIPI-wisdom! ?

 

[wierd_w]

Connect to the second tipi using SSH (via something like PuTTY), and do the rename that way.  Connect direct to its IP address.

[+Vorticon]

12 hours ago, jedimatt42 said:

 

 

Yep, so I pressed backspace after the 'o' in hello, and then sent the output to hexdump... the backspace took, the 'o' is gone, but the display decoding is all buggered. So.. not sure how to capture what is being sent, other than turning on byte level tracing of TIPI messages... so... maybe someday...  I'd rather finish working the API for ForceCommand, which encapsulates the terminal handling code, and fix it there, and then rebuild a working telnet on top of that API... 

The problem is only in the main rpi shell (I assume bash). Once you are in an application, the latter responds correctly to the backspace code being sent. 

[+jedimatt42]

seems like it isn't just my terminal:  https://github.com/msys2/MSYS2-packages/issues/1124

 

in bash, changing the term type seems to help... 

 

export TERM=xterm

 

 

[Nick99]

8 hours ago, wierd_w said:

Connect to the second tipi using SSH (via something like PuTTY), and do the rename that way.  Connect direct to its IP address.

Worked out well, thanks!

[+jedimatt42]

@Nick99 - the above thread is maybe poorly named, but it is about developing software on the Geneve. Not TIPI usage. The issue you posted is a usage issue. So I'm referencing it, and answering it here.

 

The problem you stated, in short, is that you have a ROMPAGE mode error using a TI Floppy Controller in a Geneve, and you are mystified by the TIPI disk mapping not working when at a CRU base that is not prior to the floppy controller... 

 

You have multiple problems:

 

1st, the TI Disk Controller does not work in ROMPAGE mode on a Geneve. That has been my experience, and the people that claim to know, only have vague memories. It seems no one curated documentation of what does and doesn't work with a Geneve.

 

2nd, the TI Disk Controller DSR is not designed to pass control on to high CRU addressed devices even if it did work in ROMPAGE mode. If you want TIPI disk mapping, you will need to run the TIPI at CRU base address >1000 as this is the only CRU address base below the floppy controller's >1100 address base. Geneve or otherwise.. that's how to TI architecture works. 

 

[Nick99]

Thanks for the clarification @jedimatt42, rompage is new to me as a few other Geneve utilities and software, even if they existed in the mid 90´s when I packed down my Geneve I have never heard of them until lately.

So at this point it´s software limitation on the Geneve, I might start a "Geneve for beginners" thread. ?

 

Thanks!

 

[+mizapf]

It would be great if we collected such information on Ninerpedia, those things quickly get lost in forum. I'll be happy to set up some more accounts.

 

Is there any information about the reason why ROMPAGE fails for the TI disk controller? The controller operation is not terribly complicated. I cannot really imagine timing problems because the timing is simply done by the READY line, and this works likewise well for the TI-99 as for the Geneve.

 

I once tried to check it and replaced my DDCC-1 with the old TI controller, but it seems to be broken; I could not make the Geneve boot with it.

 

The Geneve boot EPROM should give a hint, because it obviously has low-level routines which work for the TI controller. Could be a matter of comparing the DSRs.

[+9640News]

Moving response to the topic area Matt referenced.

 

Edited August 30, 2020 by BeeryMiller
Moving response to another topic

[+InsaneMultitasker]

Historically, rompage was "intended" to give the Geneve user a means to access the HFDC (and later, SCSI) low level routines within GPL (i.e., TI emulation mode) for the few programs that needed it. This is done by exposing the external bus to the 0x4000-0x5fff local memory space.

 

Full support for the floppy controllers was baked into the OS long ago.  The few floppy-disk applications that benefit from rompage are track copiers and PC-transfer, programs requiring direct access to the controller IO ports, and there timing is often a challenge. 

 

While TIPI and a few other cards certainly can benefit from rompage (with certain caveats) let's not elevate rompage to swiss army knife status.  It is never going to be the full/sole solution to every peripheral integration challenge.

 

I could not find the topic but someone recently released commented source code for the TI Disk controller (among other things) and I recall certain timing and signal settling that seemed pretty tight.   I expect that one reason for the Geneve boot EPROM's low-level FDC IO implementation is that the floppy dsr would have require changes to work out of the box, and it was far easier to roll the code once versus ask people to upgrade their eproms.

[+mizapf]

1 hour ago, InsaneMultitasker said:

I expect that one reason for the Geneve boot EPROM's low-level FDC IO implementation is that the floppy dsr would have require changes to work out of the box, and it was far easier to roll the code once versus ask people to upgrade their eproms.

As I stated some time ago, I'm dreaming of a completely revised boot EPROM that does not need to contain low-level routine if it were possible to load at least one (small) file from the floppy. This would contain the next stage bootloader, which we could customize more easily.

 

But this means that I need to be able to load a file by the card DSR. I'd have to do a lot different if I cannot rely on that.

 

As I said, maybe we could compare the TI card DSR with the low-level routines in the EPROM. I don't know of any hard timings inside the DSR, and I cannot guess what it could be, because the timing is essentially done by controlling READY via the controller chip. There is nothing like e.g. waiting for the address marks actively; this would not work.

[+InsaneMultitasker]

13 minutes ago, mizapf said:

As I said, maybe we could compare the TI card DSR with the low-level routines in the EPROM. I don't know of any hard timings inside the DSR, and I cannot guess what it could be, because the timing is essentially done by controlling READY via the controller chip. There is nothing like e.g. waiting for the address marks actively; this would not work.

Probably a topic for another thread. As I mentioned above, there are comments in the DSR source code related to timing and settling - not timing loops - that need to be considered as part of the review. My comment was not limited to READY logic.

[webdeck]

I figured out an issue I was having when uploading a number of .dsk images using the web UI.  I was puzzled why some of them would not be recognized as proper disk images.  Apparently, the issue was that they had the same disk name as an existing directory.  I see that when that happens the first time, the second directory gets named with an _1, but if there is already a _1 version, then it silently fails.  Would it be possible to have it keep incrementing the number?  Otherwise, I need to ssh in and rename the conflicting directory and re-upload the .dsk image.

[+arcadeshopper]

I figured out an issue I was having when uploading a number of .dsk images using the web UI.  I was puzzled why some of them would not be recognized as proper disk images.  Apparently, the issue was that they had the same disk name as an existing directory.  I see that when that happens the first time, the second directory gets named with an _1, but if there is already a _1 version, then it silently fails.  Would it be possible to have it keep incrementing the number?  Otherwise, I need to ssh in and rename the conflicting directory and re-upload the .dsk image.

This is a bug it should increment

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

57 minutes ago, webdeck said:

I figured out an issue I was having when uploading a number of .dsk images using the web UI.  I was puzzled why some of them would not be recognized as proper disk images.  Apparently, the issue was that they had the same disk name as an existing directory.  I see that when that happens the first time, the second directory gets named with an _1, but if there is already a _1 version, then it silently fails.  Would it be possible to have it keep incrementing the number?  Otherwise, I need to ssh in and rename the conflicting directory and re-upload the .dsk image.

 

It is supposed to find the next number automatically.. but I guess that is broken.