New MAME release

[+mizapf]

Hmm, the first attempt was not really successful. After "telnet heatwave.ddns.net:9640", the log on the TIPI says "<timestamp> TiSocket: INFO read 1 bytes from 1" (several times), but the telnet program continues to read 06 from RCIN and is caught in that loop.

 

Did it work in an earlier MAME release?

[+9640News]

12 minutes ago, mizapf said:

Hmm, the first attempt was not really successful. After "telnet heatwave.ddns.net:9640", the log on the TIPI says "<timestamp> TiSocket: INFO read 1 bytes from 1" (several times), but the telnet program continues to read 06 from RCIN and is caught in that loop.

 

Did it work in an earlier MAME release?

No, the embedded telnet has not worked in earlier versions.

[+mizapf]

OK, I got a but further, but again a lockup at the end (that is, none of the keys worked, neither did F9 or ESC). So this is still not stable.

 

[+9640News]

9 minutes ago, mizapf said:

OK, I got a but further, but again a lockup at the end (that is, none of the keys worked, neither did F9 or ESC). So this is still not stable.

 

One small step for man, one gigantic step for MAME.  Just need a few more steps <grin>.

Beery

 

[+9640News]

@arcadeshopper

 

Not MAME related, but tried sending you a message and it said you cannot receive messages.  Mailbox full?

[+arcadeshopper]

4 hours ago, 9640News said:

@arcadeshopper

 

Not MAME related, but tried sending you a message and it said you cannot receive messages.  Mailbox full?

likely.. i will clean it up easier to email me @gmail

 

[+mizapf]

As I said, there is something strange going on which actually triggered the error. One one hand, I did not guard the queue against being read when it is empty. On the other hand, why does that happen at all?

 

[:peb:slot6:tipi] DSR on 
[:peb:slot6:tipi] TDOUT <- 00
[:peb:slot6:tipi] TCOUT <- 00
[:peb:slot6:tipi] DSR off
[:peb:slot6:tipi] DSR off
[:peb:slot6:tipi] DSR on
[:peb:slot6:tipi] TCOUT <- f1
[:peb:slot6:tipi] Reset
[:peb:slot6:tipi] RCIN -> f1
[:peb:slot6:tipi] TDOUT <- 00
[:peb:slot6:tipi] TCOUT <- 02
[:peb:slot6:tipi] RCIN -> 02
[:peb:slot6:tipi] Queue empty, RDIN -> 00 again
[:peb:slot6:tipi] TDOUT <- 19
[:peb:slot6:tipi] TCOUT <- 03
[:peb:slot6:tipi] RCIN -> 03
[:peb:slot6:tipi] Queue empty, RDIN -> 00 again
[:peb:slot6:tipi] TDOUT <- 22
[:peb:slot6:tipi] TCOUT <- 02
[:peb:slot6:tipi] RCIN -> 02
[:peb:slot6:tipi] Queue empty, RDIN -> 00 again

This is the new log output with a check whether the queue is empty. This output occurs when you do a "telnet some.host:1234".

 

I suspect there is something wrong in the telnet client, or I may have misunderstood the interaction protocol with the TIPI, I don't want to rule that out.

 

As I understood it, writing a byte to the TIPI means to write a byte into TDOUT (5FFF), then submit it by writing 02 (alternating with 03) to TCOUT (5FFD). You read RCIN (5FF9) to check that your write has been done; in that case it reflects the value of TCOUT.

 

For reading, you write 06 to TCOUT (alternating with 07) and when it is reflected in RCIN, you can read from RDIN (5FFB).

 

This does not happen here. You see that after the Reset, a byte 00 is written to the TIPI (00->TDOUT, 02->TCOUT, RCIN->02), then obviously, RDIN is read, but there was no read request before (i.e. there was no 06/07->TCOUT). Further bytes are written, but each time, RDIN is read, which does not make sense, as I see it. And this was the reason why I got a SIGSEGV: There was nothing in the queue.

 

