I recently got hold of a ZX Spectrum +3 and am trying to get RS232 working with the spectrum. I’ve built a cable (‘BT’ style connector <-> DB9 serial) following the pin out of the cable (Spectrum 128 RS232 data cable) here.
The other end of the cable is connected to the PC using a USB-Serial adapter. I'm using Moserial on Linux to communicate with the Spectrum.
The cable works and I can use LLIST to print BASIC programs over the serial port, but I'm unable to get the Spectrum to read from the serial port reliably - even when enabling hardware handshaking (DTR/CTS) in Moserial.
I wrote a simple program in +3 BASIC to print received characters to the screen. It seems the first character is received OK, but the remaining characters are dropped or become corrupted.
Here is an example of what the Spectrum outputs when attempting to send 'zx spectrum' at 300 baud:
z[dot/box character]. VAL$ [box character]MOVE VAL$ VAL$ ?)
(it seems VAL$ and MOVE$ are each a single character in the Spectrum's ROM)
screenshot:
And the BASIC program which opens the serial port, and prints received characters to the screen:
10 FORMAT LINE 300
20 FORMAT LPRINT "r"
30 FORMAT LPRINT "e"
40 OPEN #4,"p"
50 PRINT INKEY$#4;
60 GO TO 50
I discovered that if I send characters one-by-one from the PC with a long enough delay between them, I can get a much more reliable output from the Spectrum. I tested this with different delays, and 80ms worked the best. I don't really want to use this approach as a solution - it's awfully slow and occasionally some characters are dropped.
Could this be an issue with the Spectrum itself? Or am I missing something in my setup? Something just doesn't seem right, I know there is a program loader for the spectrum over serial - so surely the spectrum must be able to accept serial input without a 80ms delay per character?
The ZX Spectrum Interface 1 works by bit-sampling, in a software loop, with delays, so that it can look for the start bit and then look for the other bits. There is no shift register. It's all done in software.They don't even use interrupts or some other kind of fixed external timer to generate baud rate delays.
As a result, it doesn't even start looking for a start bit until it knows you're looking for input... Now that you have an idea what's going on I'm pretty sure you've already seen the problem there? If you're sending data too fast, then your basic program doesn't even have time to go back to the receive routine to look for start bits, and start bits are going to be lost, or more likely, you're going to pick up a bit transition mid-byte and receive gibberish... So you need to make sure that there's a delay between bytes and your Spectrum is ready to receive the next byte before you start transmitting.
Hope this helps even though it's a while ago, but others will find this so...
In zx spectrum 48k, with interface 1, i must choose how the rs232 will work.
Mode t : text ->rx and tx only character in 7bit
Mode b: byte -> rx and tx full byte (8 bit)
Maybe you must chek that.
On 48k with interface 1
FORMAT "b";9600
Then , the spectrum works in 8bit data at 9600 bauds.
In your code, i dont see how will works.
My best regards.
I came across your problem as I was trying to do the same!
You need to enable RTS/CTS handshaking in your linux (PC) application, not DTR/RTS.
This works for me on my Spectrum+2:
100 REM ** Receive Test **
110 REM ** Use RTS/CTS **
120 CLS
130 FORMAT "p";9600
140 OPEN #4,"p"
150 PRINT INKEY$#4;
160 GO TO 150
There's software incompatibility between modern computers and ZX Spectrum when doing serial communication. It can be fixed, but not from Basic. The problem with RTS/CTS is that after Spectrum signals that it can't receive any more data via the CTS signal: modern UART chips will assume that the receiving computer is still able to receive cca. one buffer of data (=up to 32 bytes). But ZX Spectrum only has 1 byte buffer. So when Spectrum says its' full, it will get flooded by additional 32 bytes of data.
That is the reason anything faster then 1200 bauds will not work from BASIC. However ... I got ZX Spectrum to run reliably at 57600 and with error correction at 115200. By simply expecting up to 32 bytes after I signal the PC to stop sending data.
I've had all this working years ago with my Spectrum and the ZX Interface 1's own rs232 port, but I wrote some C program using an old Windows 386 computer.
I still have the hardware and the cables. In fact, now that I remember I had to build my own "null modem" cable and connect it from the RS232 port on the computer to the ZX Interface 1 (I have an old Sony Vaio laptop with an RS232 port).
I was even able to download TAP files to play on the real spectrum. I'll dig up what I have and get back to you.
Related
I have an older Aanderaa RCM9 (https://epic.awi.de/id/eprint/45145/1/RCM9.pdf) that is missing its Data Storage Unit and its reader. They don't produce these anymore nor do they service the model. It would be a shame to toss an otherwise nice piece of equipment, so I thought to try and get a serial feed from the terminal or DSU output and log on an Arduino with an SD card. I have tried to connect with a TTL-RS232 converter, and there seems to be a consistent Tx from the instrument, it comes in batches, but reads out in CoolTerm as "............" I've tried different terminal configurations, and connections, but that's the best I get. Here's how it looks inside: https://imgur.com/a/xxCPUlQ
Any thoughts??
I am afraid that the output is the old Aanderaa PDC4 serial format where long pulses (81ms) represents zeros and short (27ms) represents ones in a 10 bit binary word framed in a 4 second window.
I was working on this project : http://elm-chan.org/works/sd8p/report.html
and I failed in every possible way from the start. Now that the .Hex files have been uploaded, and the fuses written, when I plugged the SD card in, nothing happened. Nothing at all. Directly asking for a solution might be impossible here as I have no idea what went wrong. So instead I tested the speaker's positive connection with the arduino serial plotter, and I found some interesting results. The output gave some cool irregular pattern of waves,similar to what I would expect from a sound output. But there was no sound, and I suspect that it was because of the output size being too small.(60/1023 is around 0.06 volts, 200/1023 is around 0.2 volts and the bigger output at 500++ levels out, so it shouldn't produce a sound.)
So now I would like to ask whether I can change the fuses of the .hex file(or the hex file itself, but its big.) to produce a larger output. I have not much understanding in hex files or even AVR devices, so any hep at all would be useful.
Thanks in advance.
the graphs
Please let me know if any other information is needed.
Your voltage output on a GPIO pin is limited to your supply voltage, so no you probably can't fix your problem by changing the software or the fuse bits. Depending on your current supply voltage, you might be able to crank that higher, which would increase your voltage output of the PWM, but the supply voltage can only go so high without damaging the chip.
That being said, you need to disconnect the amp and speaker from the AVR and probe the output pin of the PWM and make sure that it is actually producing a signal on that pin. The plots that you posted with that amplitude look like they are nothing but random electrical noise to me.
I write a simple Arduino software where I read some information on analog pins.
I compile this software on an Arduino Leonardo and on a Funduino Mega. Anyway, the Arduino obtains a better sampling frequency. Did you think that I can improve the frequency performance if I buy an Arduino Mega?
The main difference is using on-chip USB interface on Arduino Leonardo. You can use baud rate settings, but it'll be ignored and it'll run as fast as it's possible.
On the other side, if you're using Mega 2560 with Serial.begin(9600); and for example Serial.println(analogRead(A0));, then it's not possible to get about theoretical 15000 samples per second as you can send only about 960 characters per second.
Btw: for three 8bit characters (for HEX representation, 4 characters for DEC representation), "\r\n" separator and 15000 samples/s you'll need baud rate about: 5*(1+8+1)*15000 = 750000 baud/s (8bit characters + 1 start bit + 1 stop bit)
Hi i am working on Tmote sky motes (MSP430 microprocessor) with contiki os. I want to know the number of instruction cycles used when I do a multiplication operation in my programming (software).
Thank you,
Avijit
The msp430 is a 16-bit system, so 32-bit values are not supported directly. A 32-bit operation is typically translated to assembly code as a sequence of 16-bit ops.
The execution times of 8-bit and 16-bit operations can be found in TI application report "The MSP430Hardware Multiplier":
Table 4. CPU Cycles Needed With Different Multiplication Modes
OPERATION: Unsigned Multiply (MPY)
SOFTWARE LOOP: 139...171
HARDWARE MPYer: 8
SPEED INCREASE: 17.4...21.4
OPERATION: Unsigned multiply-and-accumulate (MAC)
SOFTWARE LOOP: 137...169
HARDWARE MPYer: 8
SPEED INCREASE: 17.1...21.1
OPERATION: Signed Multiply (MPYS)
SOFTWARE LOOP: 145...179
HARDWARE MPYer: 8
SPEED INCREASE: 18.1...22.4
OPERATION: Signed multiply-and-accumulate (MAC)
SOFTWARE LOOP: 143...177
HARDWARE MPYer: 17
SPEED INCREASE: 8.4...10.4
The HW multiplier should be active with default compilation settings, but check the generated object file with msp430-objdump to make sure.
You can use naken_asm by Michael Kohn to disaemble an Intel hex or ELF file and it will calculate the cycle counts for each instruction. I've used it in the past and the cycle counter is OK for CPU (such as in your Tmote) but not fully supported in CPUX.
You can invoke it from the command line as simply as:
naken_util -disasm <infile>
where <infile> is the name of your hex or ELF file. The default processor is MSP430, but you'd need the assembly listing from your compiler in order to be able to match up the original code with the disassembled code which includes cycle counts.
Another alternative would be to use MSPDebug's tracer option which can track running software and provide an up-to-date instruction cycle count. However, I've never used it for that purpose so cannot provide an example.
I have connected a device which sends data over a serial port, through UART and a usb connector.
On my laptop running ubuntu, I have written a C++ program to read this data and store it.
It sends 5 lines of 15 bites, 100 times per seconds, meaning: 500 lines per second.
I use the standard read command:
while((res += read(IMU, header, 15-res)) < 15);
string head(header, 15);
cout << indexLog << " " << head << endl;
when I read the serial port and read 15 bites it shows:
0 snp�` �����
0 snp�b#A��H
0 snp�dP�O�^���
0 snp�\����f
0 snp�^���e��M
0 snp�` �����
0 snp�b"����
where the snp is the beginning of each package. It can be seen that my laptop nicely reads every bite coming in, since every line starts with snp.
I would like to run the same application on my Raspberry PI, for weight and size considerations.
now when I run the same application on my raspberry PI, I get:
0 �Nsnp�Nsnp
0 Nsnp�\��
0 vsnp�^���
0 np�^�O�
0 vsnp�^�O�
0 np�^�D�
0 ssnp�
0 X�snp�dU
It looks like the raspberry doesn't read all the bites, and it becomes a big mess. Trying to salvage usefull date results in big data loss.
I all ready installed a skimmed down version of Rasbian, weezy. deinstalled X as GUI. But it doesn't seem to make difference.
I believe the raspberry should be fast enough.
What would be the limiting factor?
Is reading 500 lines (15 bites) per second over a serial just to much to cope with for the RasPI?
Are there any settings I can change or OS for the raspberry which can do the job better?
Or is there a way in C++ to read the data more efficient?
kind regards
Is reading 500 lines (15 bites) per second
That is 500 x 15 x 10 = 75000 bits per second. Clearly that is not possible when your baudrate is only 38400. So transmitter overrun is your first candidate for data loss.
You also have a fire-hose problem on the receiving end. Your terminal needs to be able to keep up with the rate, 500 lines per second is pretty challenging. Scrolling the window fast enough is the usual problem, not to mention the poor eyes of the user that needs to stare at this Matrix effect. This is the more likely source of the data loss, when you don't empty the serial port receive buffer quickly enough then you'll suffer from buffer overflow. It can also occur when the driver doesn't empty the UART fifo buffer quickly enough, less likely to be a problem at 38400 baud.
The obvious way ahead here is to improve your code so that you can actually detect these kind of errors so you know when it goes wrong.