Jump to content
IGNORED

new feature: 850 emulation


Joey Z

Recommended Posts

Today, I am starting documentation of the progress I make on adding accurate 850 emulation to RespeQt.

 

So far, I have taken the 850 source code and started reading through it, from reset. I am constructing a flow chart as to how the 850 behaves, so that I can base the emulation in RespeQt around that. When I have completely finished the flow chart, I'll scan it in and post it somewhere, for others as well as myself to use for reference in the future.

  • Like 11
Link to comment
Share on other sites

So Joey, perhaps you can explain what this would be useful for. The shareware SIO2OSX software has 850 emulation but I've never quite understand what it does.

The 850 gave your atari 4 RS232 ports, one with full modem handshake, two without, and one capable of 20ma current loop. mostly, people used them for BBSing, so modern R: emulation generally emulates a modem and lets you telnet out, which is nice for using your atari to BBS, or even as a terminal for you linux machine, etc.

 

The 850 also gave you a parallel port, but that's a generic device, well defined, and the 850 didn't really have any quirks specifically related to that, so I'll be focusing on the R: side of things, unless I uncover something unusual in the 850 P: stuff.

Link to comment
Share on other sites

So Joey, perhaps you can explain what this would be useful for. The shareware SIO2OSX software has 850 emulation but I've never quite understand what it does.

 

APE also has it and you can use it to call BBSes via the internet as well as run a BBS on the internet.

  • Like 2
Link to comment
Share on other sites

  • 3 months later...
  • 6 months later...

In SIO2OSX, it gives you internet modem functionality as well as letting you map any local serial ports on your Mac to the Atari. It's pretty handy. For example if you have a USB->serial adapter on your Mac you can use SIO2OSX to talk to serial devices from the Atari like terminals, modems, RTTY interfaces, act as a serial console for network gear and computer equipment, etc. I used to the 850 emulation quite a bit. My hackintosh has a local serial port plus a powered FTDI 4-port USB->serial adapter.

 

SIO2OSX doesn't emulate the parallel port though. It *DOES* have printer emulation for raw text, Atari 825, 1020 and Epson FX-80. This would be awesome to have for RespeQT at some point!

Edited by kogden
Link to comment
Share on other sites

  • 8 months later...

The "real" Atari 850 device counts GetStatus SIO messages (sent to D1).

If the number of "retries" indicates that there is no D1 disk connected, the ATARI 850 sends an answer to the last GetStatus message. This way ATARI 850 starts D1 drive emulation and provides the answers to the following GetSector requests. The code loaded from the ATARI 850 retrieves the R: handler from the device itself.

The fact that the R: Handler was retrieved is stored in RAM, so the ATARI 850 will not emulate the disk drive anymore until it is power cycled.

 

I understand that this can be usfeull if you do not have a floppy drive.

 

If you have a floppy drive, the ATARI DOS tries anyway to retrieve the R: handler by sending a specific request to the ATARI 850.

 

I wondered if the mechanism described above (disk emulation of the 850) would be missed by anybody if it wouldn't be emulated in RespeQt?

 

Every RespeQt user automatically gets emulated disk drives available.

I think that such a feature would be totally confusing to the users.

 

Link to comment
Share on other sites

The "real" Atari 850 device counts GetStatus SIO messages (sent to D1).

If the number of "retries" indicates that there is no D1 disk connected, the ATARI 850 sends an answer to the last GetStatus message. This way ATARI 850 starts D1 drive emulation and provides the answers to the following GetSector requests. The code loaded from the ATARI 850 retrieves the R: handler from the device itself.

The fact that the R: Handler was retrieved is stored in RAM, so the ATARI 850 will not emulate the disk drive anymore until it is power cycled.

 

I understand that this can be usfeull if you do not have a floppy drive.

 

If you have a floppy drive, the ATARI DOS tries anyway to retrieve the R: handler by sending a specific request to the ATARI 850.

 