Of course, reading RDIN should not cause any trouble, in particular lockups or other unexpected behavior, but I guess it should better not be done here. I'm not sure what to return; I suppose it is the last valid value that was returned, unless there has been a Reset, in which case I return 00.

[+mizapf]

@9640NewsBeery, could you point me to the telnet client source code, please? Maybe I can figure out the instabilities.

 

[+9640News]

3 hours ago, mizapf said:

@9640NewsBeery, could you point me to the telnet client source code, please? Maybe I can figure out the instabilities.

 

Just sent you a couple of files.

[+mizapf]

OK, I think I found the actual problem, and first tests showed that all is working now, both TIPI file operations and telnet. I'm not fully sure, however:

 

* When I connect to heatwave, after logging off, the following connection attempts fail. I have to try several times (getting No connection), then it works again.

* Within the screens, it seems I'm getting kind of ANSI sequences that are not displayed properly.

 

At least it's running stable enough so that I was able to create an account on heatwave from the MAME-emulated Geneve via the Qemulated Raspi.

[GDMike]

Noisy line. Did you try filter

[+9640News]

1 hour ago, mizapf said:

OK, I think I found the actual problem, and first tests showed that all is working now, both TIPI file operations and telnet. I'm not fully sure, however:

 

* When I connect to heatwave, after logging off, the following connection attempts fail. I have to try several times (getting No connection), then it works again.

* Within the screens, it seems I'm getting kind of ANSI sequences that are not displayed properly.

 

At least it's running stable enough so that I was able to create an account on heatwave from the MAME-emulated Geneve via the Qemulated Raspi.

Heatwave as I recall has a configuration setting that allows you to set ASCII or ANSI and it remembers the setting.  It doesn't prompt and/or detect when you call back in.  You would need to go back onto Heatwave with another terminal program and change your settings to go to ASCII.

 

Beery

 

[+InsaneMultitasker]

5 hours ago, mizapf said:

OK, I think I found the actual problem, and first tests showed that all is working now, both TIPI file operations and telnet. I'm not fully sure, however:

 

* When I connect to heatwave, after logging off, the following connection attempts fail. I have to try several times (getting No connection), then it works again.

* Within the screens, it seems I'm getting kind of ANSI sequences that are not displayed properly.

 

At least it's running stable enough so that I was able to create an account on heatwave from the MAME-emulated Geneve via the Qemulated Raspi.

Trying to make sense of this screen reminds me of my experiences at work today.

 

When you created your account, you should have been asked if you wanted 'color ansi' display.  If you do log in again, get to the main menu and adjust your settings with option "E" to edit your configuration.  Turn off color ANSI. Edit:  I remotely logged into the BBS and updated your user profile settings to 40 column/no color ansi.   If I recall correctly, @9640News had tried to add the ansi driver to the command line telnet but the XOP support won't allow that many nested levels.  You'd have to use the Myterm equivalent to see the color/ansi.   

 

As for the connection attempts, Heatwave resets to pristine condition after a caller disconnects.  It takes about 15 seconds to reset, reload all the string info, reset parms, etc.  The BBS runs from XB with assembly/XOP support under GPL.  XB file IO is not very fast, fortunately, most of the user display output for files is assembly-based.

[+mizapf]

Yes, that looks good now; thanks for changing the setting. One thing: After "Goodbye", the last message is "Logging you off at: <time>", but it does not return to MDOS until I press Esc. Is that OK?

 

I'm building intermediate MAME releases now and upload them to WHTech as soon as they are ready. You will find them at the usual location, named "mame20220607b...".

 

Edit: Now available at your favorite WHTech.

[+9640News]

29 minutes ago, mizapf said:

Yes, that looks good now; thanks for changing the setting. One thing: After "Goodbye", the last message is "Logging you off at: <time>", but it does not return to MDOS until I press Esc. Is that OK?

 

I'm building intermediate MAME releases now and upload them to WHTech as soon as they are ready. You will find them at the usual location, named "mame20220607b...".

The telnet client requires a F9 key or ESC press to actually exit the command. That is normal. The next release has the TIPI XOP calls that allows specific server bytes by application to be used. That should not impact the emulation. 

