Jump to content
IGNORED

new feature: 850 emulation


Joey Z

Recommended Posts

it looks to me like the NVT codes match with ASCII control codes, and the meanings of those are fairly standard, and normally act as they are described in that specification. I think you can pass them without translation (aside from the 850 style translation, if enabled)

 

Also, does the 850 support translation in concurrent mode? if it does, this normally happens in the R: handler. In concurrent mode, the 850 becomes a fancy level shifter, digitally copying serial RX to SIO TX and SIO RX to serial TX. In line mode, the 850 may do the translation.

 

Either way, I think the differences between RespeQts R: and the 850 is probably going to be different enough that at least a partial rewrite of the handler is going to be necessary, or at least beneficial. The 850, in concurrent mode, was a fairly dumb device limited by the lack of real UARTs, small RAM, and slow CPU. The 850, for these reasons, offloaded some things to the atari computer. However, these limitations aren't present within RespeQt, so we can do these things in RespeQt rather than on the atari. translation is the first example that comes to mind, but another example is that a FIFO can be implemented in RespeQt, unlike the 850 hardware which had no FIFO in concurrent mode. Some of these changes need no change to software (a FIFO would not break the 850's R: handler) but others do, like translation within RespeQt.

 

EDIT: additionally, you can assume that if the user is using a terminal that doesn't comply with NVT (ATASCII terminal for example), then the user knows what they are doing, and is also sure that the far end doesn't expect compliance with NVT and will instead cater to the needs of the client (send ATASCII characters for example).

Edited by Joey Z
  • Like 1
Link to comment
Share on other sites

The 850 controller source is available: http://www.atarimuseum.com/computers/8bits/400800/atari850.html

 

It does not do translation or parity, in either block or concurrent mode. That's done by the R: handler.

 

In-band signaling is also likely to be more reliable for sensing control signals, which for the 850 requires frequently dropping in and out of concurrent mode to send check commands. The downside is that RespeQt would not be compatible with standard 850 R: handlers. PC serial timing may not be good enough for that anyway, though.

 

The P:R: Connection uses a similar protocol to the 850 but ditches block mode in hardware, emulating it with concurrent mode. The R-Verter and SX212 solve the control signal sensing problem by using SIO proceed/interrupt lines, but good luck finding an SIO2PC cable supporting those.

 

The Telnet protocol is a bit of a mess -- you really have to test against actual servers upon which you'll find that (a) a popular Telnet server relies upon a behavior counter to the standard but which everyone has to support, or (b) the behavior you're seeing isn't accounted for in the five RFCs you're looking at because there's another sixth RFC up in the 7xxx range that accounts for it.

  • Like 2
Link to comment
Share on other sites

I only wondered if this approach would work if the application would not explicitely call close operation of the R Handler (to leave concurrent IO mode) before accessing SIO devices (like a disk drive).

Normally an application does not need to do it, because the asserted command line would automatically stop the 850 concurrent IO mode.

I need to sniff the communication with a real 850 and study the 850 documentation to find it out :)

From 850 doc:
CLOSE is the only way to terminate concurrent mode I/O from a program.[...]
FAILURE TO TERMINATE CONCURRENT MODE I/O PROPERLY BEFORE ATTEMPTING I/O TO OTHER PERIPHERALS (OR EVEN OTHER RS-232-C PORTS) WILL PROBABLY RESULT IN PROGRAM FAILURE. THE ONLY WAY TO RECOVER FROM SUCH FAILURE IS BY TURNING TNE COMPUTER OFF THEN ON AGAIN, WHICH RESULTS IN THE LOSS OF INFORMATION IN MEMORY.
Link to comment
Share on other sites

  • 4 weeks later...
  • 5 months later...

This is excellent people, glad you are doing this. As much as I love APE, this not only brings RESPEQT in line with it.. it surpasses it with the ability to write to a shared folder. I do use the R: handler from APE as my way to get online with my 8-bit, and would use it if I was to run a bbs with it. But I am a caller of BBSs not a host.. so this is excellent.

 

Really for me the last and only reason I do not use RespeQT over APE. Thank you all for your work, great to see hobbiest enjoying their hobby.

 

James

  • Like 2
Link to comment
Share on other sites

  • 3 months later...
  • 1 year later...
5 minutes ago, _The Doctor__ said:

bump

:)

Good luck. Since @JoSch got in a huff and quit the forum, and with @Joey Z busy with other interests in life, I don't guess anyone is doing much very actively with RespeQt anymore. Maybe @ebiguy or @TheMontezuma will pick up the torch, but I'm not holding my breath.

Link to comment
Share on other sites

  • 2 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...