I wondered if the mechanism described above (disk emulation of the 850) would be missed by anybody if it wouldn't be emulated in RespeQt?

 

Every RespeQt user automatically gets emulated disk drives available.

I think that such a feature would be totally confusing to the users.

 

 

I think you're right to consider not replicating the behavior exactly. RespeQt will itself provide the equivalent of 1 - 15 drives already and I find it hard to believe someone would want or need to emulate the 850 alone. I can't even think of what kind of user scenario that would make sense that way.

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

Well, the 'polling' process you describe, if I'm not mistaken, is performed by the OS ROM actually, not the DOS. I could be mistaken. 400 and 800 don't do the polling, so the only way to load the 850 handler is by disk boot without disk, or by running a special loader from DOS that loads the 850 code. I'd consider keeping the functionality, but implemented in a somewhat different form. For the moment, it could be left off, and then implemented later once time has been taken to figure out how the feature would be worked into the current RespeQt APIs.

Link to comment
Share on other sites

Well, the 'polling' process you describe, if I'm not mistaken, is performed by the OS ROM actually, not the DOS. I could be mistaken. 400 and 800 don't do the polling, so the only way to load the 850 handler is by disk boot without disk, or by running a special loader from DOS that loads the 850 code.

 

I made a small research:

 

There are different "POLL" types.

Answering to a request for a disk sector from D1 is called a "Type 0 Poll".

More info in Altirra Hardware Reference Manual

 

Atari 400/800 do not support POLL 3 and 4 types (which were introduced in XL OS).

 

From FAQ:

Bootstrapping Operation Without Disk Drive:When the Atari computer is turned on, it issues a disk request via SIO.  If noDrive 1 is present with power ON, the 850 responds to the disk request.  Thecomputer then loads the bootstrapping program from the 850, as if it werereading from a disk.  The bootstrapping program is then run, and it gets theRS-232-C handler from the 850 and relocates it into the computer's RAM.  Thememory occupied by the bootstrapping program is then freed (but the handlerremains).Bootstrapping Operation With Disk Drive:If there is a disk drive attached to the system (Drive 1 only), it responds tothe disk request issued by the computer at power-on.  The computer then readsa start-up program from that disk, such as a DOS.  The 850 does not respond tothe disk request if a disk drive responds first; therefore, the program loadedfrom disk must load the handler from the 850.  Many varieties of DOS for theAtari include an explicit provision for loading and executing thebootstrapping program from the 850, such as through the use of an AUTORUN.SYSfile.  When the 850 bootstrapping program is executed, it gets the RS-232-Chandler from the 850 and relocates it into the computer's RAM.  The memoryoccupied by the bootstrapping program is then freed (but the handler remains).

From 850 manual:

The AUTORUN.SYS program is loaded and executed by the DOS, it finds the Interface Module and loads the bootstrapping program from it.

The bootstrapping program then loads and relocates the RS-232-C handler from the Interface Module.

Link to comment
Share on other sites

I have been using Altirra's 850 R:Handler with my 850. If I use the RS232 command in SDX, it only loads once. If I type COLD, RS232 will not download the handler again until the computer or the 850 is power cycled.

 

Edit: This is on real hardware.

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

There was a bug in certain 850 roms that did just such behavior...sure it's in faq or on here somewhere that tells the offending rom revision.

 

Looks like everyone forgot what was once common knowledge but a software work around was in here somewhere...

 

https://atariage.com/forums/topic/192436-bootstrap-atari-850-only-once/

 

I can't remember exactly but their were a few rom revisions and I believe only 1 had the bootstrap problem... some had other quirks and only 1 had little wrong with it and kept up a solid flow.... it was written about in articles and users group notes...

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

OK. I assume that "Type 0 Poll" may be an interesting feature in 850 emulation.

 

Next question:

Although telnet is designed to be symetric protocol (with only a few "options" violating this rule), the implementation of the client and a server is different.

A server is listening on a socket and accepts connections. A client requests those connections.