[+9640News]

8 hours ago, InsaneMultitasker said:

Trying to make sense of this screen reminds me of my experiences at work today.

 

When you created your account, you should have been asked if you wanted 'color ansi' display.  If you do log in again, get to the main menu and adjust your settings with option "E" to edit your configuration.  Turn off color ANSI. Edit:  I remotely logged into the BBS and updated your user profile settings to 40 column/no color ansi.   If I recall correctly, @9640News had tried to add the ansi driver to the command line telnet but the XOP support won't allow that many nested levels.  You'd have to use the Myterm equivalent to see the color/ansi.   

 

As for the connection attempts, Heatwave resets to pristine condition after a caller disconnects.  It takes about 15 seconds to reset, reload all the string info, reset parms, etc.  The BBS runs from XB with assembly/XOP support under GPL.  XB file IO is not very fast, fortunately, most of the user display output for files is assembly-based.

@mizapf

 

As @InsaneMultitasker indicated, I have an ANSI driver to be released with the next MDOS release.  I have modified the code for the Telnet client code you received to use the driver, however there are two functions in the ANSI driver that requires communication with the TIPI. One is to respond with terminal type, and another with screen location.  

 

The issue I was having is the ANSI driver (an XOP itself) communicates with the Video XOP for all screen I/O and it also can call the TIPI XOP to pass information back if it receives an ANSI sequence requesting feedback information from the client.  Somewhere, and I have tried multiple avenues on the real iron to resolve, I could not get the code to return from the TIPI XOP back to the ANSI XOP.  

 

That effort  to resolve I am hoping can be resolved when the TIPI emulation works for the Geneve on MAME.  I need the extra debugging tools MAME offers to see the memory maps to trace where the specific issue is.  If I can find the issue, then the embedded Telnet client will have both ANSI 80 column text as well as ANSI color capability.

 

Beery

[+9640News]

I saw the new MAME update for Windows on whtech.  I was able to connect to Heatwave with no issue.  

 

Beery

[+arcadeshopper]

telnet works here too.. when i x out of the mame window in windows i get

 

-----------------------------------------------------
Exception at EIP=0000000000be2c10 (not found): ACCESS VIOLATION
While attempting to read memory at 0000000008b81160
-----------------------------------------------------
RAX=0000000000be2c10 RBX=0000000008b18260 RCX=0000000008b80c60 RDX=0000000008c31c90
RSI=0000000003cfa1e8 RDI=0000000008c31c90 RBP=000000001385f758 RSP=000000001385f728
 R8=0000000008b17f80  R9=0000000000000001 R10=000000000000107a R11=8101010101010100
R12=000000001385f850 R13=0000000003cfa030 R14=000000001385fb00 R15=000000000bd1ef68
-----------------------------------------------------
Stack crawl:
  000000001385f720: 0000000000be2c10 (not found)
  000000001385f780: 0000000000ce29c1 (not found)
  000000001385f8f0: 000000000087c3b9 (not found)
  000000001385f9f0: 000000000265f16d (not found)
  000000001385fc30: 00000000026689ae (not found)
  000000001385fda0: 000000000087af42 (not found)
  000000001385fe30: 000000000087bbed (not found)
  000000001385fe70: 0000000002b6a341 (not found)
  000000001385fec0: 0000000001209eb3 (not found)
  000000001385fef0: 00007ffec3b3af5a (beginthreadex+0x012a)
  000000001385ff20: 00007ffec3b3b02c (endthreadex+0x00ac)
  000000001385ff50: 00007ffec3617034 (BaseThreadInitThunk+0x0014)
  000000001385ffd0: 00007ffec43c2651 (RtlUserThreadStart+0x0021)

[+9640News]

I got some type of error as well, however I thought it was due to the way I shut down and disregarded the error.

[+arcadeshopper]

I'm also getting an error/crash when i reset the geneve emulator from the menu.. say after i change the cru address and set tipi to sync

starts right back up though

 

Edited June 8, 2022 by arcadeshopper

