So, in the mode you describe, can the apple transmit back out serial?
Always.. The question is do the Bytes go to the UDS-10, or do they Pass Thru it to the Ethernet Interface and on to the other end of the pipe.
It's a bootstrapping process. So as data is fed in via serial, the code running in RAM now will reply with certain characters to establish that the comms are OK. And in some cases, the bootstrapping process is entirely one way, where via serial the entire program blob is loaded into RAM.
So Data Bytes come into the Apple ]['s Serial Port, and a Program running at that moment
on the Apple will Handshake
( Reply to the Incoming Bytes and establish a Communications Channel ).
In some cases, the Incoming Data Bytes are Uploaded to the Apple ][ and loaded into the Memory?
Only once it's excuted does it begin to transmit back out the serial to the host.
If your referring to "the code running in RAM", I would think that it should. If ( the code ) could "establish that the comms are OK", it should continue to communicate with the Incoming Connection.
If your referring to "the entire program blob is loaded into RAM", you would need to ensure that the "the code running in RAM" Relinquish Control of the Serial Port so your new code
can then Communicate with the Incoming Connection.
Or have a driver
that handles the Com Port and lets multiple pieces of Code access it.
Your programs would need to be able to determine when the Data is for them, and when it is for some other program. ( This is like checking to see if a piece of Postal Mail is Addressed to you )
Your driver, would need to be designed to let all the individual pieces of Code, look ( Peek ) at the Data or a Header for the Data to determine if it for them. From an efficiency aspect, this is not very efficient, because each piece of Code needs to be executed for every incoming data ( packet ) and see it is suppose to handle it
. This is called Polled or Polling
So, for efficiency
you want Interrupted or Interrupt Driven
The Windows OS implements something called, Call-Backs. When your Code, ( Application or DLL is Executed ), it can Register with certain running Services, so that when some event happens
, that Service will Call your Application and Push it some Data.
If you built a Com Driver that handled Call Backs, your individual pieces of Code could register with the Driver, an ID
and a Pointer
to a Handler for that individual piece of Code's data processing. Then your individual pieces of Code would only be processing Incoming Data when it was relevant to them.
About the UDS-10 in General.....
In this mode the UDS-10 is just like a Dial Up Modem. It has an Off-Line Mode and an On-Line Mode.
In Off-Line Mode, Bytes sent to the Modem ( UDS-10 ) are interpreted and processed by the Modem ( UDS-10 ), Commands Like Dial ( a phone number for the Modem or an IP Address for the UDS-10 ) or Auto Answer ( Answer on Incoming, Ring for the Phone or IP Connection for the UDS-10 ).
In On-Line Mode, Bytes sent to the Modem ( UDS-10 ) Pass-Thru it to what ever is Connected to it.
Was any of this helpful????