Well...

Hello, All Kir> Zhavoronkov Sergejj -- 115200 delal. Ja ogranichilsja na urovne Kir> 38400. Here I would like some clarification, apparently in this method a high error rate (or more likely it was the transmission speed, and the analysis the transferred data was not carried out immediately, but only later, after the transfer), because 3500000/115200 = 30 clock cycles per bit (not a byte, right?), despite the fact that The minimum port read command is 12 clock cycles. The algorithm that I am above I suggested that you can also overclock it “slightly”, but not by that much... P.S. By explanation I assume a specific algorithm

Press RESET immediately, Valery Grigoriev! On Mon, 31 Oct 05 17:35:56 +0300, Grigoriev Valery wrote: GW> Hello, All Kir>> Zhavoronkov Sergejj -- 115200 delal. Ja ogranichilsja na urovne Kir>> 38400. GV> Here I would like some clarification, apparently in this method a high level was allowed GV> error rate (or, more likely, it was the transfer rate, and GV> analysis of the transmitted data was not carried out immediately, but only later, after GV> transfers), because 3500000/115200 = 30 clock cycles per bit (not byte GV> right?), despite the fact that the minimum command for reading a port is 12 clock cycles. That GV> the algorithm that I proposed above can also be “slightly” overclocked, but not by GV> so much... http://www.google.com/groups group:fido7.zx.spectrum Newsgroups: fido7.zx.spectrum From: Kirill Frolov X-Comment-To: Andrew V. Miheev Subject: Re: 32bit SIMMs Date: Sat, 27 Sep 2003 05:47:27 +0400 Press RESET immediately, Andrew V. Miheev! On Fri, 26 Sep 03 11:16:01 +0400, Andrew V. Miheev wrote: >>>> AVM> Communication with a modem/another machine. >>>> 1. programmatically AVM>>> At what speed? This is only to convey individual letters, but not as not AVM>>> data in tens of kilobytes. >> I have 38400. The moderator claims that it is 115200. I believe that this is already >> on the verge of fantasy, unreliable. AVM> Did you write it yourself or did you use something ready-made? I took the idea from the creators of ZX-TCP. AVM> Where can I see the implementation? From my letter: === cut here === Here, on the RXWAIT label, the leading edge of the start bit is caught. moment must be determined accurately enough, otherwise by the end of the byte transfer an error will accumulate in the last bits (you need to withstand ~5% there, definitely not I remember). The signal quantization period is 20 clock cycles = 5.7 µs, while The bit transmission period at 115200 speed will be only 8.6 µs. Less than 20 clock cycles can no longer be done (one IN command takes 11 clock cycles). That is it turns out that at 3.5Mhz the Z80 is basically not capable of sufficient accurately catch the leading edge of the start bit, and therefore carry out the bit synchronization. The error occurs within those same 5.7 microseconds, and if towards the end of the byte adding up all the errors will result in complete nonsense instead of what is accepted byte. The transmitter code is trivial, I won’t comment on it. The raw version (driver piece) is designed for a speed of 38400 bps:;--------------------------------------- ; RS232 EMULATOR ZX-LINK ; ; transmitter port (this is #1ffd on scopion) TXPORT EQU #CFF7 ; maximum receiver buffer size in bytes RXMAX EQU 270 ; driver initialization ZXL_INI LD A,1 JR ZXL_CTL ; disabling the driver ZXL_OFF XOR A ; DCD signal setting ZXL_CTL ;LD (ZXL_DCD),A AND #01 RLCA RLCA LD (TXMASK),A IN A,(#1F) RLCA RLCA RLCA AND #01 RET ; LINE SCAN returns BC=SIZE D=SPEED CY=NOTHING (MMD2.20 driver standard) ; waiting for bytes from the PC for a specified time LSCAN DI PUSH IX PUSH IY LD HL,RXMAX LD DE,RXBYTE PUSH DE LD IX,(M_BUFF) LD IY,TXMASK LD BC,TXPORT LD A,(TXMASK) OR#20 OUT (C),A ; setting CTS for pussy - transmission permission RXNEXT LD D,#9F ; TIME 0x9f+0x100 cycles RXWAIT IN A,(#FE) R.L.A. RET C IN A,(#FE) ; 25..34 ~40 R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) ; here comes the waiting for the front RLA ; edge of the start bit RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET CDEC D JP NZ,RXWAIT ; +14 IN A,(#FE) R.L.A. RET C LD A,(TXMASK) ; here the timeout expires - reset CTS for the PC LD E,A ; +17 ; and waiting for the time of transmission of the "last" byte IN A,(#FE) ; from the transmitter buffer to the PC R.L.A. RET C OUT (C),E ; +12 IN A,(#FE) R.L.A. RET C LD D,#7 ; +7 IN A,(#FE) R.L.A. RET C RXWAIT1 IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C IN A,(#FE) R.L.A. RET C DEC D JP NZ,RXWAIT1 ; no bytes were received from the PC within the specified time RXEND POP BC EX DE,HL LD HL,RXMAX OR A SBC HL,DE POP IY POP IX JR NZ,RXOK LD BC,#0101 XOR A INC A SCF RET ; successful completion (something accepted) RXOK LD D,LINKSPEED LD B,H LD C,L XOR A INC A RET ; front edge of start bit detected! RXBYTE IN A,(#FE) ; check in the middle (approximately) RLA ; bit intervalJR C,RXBYTE1 ; yes -> receive byte DEC SP DEC SP ; no -> false positive JP RXWAIT RXBYTE1 JR$+2 JR$+2 JR$+2 JR$+2 NOP IN A,(#FE) ; B0 ; the first bit is received R.L.A. RR E DEC HL LD A,H OR L CP 1 SBC A,A CPL AND #20 OR (IY) OUT (C), A ; here CTS is disabled when the buffer overflows IN A,(#FE) ; B1 R.L.A. RR E LD BC,RXBYTE PUSH BC LD BC,TXPORT JR$+2 JR$+2 JR$+2 IN A,(#FE) ; B2 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOP IN A,(#FE) ; B3 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOP IN A,(#FE) ; B4 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOP IN A,(#FE) ; B5 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOP IN A,(#FE) ; B6 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOPIN A,(#FE) ; B7 R.L.A. RR E JR$+2 JR$+2 JR$+2 JR$+2 JR$+2 NOP NOP IN A,(#FE) ; B STOP ; last stop bit R.L.A. JR C,RXERR ; if the stop bit is not 0 -> error LD A,E CPL LD(IX),A INC IX JP RXNEXT ; receiving the next byte (waiting for the start bit) ; an error occurred (synchronization failure) in the receiver RXERR LD A,(TXMASK) OUT (C),A ; disabling CTS - prohibiting transmission for the PC JP RXEND ; return with error indication ; SEND BLOCK IN MDMBUFF BC=SIZE LTRANS DI PUSH IX LD E,C LD D,B LD IX,(M_BUFF) LD BC,TXPORT TXBYTE LD A,(TXMASK) OR#08 OUT(C),A LD A,(IX) CPL LD L,A LD H,8 JR$+2 LD A,0 TXBIT RR L SBC A,A AND #08 OR 0 TXMASK EQU $-1 OUT(C),A JP$+3 JP$+3 JP$+3 LD A,0 DEC H JR NZ,TXBIT JR$+2 LD A,0 LD A,(TXMASK) OUT(C),A JR$+2 JR$+2 JR$+2 INC IX DEC DE LD A,D OR E JR NZ,TXBYTE LD B,4 DJNZ$ POP IX RET Unfortunately, there is one error that does not manifest itself in any way whencorrect operation of the PC COM port but potentially very dangerous (as always buffer overflow). The error there is that after when the receiving buffer is full, the Spectrum resets the CTS so that the pussy stopped transmitting, after which the Spectrum receives the last byte (CTS signal blocks the transmission of the next byte, but the current one has already begun be transmitted). Only in the process of receiving the last byte Spectrum It doesn’t accept just one byte, but how many they give. More than one usually the pisyuk does not give, but if it does, the Spectrum will receive up to victorious end. In this case, the criterion for the end of transmission for the Spectrum serves as a long stop bit, that is, a pause in transmission of several bits intervals. I'll definitely fix this bug, I'm just too lazy right now... === cut here === And this is from the moderator’s letter, where he has 115200: ===cut here=== KF>>> IMPOSSIBLE. RS232 program receiver without turbo mode only on KF>>> 38400bps. works stably. More performance KF>>> the processor does not allow synchronization using the start bit KF>>> - synchronization is not accurate enough, errors appear. SZ>> "IMPOSSIBLE" ... also in capital letters :). But it works for me, strange. SZ>> Loading all 48k of memory lasts approximately 5-6 seconds, and only SZ>> half of the time (at a very rough estimate) is spent on actual activities SZ>> byte transfer. SZ>> "Never say never." I have witnesses that this is SZ>> works :). KF> Bring the receiver code for the Z80! Please: (pacing in brackets, frequency 3.5 MHz) in A,(C) ; waiting for the start bit (12) jp P,*-2 (10) ld A,(0) ; delay (13) in A,(C) ; next bit (12) rla rr L; received byte (8) inc DE (or dec DE, every other time) (6) ... repeated 8 times alternating inc dec nop nop nop in A,(C) ; stop bit jp P,... ; no error error: ... The code runs from ROM. In the sense that from “fast” memory. KF> Here, on the RXWAIT label, the leading edge of the start bit is caught. KF> The moment must be determined quite accurately, otherwise by the end of the byte transfer KF> an error will accumulate in the last bits (you need to withstand ~5% there, definitely not KF> I remember). The signal quantization period is 20 clock cycles = 5.7 μs, while KF> the bit transmission period at a speed of 115200 will be only 8.6 microseconds. Less than 20 KF> cycles can no longer be done (one IN command takes 11 clock cycles). I have 26 bars per bit. One clock cycle at 3.5 MHz is equal to 0.2857 microseconds. 0.2857 * 26 = 7.4282 µsec, this is how it turned out for me. KF> That is, it turns out that KF> at 3.5Mhz Z80 is basically not capable of catching with sufficient accuracy KF> leading edge of the start bit, and therefore carry out bit synchronization. KF> The error occurs in those same 5.7 microseconds, and if you add everything to the end of the byte KF> errors will result in complete nonsense instead of the received byte. For some reason it works. And there are no errors. I wonder why? :) === cut here === I believe that 115200 is already on the edge where today and on this the machine works, and tomorrow it will work on another - unknown. AVM>> What else can it do at the time of reception and transmission? Nothing? Well, why AVM>> is it needed? >> It also cannot transmit at the time of reception. So port >> asynchronous, no problem. To block reception at the time of transmission >> has CTS. AVM> Where? Tell us more about hardware and software. What's where? A full-fledged port in a PC or modem. Another defective Spectrum. For normal operation, one full-fledged one is enough. A defective Spectrum port can receive or transmit strictly in certain point in time, and the rest of the time it blocks transmission at computer (modem) with a CTS signal. Two Spectrums can be connected like this more difficult - they will have to work synchronously, one in transmission, the other at the reception. But it worked in Interface-1, there is a whole network of Spectrums like this was organized. Software, to communicate with the PC, I used MMD (Macro Modem) on Spectrum and its compatible analogue for pisyuk. MMD is a program for Spectrum modem connection (their own modems, not private ones, not with digital ones compatible). Files were transferred back and forth and commands could be given for a pussy from Spectrum and vice versa. It was possible to control Linux from Spectrum. >> That's what I'm saying - it turns out to be easier programmatically. Although, for the modem >> better than 580ВВ51 (you can simultaneously draw letters in the terminal). AVM> For a modem, the native Z80SIO is better. Not better. It is programmed in a non-standard/unusual way, and its I need to get more from somewhere. Software is better than 16550A, but it tooThere’s nowhere to get it from, it’s easier to just screw on a fancy “multi-card” right away.