Jump to content

Photo

new feature: 850 emulation


38 replies to this topic

#26 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • Topic Starter
  • 876 posts
  • Location:Hoffman Estates, IL

Posted Tue Apr 25, 2017 11:08 AM

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, Tue Apr 25, 2017 11:26 AM.

  • TheMontezuma likes this

#27 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,780 posts
  • Location:Bay Area, CA, USA

Posted Wed Apr 26, 2017 1:36 AM

The 850 controller source is available: http://www.atarimuse...0/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.


  • _The Doctor__ and TheMontezuma like this

#28 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 678 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Apr 26, 2017 2:56 PM

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.


#29 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,780 posts
  • Location:Bay Area, CA, USA

Posted Wed Apr 26, 2017 10:50 PM

The R: device might not be able to handle this, but the mechanism is still useful in the case that the computer restarts or is power cycled as it allows the 850 to recover and stop using the SIO bus.


  • _The Doctor__ and TheMontezuma like this

#30 w1k OFFLINE  

w1k

    Stargunner

  • 1,669 posts
  • Location:martin, slovakia

Posted Sat May 20, 2017 11:13 AM

any news?:)



#31 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 678 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sat May 20, 2017 11:24 AM

We have to spend more time in order to make the software well protected against ransomware ;)



#32 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,961 posts
  • Location:10-0-11-00:02

Posted Wed Nov 1, 2017 7:16 PM

I think this will progress much more quickly as the serial and control line protocol reveals themselves and further their understanding


  • mechanerd likes this

#33 w1k OFFLINE  

w1k

    Stargunner

  • 1,669 posts
  • Location:martin, slovakia

Posted Sat Nov 4, 2017 4:12 AM

when will be this finished?:)



#34 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 4,087 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Sat Nov 4, 2017 5:59 AM

when will be this finished?:)


Feel free to write some code and submit it to the Github repository.
  • Brentarian , Calibus and Bikerbob like this

#35 Bikerbob OFFLINE  

Bikerbob

    Dragonstomper

  • 715 posts
  • Location:Mississauga ON Canada

Posted Fri Nov 10, 2017 7:28 AM

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


  • Brentarian and mechanerd like this

#36 tschak909 ONLINE  

tschak909

    River Patroller

  • 3,248 posts
  • Location:USA

Posted Mon Feb 19, 2018 5:31 PM

Did this ever get done ?

 

-Thom



#37 w1k OFFLINE  

w1k

    Stargunner

  • 1,669 posts
  • Location:martin, slovakia

Posted Tue Feb 20, 2018 12:34 PM

death project



#38 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 4,087 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Tue Feb 20, 2018 5:10 PM

Did this ever get done ?

 

-Thom

 

I gather JoeyZ has moved on in his interests and no one else has picked up the baton. 



#39 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 678 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Feb 21, 2018 6:39 AM

I'm actually interested in doing that, but my long TO DO list hinders me...


  • Bikerbob likes this



Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users