[+mizapf]

Hmm, I could not reproduce this issue in Linux. F3 causes a clean reboot, closing the window does not trigger a error either. I'll have to check it in Windows.

 

The thing is, the websocket client in MAME is somewhat tricky to use; it starts an own thread, sometimes getting into race conditions in logging, and I already had similar problems on shutdown (maybe something is gone which the client tries to get access to).

 

Edit: Does it only occur when TIPI is plugged into the PEB? What happens when you leave away the "-conn rpi.localhost"?

[+dhe]

Having some problems with TIPI / MAME

 

Here is my start up batch file:

 

D:\mame>type gmtipi.bat
mame -oslog -debug -window genmod -bios 1.00 -peb:slot3 horizon -peb:slot5 tirs232 -peb:slot6 tipi -conn rpi.192.168.3.2 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -peb:slot8:hfdc:h2 generic -peb:slot8:hfdc:h3 generic -peb:slot8:hfdc:f3 525dd -peb:slot8:hfdc:f4 525dd -hard1 genos7boot.HD -hard2 Bootdisk2.HD -hard3 Bootdisk3.HD -flop1 DSDD1.dsk -flop2 DSDD2.hfe -flop3 DSDD3.dsk -flop4 DSDD4.dsk -serl1 socket.localhost:10000

 

TIPI can be seen from both ping/ssh and via a web browser.

 

TI STAT locks and I get this in the log:

 

And the log shows:

[:peb:slot6:tipi] Got error: No connection could be made because the target machine actively refused it. (10061)

 

I'm pretty sure - I must be missing the vital piece the emulates the board to pi physical connector?

[+jedimatt42]

13 minutes ago, dhe said:

Having some problems with TIPI / MAME

...

 

I'm pretty sure - I must be missing the vital piece the emulates the board to pi physical connector?

Did you do this part: emulation installation · jedimatt42/tipi Wiki (github.com)

 

specifically the following part:

 

Quote

Enable emulation mode, by running /home/tipi/tipi/emulation/emu_config.sh and responding to the prompts. On a real Raspberry PI, PDF conversion can be enabled, and you probably don't want tipi_disk mounted via NFS.

In most cases you'll answer 'y' YES to enable emulation websocket, 'n' NO to NFS, and 'y' YES to PDF support.

 

[+mizapf]

On 6/8/2022 at 9:25 PM, arcadeshopper said:

telnet works here too.. when i x out of the mame window in windows i get

 

-----------------------------------------------------
Exception at EIP=0000000000be2c10 (not found): ACCESS VIOLATION
While attempting to read memory at 0000000008b81160

I could still not reproduce this error, even in Windows. I use a Qemu-Raspi on a Linux host to connect to. I did get an error message on exit, but it did not lead to an exception with this stack dump.

 

Does it always happen, and if not, roughly every second/third/... time?

Does this occur on the Geneve only, or on the TI as well?

Does it happen after using telnet or when you only used it for file operations (e.g. DIR TIP1.)?

Does it happen when there is no connection to a Raspberry? (leave away the -conn)

What is the simplest command line that triggers this error?

[+arcadeshopper]

46 minutes ago, mizapf said:

I could still not reproduce this error, even in Windows. I use a Qemu-Raspi on a Linux host to connect to. I did get an error message on exit, but it did not lead to an exception with this stack dump.

 

Does it always happen, and if not, roughly every second/third/... time?

Does this occur on the Geneve only, or on the TI as well?

Does it happen after using telnet or when you only used it for file operations (e.g. DIR TIP1.)?

Does it happen when there is no connection to a Raspberry? (leave away the -conn)

What is the simplest command line that triggers this error?

 

every time

geneve not ti

just start it and hit X to close window doesn't even have to boot up just wait for the swan

yes it happens with out the -conn but it doesn't happen when i remove the -peb tipi card and the -conn 

mame geneve -peb:slot6 tipi  -peb:slot2 memex -debug -peb:slot4 hfdc -peb:slot4:hfdc:h1 generic -hard1 l:\ti994a\80mb4.hd