I would like to understand if we need support for a telnet server? And if yes - how it should work.

Link to comment
Share on other sites

Telnet server would indeed be useful. Think of it as when you have a modem that has auto answer. Incoming connection would send RING once to the Atari (assuming Hayes emulation) followed by the appropriate CONNECT message (which may or may not include a speed). This is useful for someone trying to run a BBS. For the 850 emulation, it'd emulate DCD going active at this point as well.

 

There's probably not such a good way to emulate anything other than auto-answer. You'd have to connect on the telnet side, send up to some set number of RINGs to the Atari, and wait for ATA (or maybe this is the *one* command that doesn't need AT preceding it, I forget). If you go through the maximum rings, you drop the telnet connection with some appropriate error perhaps, maybe NO CARRIER or NO ANSWER.

 

Also, I think there should be an API for a generic R:-attached device. That is, maybe one that is a modem emulator using telnet, one that just directs to a file (useful for early testing of the basic 850 functionality I think), and one that redirects to a serial port on the host machine.

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

850 with terminal cart.. fast way to get online without loading dos and other things... and sure if you really wan't to save to a cassette :) of course there were other devices in other settings using carts or modified OS and the 850

Edited by _The Doctor__
Link to comment
Share on other sites

Telnet server would indeed be useful. Think of it as when you have a modem that has auto answer. Incoming connection would send RING once to the Atari (assuming Hayes emulation) followed by the appropriate CONNECT message (which may or may not include a speed). This is useful for someone trying to run a BBS. For the 850 emulation, it'd emulate DCD going active at this point as well.

 

Does it really make sense?

I mean people who still wants to use ATARI as a BBS server - they probably prefer real hardware against a PC software like RespeQt.

They would use "Black Box" and Lantronix, etc.

Otherwise you may run BBS software on a PC (it doesn't matter for clients connecting via Telnet) and you don't need ATARI and RespeQt.

Anyway we may start with a Telnet Client support only and add Server support later.

 

And what about multiple clients?

The way you usually program a threaded socket server is: call accept() in a loop; spawn a new thread to handle the new connection.

For the "ATARI - RespeQt" approach we would handle only one client at a time?

 

There's probably not such a good way to emulate anything other than auto-answer. You'd have to connect on the telnet side, send up to some set number of RINGs to the Atari, and wait for ATA (or maybe this is the *one* command that doesn't need AT preceding it, I forget). If you go through the maximum rings, you drop the telnet connection with some appropriate error perhaps, maybe NO CARRIER or NO ANSWER.

 

ATA Answer incomming call

ATA can be used answer an incomming call manually. Another modem must already try to connect to the modem and the line should be ringing. After the ATA command, the modem picks up the line, negotiates with the other modem about the data transfer rate and error correction settings and switches to data transfer mode when the negotiation succeeds. In case of succes, the string "CONNECT" is returned, otherwise the returned string is "ERROR". In the latter case the modem stays in command mode. The "CONNECT" string may be followed by text indicating the speed and protocol settings used for the session.

 

 

 

That's why I saw the string ATA coming over Telnet from a server...

 

Also, I think there should be an API for a generic R:-attached device. That is, maybe one that is a modem emulator using telnet, one that just directs to a file (useful for early testing of the basic 850 functionality I think), and one that redirects to a serial port on the host machine.

 

This is a good idea. I realized that Altirra configuration requires first to add a 850 device emulation and then to add a modem emulation.

 

Shall we use the original R: Handler from 850? Or maybe the Altirra version?

Since the "concurrent i/o" mode shall be left as soon as the command line is raised, we would either break support for "NONE" and "SOFTWARE" handshake or we would need a protocol layer in a R: Handler and in RespeQt which would allow us to send a message to force leaving "concurrent i/o" mode. I will do it this way in a SIO2BT app, so a similar approach can be implemented in RespeQt.

Edited by TheMontezuma
Link to comment
Share on other sites

Does it really make sense?

I mean people who still wants to use ATARI as a BBS server - they probably prefer real hardware against a PC software like RespeQt.

They would use "Black Box" and Lantronix, etc.

Otherwise you may run BBS software on a PC (it doesn't matter for clients connecting via Telnet) and you don't need ATARI and RespeQt.

I'll let the guys who run BBSes decide that.

 

Anyway we may start with a Telnet Client support only and add Server support later.

That said, yes, it's no problem to leave it out for the moment and only add it later.

 

And what about multiple clients?

The way you usually program a threaded socket server is: call accept() in a loop; spawn a new thread to handle the new connection.

For the "ATARI - RespeQt" approach we would handle only one client at a time?

Yes, you could either accept only one connection at a time or you can continue to accept connections, and just send some sort of 'busy' message.

 

This is a good idea. I realized that Altirra configuration requires first to add a 850 device emulation and then to add a modem emulation.

And that said, Altirra probably provides a decent model for how to do this. It's probably a safe bet that if you don't quite know how to implement something, it can be implemented similar to how altirra behaves. Differences will arise, of course, between an SIO device emulator and a full machine emulator as far as the lower level details go.

 

Shall we use the original R: Handler from 850? Or maybe the Altirra version?

Since the "concurrent i/o" mode shall be left as soon as the command line is raised, we would either break support for "NONE" and "SOFTWARE" handshake or we would need a protocol layer in a R: Handler and in RespeQt which would allow us to send a message to force leaving "concurrent i/o" mode. I will do it this way in a SIO2BT app, so a similar approach can be implemented in RespeQt.

Any R: handler should be OK to use, it's not really important as long as they provide the same functionality. And yes, support for NONE and SOFTWARE handshake will be difficult in an 850 styled device. There are ways to do software protocol though, like you said, that can effectively signal the emulated 850 to exit concurrent mode without hardware handshaking. Personally, I would pick an unlikely character, such as 0x00, to be a special character. Consider this character to be a sort of 'control code introducer.' You then follow it with a second byte which indicates what the emulated R: device should actually do.

 

So, for example:

 

0x00 0x00 - literal character 0x00 should be sent by R:

0x00 0x01 - drop out of concurrent mode

0x00 0xnn - various other codes for doing useful things without dropping out of concurrent mode (maybe changing handshaking mode, for example, other R: commands etc.)

 

The Atari has to scan the data going out for 0x00 and replace it properly. This is why I chose 0x00, because it is particularly easy to detect on the 6502, just load the value and check the zero flag. This is only a good idea if 0x00 is an infrequent character to be sent, which is probably a safe assumption to make. Otherwise it results in potentially a large performance penalty, sending two bytes for one byte of information.

Link to comment
Share on other sites

Any R: handler should be OK to use, it's not really important as long as they provide the same functionality. And yes, support for NONE and SOFTWARE handshake will be difficult in an 850 styled device. There are ways to do software protocol though, like you said, that can effectively signal the emulated 850 to exit concurrent mode without hardware handshaking. Personally, I would pick an unlikely character, such as 0x00, to be a special character. Consider this character to be a sort of 'control code introducer.' You then follow it with a second byte which indicates what the emulated R: device should actually do.

 

So, for example:

 

0x00 0x00 - literal character 0x00 should be sent by R:

0x00 0x01 - drop out of concurrent mode

0x00 0xnn - various other codes for doing useful things without dropping out of concurrent mode (maybe changing handshaking mode, for example, other R: commands etc.)

 

The Atari has to scan the data going out for 0x00 and replace it properly. This is why I chose 0x00, because it is particularly easy to detect on the 6502, just load the value and check the zero flag. This is only a good idea if 0x00 is an infrequent character to be sent, which is probably a safe assumption to make. Otherwise it results in potentially a large performance penalty, sending two bytes for one byte of information.

 

Yes, I meant exactly such a pattern (the same approach as used in Telnet protocol for negotiations).

However it is not the ATARI which is suppoused to scan the data, but the 850 emulation in RespeQt (I see no need to make it symmetric).

 

And it would require to extend the R: handler code to send such a sequence ($00 $01).

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 :)

Link to comment
Share on other sites

I have recorded and analyzed (with https://www.wireshark.org/) a few telnet negotiations with darkforce-bbs.dyndns.org telnet server:

 

1) ALTIRRA

FROM BBS:
ff fb 01 (WILL ECHO)
ff fb 03 (WILL SUPPRESS-GO-AHEAD)

FROM ALTIRRA:
ff fe 01 (DON'T ECHO)
ff fd 03 (DO SUPPRESS-GO-AHEAD)

FROM BBS:
ff fc 01 (WON'T ECHO)

2) APE

FROM BBS:
ff fb 01 (WILL ECHO)
ff fb 03 (WILL SUPPRESS-GO-AHEAD)

FROM APE:
ff fd 01 (DO ECHO)
ff fd 01 (DO SUPPRESS-GO-AHEAD)

3) PUTTY

FROM PUTTY:
ff fb 1f (WILL NEGOTIATE ABOUT WINDOW SIZE)
ff fb 20 (WILL TERMINAL-SPEED)
ff fb 18 (WILL TERMINAL-TYPE)
ff fb 27 (WILL NEW ENVIRONMENT OPTION)
ff fd 01 (DO ECHO)
ff fb 03 (WILL SUPPRESS-GO-AHEAD)
ff fd 03 (DO SUPPRESS-GO-AHEAD)

FROM BBS:
ff fb 01 (WILL ECHO)
ff fb 03 (WILL SUPPRESS-GO-AHEAD)

FROM BBS:
ff fe 1f (DON'T NEGOTIATE ABOUT WINDOW SIZE)
ff fe 20 (DON'T TERMINAL-SPEED)
ff fe 18 (DON'T TERMINAL-TYPE)
ff fe 27 (DON'T NEW ENVIRONMENT OPTION)
ff fd 03 (DO SUPPRESS-GO-AHEAD)

FROM PUTTY:
ff fb 24 (WILL ENVIRONMENT OPTION)

FROM BBS:
ff fe 24 (DON'T ENVIRONMENT OPTION)

I can see in every sequence that all parties agree to suppress GO-AHEAD, which means they agree to support full-duplex communication.

 

However echoing is handled differently by each Telnet client (RFC 857 describes the ECHO option).

 

No remote echoing (default NVT setting and the ALTIRRA setting) is more efficient (less network traffic). I would tend to go the ALTIRRA way (as Joey recommended).

 

By the way, I also recorded a session with a UDS Lantronix device and a surprise: it does not support Telnet at all - the telnet commands are passed through (the serial to TCP/IP bridge is fully transparent)...

According to the Telnet specification, to avoid endless negotiations, requests shall not be answered if a requested feature is already enabled.

I wondered how is it handled on the Telnet Server side if it requested ECHO: ff fb 01 (WILL ECHO) and there was no answer at all ?

Link to comment
Share on other sites

 

Yes, I meant exactly such a pattern (the same approach as used in Telnet protocol for negotiations).

However it is not the ATARI which is suppoused to scan the data, but the 850 emulation in RespeQt (I see no need to make it symmetric).

 

And it would require to extend the R: handler code to send such a sequence ($00 $01).

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 :)

I only meant that the Atari software might try to send 0x00, so the Atari's R: handler must scan for this and replace it with 0x00 0x00. Otherwise, it would be interpreted as some other command on the RespeQt side. Nothing needs to be done on the RX side within the atari R: handler.

 

And I think the right way to do things is to explicitely exit concurrent mode, but I'm not sure how the 850 behaves, or how software using it might behave. This is where the source for the firmware on the device might be useful, or otherwise looking at the code for the emulation in altirra is probably fairly accurate.

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

I only meant that the Atari software might try to send 0x00, so the Atari's R: handler must scan for this and replace it with 0x00 0x00. Otherwise, it would be interpreted as some other command on the RespeQt side. Nothing needs to be done on the RX side within the atari R: handler.

 

Yes, you are right, R: Handler should scan the data to be sent (and replace 0x00 with 0x00 0x00) and RespeQt should do the opposite operation (strip it down to 0x00).

 

Per default Telnet communication is based on 7-bit ASCII. The ASCII control codes (0-31 decimal) shall be translated to the NVT control codes in the Telnet layer.

 

By the way: "0x00" is a valid (and mandatory) telnet NUL command (means NO OPERATION).

So it wouldn't even hurt to keep two zeros in the data stream sent over Telnet (although the original 0x00 code would not be received at all by the process connected to the Telnet server).

 

This brings me to the next area: translations...

 

1) Translations in 850. We want to stay compatible and we want to emulate 850 translations (per default: light translations, which influence EOL handling).

 

2) The terminal software (like BobTerm or ICE-T) emulate a particular terminal type (for example VT-100).

This terminal type has specific control command codes which may or may not match NVT contol codes, correct?

Normally the Telnet client (in RespeQt) shall do the translations (Specific terminal <-> NVT). However It would need to know which terminal type is emulated on the ATARI...

Link to comment
Share on other sites

2) The terminal software (like BobTerm or ICE-T) emulate a particular terminal type (for example VT-100).

This terminal type has specific control command codes which may or may not match NVT contol codes, correct?

Normally the Telnet client (in RespeQt) shall do the translations (Specific terminal <-> NVT). However It would need to know which terminal type is emulated on the ATARI...

There are plenty of telnet based solutions which get by without implementing this fully, for the same reasons. ser2tcp and various terminal server standalone devices like the series of lantronix boxes all have this same issue. They can't know exactly what they're connected to. Somehow they found a way around this problem, most likely the solution was to not support the codes that don't make sense. In this case, you wouldn't do translations between specific terminal commands and NVT. You would, if possible, indicate that the NVT commands which have this issue are not supported. At this point, the far end (unfortunately) has to guess the terminal type by trying specific terminal commands. This is, AFAIK, how most hosts work anyway in the BBS world since not all clients are fully telnet compliant (fully compliant clients are rarer than you might expect I think).

 

ser2tcp, I think, at least partially supports telnet, so this may be a good source to draw from. Additionally, again, altirra would be a good source to draw on for this behavior. Lastly, a professional solution which deals with the same issue are any of the lantronix terminal servers, so if you have one or can get your hands on one for a reasonable price, it may be beneficial to do some network sniffing to figure out how they get around this issue. That said, lantronix boxes aren't always cheap, so this isn't as reasonable if you don't already have one (I don't). It's also possible that someone on the forum can provide help here. It would even be reasonable to set up a telnet server, and ask someone on the forum to just connect with their lantronix box so you can capture the negotiation and some protocol in wireshark.

 

Do you have a decent reference link on the NVT codes? I'd like to have a look myself at what exactly we're dealing with.

Edited by Joey Z
Link to comment
Share on other sites

I have a Lantronix UDS device (I connected it to the serial port on my PC) and it does not answer to the Telnet commands sent from a BBS at all:

ff fb 01 (WILL ECHO)
ff fb 03 (WILL SUPPRESS-GO-AHEAD)

Lantronix UDS is passing those 6 bytes to the serial port (this what you see in the terminal as strange characters) and does not send any answer to the Telnet server.

That means it is definitely not a reference device (altthough it shows that you do not need Telnet support to visit BBSs - a raw socket connection will do).

 

By the way - there is a difference between Telnet commands:

http://www.tcpipguide.com/free/t_TelnetProtocolCommands-3.htm

 

and Telnet NVT control codes:

http://www.tcpipguide.com/free/t_TelnetCommunicationsModelandtheNetworkVirtualTermi-3.htm

  • Like 2
Link to comment
Share on other sites

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...