Reading from the 128 Serial Port
Don't shout at me if this is a silly question. I have Googled extensively, and searched the forums, but I can't find anything discussing what seems to me to be an obvious question. Even the Manual doesn't discuss it!
How do you read incoming data from the Serial port on the Spectrum 128?
The Manual only talks about sending data out of the serial port (using LPRINT) but makes no mention of receiving data coming the other way.
Thanks.
How do you read incoming data from the Serial port on the Spectrum 128?
The Manual only talks about sending data out of the serial port (using LPRINT) but makes no mention of receiving data coming the other way.
Thanks.
Post edited by trellis on
Comments
with great difficulty, I don't think there's a way to do it from basic easily :(
if you use machine code it is easy I guess but I don't know z80 mc really.
I think the z88dk compiler has some serial functions in it's spectrum library but I never really spent much time trying to get them to work.
Of course, it's just a stream isn't it. Duh! I know it was a stupid question.
There's even an example program in the manual to read data from the RS232 port :D
Thanks folks.
I'm sure there was some stupidly annoying reason that this didn't work properly on the +3, but maybe I'm just mis-remembering it's been a while since I did any serial stuff with the speccy
I remember it took me ages to actually get the cable working.
cause the pin names in the manual are "wrong" iirc
the handshaking pins are silly I think
I did fathom it out in the end, mostly by trial and error, and some googling. I think two of the pins have the wrong names (not swapped, just "wrong" in some way)
Further, there's the whole question of which lines get used for handshaking; PCs these days tend to use RTS/CTS handshakes, but the 128 uses DTR/CTS, giving more opportunities for fun.
that's the one, normally it's normally either RTS/CTS or DTR/DSR
Using INKEY$ and LPRINT I've got characters typed on the +3 appearing in HyperTerminal on the PC, and vice-versa, but obviously using INKEY$ in a loop is far to slow to do anything useful.
What is the correct method for using INPUT with streams? The manual seems to gloss over this and doesn't explain it properly at all.
If I type the +3 seems to start accepting characters from the PC, but as soon as it sees a carriage return, it squirts a stream of garbage out of the RS232 port, and reports E Out of Data. After this, a$ is undefined.
The stream of garbage it squirts out is always the same:
Any ideas appreciated!
I didn't want to bother him again because my original intention was to find a way to explore the ports without the need for additional hardware. I don't understand all the technical details, but it seems Amstrad gave us an aux port that's less reliable than the one on the IF1. :o
Still, the ports are there and the idea of using them has always fascinated me. Simple communication between a Spectrum and a PC without interfaces. Just terminals on each side to send and receive binaries and, who knows, the ability to write EDSK images without having to go through the usual steps.
If error checking isn't part of the AY's serial data capabilities, can't we send use some type of checksum every n bytes?
Hmmm, yes, he makes a very persuasive argument doesn't he :-(
Actually, at the best of times RS232 only offers a very simple parity bit for error checking, and in most cases even that isn't used, so there isn't any kind of error detection. Any error checking and recovery is usually left for higher-layer protocols to deal with, so that's not really a criticism that can be levelled at Amstrad's implementation ;-)
I was hoping that using INPUT instead of INKEY$ might enable me to pull in a chunk of bytes at wire-rate into a BASIC string variable, and deal with it from there. But my experimentation so far has shown that this may not be possible. Even sending a long string out using LPRINT doesn't go at wire speed, even at 9600.
It could be that the BASIC ROM routines are very inefficient, but I suspect the problem with the +3's built-in port may simply be one of speed.
I gather that the problem is that there is no hardware fifo buffer and the spectrum is effectively emulating the serial port buffers in software.
This might be nonsense but I'm sure someone has said it doesn't have proper input and output buffers like a proper rs232 controller
it's called zfst and isn't easy to find but there's a copy here http://www.geocities.com/ResearchTriangle/4535/tools.html
Working with files cannot be more easy. On PC, I've made simple BAT file with syntax "s filename.tap" to "send" file to ZX. "r filename.tap" to "receive" file from ZX.
My system is MB02, but with low effort it can be implemented on divIDE, MDOS or other systems allowing to map RAM instead of ROM.
http://omega.webnode.com/products/rsp/
It works very nicely as a terminal, but like you, I can't seem to get the XModem transfer function to work in either direction. HyperTerminal has "XModem" and "1K XModem" options - neither works to ZFST.
Even with ZFST on the real +3 talking to ZFST running on an Emulated +3 on the PC, nothing happens, yet I see lots of data flying around on the Breakout Box.
(In all cases, the two machines talk to each other in Terminal mode, so it's not a comms problem).
However, it looks like it could be a good starting point for further development.
yeah the hyperterminal transfer thing looks to be totally incompatible
but I never got around to trying the utilities that he documents in the manual.
that's probably a handshaking issue, it does mention that that is the most likely cause in the manual. so either the cable is wrong, or the emulator doesn't fully emulate the serial port/use the same handshaking/allow bit banging the pins.
it would be helpful if you could use another computer wired onto the data lines to display what data is going back and forth on a terminal.
though I suspect I already know, it's some sort of ping type thing if I remember correctly. the receiver telling the sender to go ahead and send the next packet
he obviously got it working, so it must be possible, at least when the stars are aligned, you're wearing the right colour shirt and the null cable is lying along an ancient leyline
http://www.worldofspectrum.org/forums/showpost.php?p=47311&postcount=6
It's an old post, but after checking his post history I found he used zfst extensively without any problems and recommended it several times.
Could it be that the problem is HyperTerminal? It seems he was doing everything with Linux, not Windows.
to avoid any ambiguity I think you need to try a) the utility he mentions in the manual, b) a real serial port if you aren't already, and c) a cable wired the way it says in the manual if you aren't already.
a) I'll boot Knoppix and give it a try, but even if it works, it'll be pretty useless. I really need it to talk to the emulated +3 to trasfer disk files.
b) It's a 9-pin D connector on the back of my PC, which Windows refers to as COM1. Is there such a thing as a 'fake' serial port?
c) Does he mention how to wire the cable in the manual? All I can find is a brief mention of a 'Null Modem' cable, which is effectively what I'm using. I don't think the cable wiring is the issue as I have no problem sending characters in both directions between the machines.
I suspect the same thing. I successfully connected a Spectrum (clone actually) IF1 serial port with a PC RS232, using hardware handshake. It works very well, even at 19200 baud. The main issue is to send a single byte at a time from the PC side to the Spectrum, otherwise the Spectrum would choke, because it's not fast enough to receive more than one byte at once (I mean, to call the SendBytes function each time with only one byte).
I tested 2 utilities, that work great with this connection:
SPXFR
PCZX.
I meant like a USB to serial adapter, if you have a proper hardware com port that's fine.
I think the hyperterm implementation and the spectrum implementation are using different checksums and handshaking protocols. The hyperterm version is a "clever version" and the speccy is using a "simplest version possible" implementation
It seems that the xmodem protocol changed a lot over the years (contrary to the author's wishes). Maybe the +3 uses the original one.
edit: Has anyone tried to emulate a +3 with Spectaculator and transfer data to a real +3 by using Spectaculator's serial port redirection? If Spectaculator's emulating the +3 serial port correctly it should send data that the real +3 can understand.
edit2: Hyperterminal's xmodem implementation is described here:
http://msdn.microsoft.com/en-us/library/ms817548.aspx
spectaculator, 5.30 at least, only redirects serial *output* it doesn't read input by the look of things, so it will not work for transfers with zfst.
I have got two real +3 machines, but only one PSU, so I'm not currently in a position to try linking two real +3s together, which would be an interesting (if rather pointless) exercise :-)
The folks at Speccy.org have replied to my topic. I shall be translating and posting their input here later today.