isdos zmodem routines v.0

Happiness, warmth and light in your home, Felix! 30 June 98 at 02:37 a letter from Felix Knajzev appeared to Michael Kondratyev. I decided to answer it.. FK>>> 1. The CPU wanted to grab a byte from the modem. (if using CTS/RTS) FK>>> 2. The CPU wanted to grab a byte from the modem. (if using Xon/Xoff) FK>>> 3. The CPU wanted to send a byte to the modem. (if using CTS/RTS) FK>>> 4. The CPU wanted to send a byte to the modem. (if using Xon/Xoff) [..gnawed..] FK> This is understandable. Only I “subtly hinted” ;) that at the _specific_ level FK> modem register show which bits in it need to be manipulated in order FK> (CTS/RTS) worked as you described above. So everything is very simple. Cts -- p+0x06 D4; Rts -- p+0x04 D1. FK> Just when I was trying to figure it out myself, "digging" your terminal, :) FK> I don’t understand why you write either #09 or #0B in the pb+4 register??? Enables/disables Rts. If Rts == 0 we don’t want to receive anything from the other side. Yes, in the version on interrupts we have to close them when we try to use dos, so that God forbid the interruption is grabbed and slammed... And this works out like can be seen from Misha’s program by transferring anything to port p+0x08+xx. Ais removed, respectively, p+00+xx. I work like this: We catch the interruption. Let's see if there is an interrupt waiting to be serviced (p+0x02 D0 <> 1). If not, then we don’t read anything. Then we read from the port. If We try to process the received byte(s), then we turn off Rts. We work on ourselves. We turn on Rts and continue to catch bytes. When transmitting to the modem, we wait for 1 in the Cts bit. Those. from p+06 we read the value, and so far the command 'And 0x10' does not give NZ We look forward to more. We check whether the receiver is ready to receive data (p+0x05 D5 <> 1). Otherwise, we pass it on. As usual, all the best. Paul.

Greetings, O Venerable Paul! 02-Jul-98 01:18 Paul Dikushin sent a letter to Felix Knajzev: FK>>>> 1. The CPU wanted to grab a byte from the modem. (if using CTS/RTS) FK>>>> 2. The CPU wanted to grab a byte from the modem. (if using Xon/Xoff) FK>>>> 3. The CPU wanted to send a byte to the modem. (if using CTS/RTS) FK>>>> 4. The CPU wanted to send a byte to the modem. (if using Xon/Xoff) PD> [..gnawed..] FK>> This is understandable. Only I “subtly hinted” ;) that at the _specific_ level FK>> modem register show which bits in it need to be manipulated in order FK>> (CTS/RTS) worked as you described above. PD> So everything is very simple. Cts -- p+0x06 D4; Rts -- p+0x04 D1. FK>> Just when I was trying to figure it out myself, "digging" your terminal, :) FK>> I don’t understand why you write either #09 or #0B in the pb+4 register??? PD> Enables/disables Rts. If Rts == 0 we don’t want to receive anything from that PD> sides. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From the modem? PD> Yes, in the version on interrupts we have to close them when PD> trying to use PD> dos, God forbid the interruption is grabbed and the memory slammed.. And this works, PD> as can be seen from Misha’s program, by transferring anything to port p+0x08+xx. A PD> is removed, respectively p+00+xx. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ In this paragraph, maybe I’m stupid :), but I didn’t understand anything. :( Dos=is-dos? "...grab the interruption and slam it..." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? PD> It works like this: PD> Grab the interrupt. Let's see if there is an interrupt waiting for service PD> (p+0x02 D0 <> 1). If not, then we don’t read anything. Then we read from the port. PD> If How about checking D0=1 from pb+5? Please explain, maybe there is a situation where there is an interruption, and D0=1 (in pb+2) ??? In "irza0505.com" Mikhail removed this check altogether! PD> we try to process the received byte(s), then we turn off Rts. PD> We work on ourselves. PD> Turn on Rts, continue to catch bytes. When transmitting to the modem, we wait for 1 in bit PD> Cts.If the program is written according to this algorithm, (which I have no doubt about!) then miss (lose) bytes from the modem when it sends them - basically impossible, IMHO. (???) But the bytes disappear! This is exactly the problem I have. :( Moreover, bytes disappear _only_ in _two_ cases!: 1. We work in team mode. Output of the same dump via AT&V. (When the 7th bank is full, the modem waits (!) - bytes don't disappear!) 2. We work with BBS, the log file is included. When the 7th is full banks (Or when the log file itself is updated on the disk?) - A whole “piece” of the log disappears! :( (When _received_ by XModem - no bytes are lost!!!) When we try to catch the next byte and read D1 from pb+5, then it is in "1" (!) - the previous byte is lost! (wasn't counted?) Here is a “piece” for reading a byte (bytes?) upon arrival of NMI from the modem: (c) by Mikhail Kondratyev! [omitted as unnecessary] NMI_RD LD BC,#02EF IN A,(C) RRA RET C;IT'S BAD INTERRUPT! (Is THIS necessary?!) NEXT_B LD HL,#0000;START BUFFER IN 7-BANK. BUF_7 EQU $-#02 LD BC,#05EF IN A,(C); that's understandable... ;Here I inserted ;) a check for byte loss: ; PUSH AF ; BIT 1,A ; JR Z,NOSKIP; no bytes lost ; LD A,2 ; OUT (#FE), A ;if lost, then BORDER_2. NOSKIP POP AF ;End insert. RRA RET NC; That's it, there's nothing more to take! LD B,#00IN A,(C); read byte in A... LD BC,#7FFD LD DE,(BNK0_7) OUT(C),D LD(HL),A; a few bytes into the 7th jar... OUT(C),E Maybe I should make RTS=0 here??? (in bp+4) INC HL; under the next received byte SET 7,H ; HL always >= #C000 SET 6,H ; LD (BUF_7),HL ; And here is the “dark forest” ;) LD A,#00; A<>0, when the received byte is output to the screen. ? LL5F22 EQU $-#01 OR A JR Z,NEXT_B LD DE,(LL5E77) SBC HL,DE LD A,H AND #3F SUB #3F JR NZ,NEXT_B; check for the end of the 7th bank? LD (LL5F22),A LD A,#09 LD BC,#04EF OUT(C),A; Do we tell the modem: “wait, smoke”? JR NEXT_B PD> That is. from p+06 we read the value, and so far the command 'And 0x10' does not give NZ PD> we wait further. We check if the receiver is ready to receive data (p+0x05 D5 <> PD> 1). Otherwise, we transmit. WR_TO0 PUSH BC PUSH AF R0BUSY LD BC,#06EF IN A,(C) AND #10 JR Z,R0BUSY LD B,#05 IN A,(C) AND #20 JR Z,R0BUSY LD B,#00 POP AF OUT(C),A POP B.C. RET This is the “piece” for sending a byte to the modem, does not raise any questions - everything is logical. (Naturally! :)Best regards, Felix!

Happiness, warmth and light in your home, Felix! 07 July 98 at 01:35 a letter from Felix Knajzev appeared to Paul Dikushin. I decided to answer it.. FK>>> I don’t understand why you write either #09 or #0B in the pb+4 register??? PD>> Enables/disables Rts. If Rts == 0 we don’t want to receive anything from that PD>> sides. FK> FK> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From the modem ? Yes. PD>> Yes, in the version on interrupts we have to close them when PD>> trying to use PD>> dos, God forbid the interruption is grabbed and the memory slammed.. And this PD>> is given, as can be seen from Misha’s program, by transferring to port p+0x08+xx PD>> anything. And it is removed, respectively, p+00+xx. FK> FK> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FK> ^^ ^^^ In this paragraph, maybe I'm stupid :), but I FK> _didn’t_understand_anything_. :( Dos=is-dos? "...interruption grab and ROM FK> collapse..." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? Well, like when an interruption arrives, we exit the ROM using the interrupt vector ornon-maskable interrupt. In any case, we get into trouble. Automatically the hard drive ROM will slam shut, and the return address will remain on the stack, but during the transition trdos will not be restored there, and we end up in the usual ROM 48.. PD>> It works like this: PD>> We grab the interrupt. Let's see if there is an interrupt waiting PD>> services (p+0x02 D0 <> 1). If not, then we don’t read anything. Then PD>> read from the port. If FK> And check D0=1 from pb+5 ? Easily. Just first you need to clarify whether it’s worth it.. ;) FK> Explain, please, maybe there is a situation where there is an interruption FK> and D0=1 (in pb+2) ??? FK> In "irza0505.com" Mikhail completely removed this check! Well done. Basically this is done to check interrupts cyclically, without running according to NMI.. Although this check will not hurt. Mish, what if our condition has changed? modem and we received an interrupt on it? (although there is a gag somewhere, it seems was).. FK> 1. We work in command mode. Output of the same dump via AT&V. FK> (When the 7th bank is full, the modem waits (!) - bytes FK> do not disappear!) FK> 2. We work with BBS, the log file is included. When the 7th is full FK> banks (Or when updating the log file itself to the disk?) - FK> a whole “piece” of the log is missing! :( Brrr... It's unlikely. Mishka’s, as far as I’ve seen, is quite dense everywhere shuts up.. Although, I believe. ;) What buffer size does Misha use? FK> (When _received_ by XModem - bytes are not lost!!!) Well, this is dialectics. Look at the transition to working with trdos, maybe there’s something there written.. FK> NMI_RD LD BC,#02EF FK> IN A,(C) FK> RRA FK> RET C;IT'S BAD INTERRUPT! (Is THIS necessary?!) Leave it. The modem can generate various interrupts. According to the documentation, it should. FK> NEXT_B LD HL,#0000;START BUFFER IN 7-BANK. FK> BUF_7 EQU $-#02 FK> LD BC,#05EF FK> IN A,(C); this is understandable... FK> ;Here I inserted ;) a check for byte loss: FK> ; PUSH AF FK> ; BIT 1,A FK> ; JR Z,NOSKIP; no bytes lost FK> ; LD A,2 FK> ; OUT (#FE),A ;if lost, then BORDER_2. FK> NOSKIP POP AF FK> ;End of insertion. FK> RRA FK> RET NC; That's it, there's nothing more to take! FK> LD B,#00 FK> IN A,(C); read the byte in A... FK> LD BC,#7FFD FK> LD DE,(BNK0_7) FK> OUT (C),D FK> LD (HL),A; a few bytes into the 7th jar... FK> OUT (C),E FK> Maybe I should make RTS=0 here??? (in bp+4) No. FK> INC HL; under the next received byte FK> SET 7,H ; HL always >= #C000 FK> SET 6,H ; FK> LD (BUF_7),HL FK> ; And here is the “dark forest” ;) So the buffer is cyclic. It is from 0xC000 to 0xFFFF (1100 000 and 1111 1111) When we are flying beyond the buffer, we need to do 0xC000, i.e. need to install seventh and sixth bits. (they are always installed in the buffer, so it’s not superfluous to have them post it again.. ;) FK> LD A,#00; A<>0, when the received byte is output to the screen. ? FK> LL5F22 EQU $-#01 No. When the space in the buffer is less than 256 bytes (i.e. so much space has been added a lot that the computer simply does not have time to process), then nothing else is needed in shove the buffer.. FK> OR A FK> JR Z,NEXT_B FK> LD DE,(LL5E77) FK> SBC HL,DE FK> LD A,H FK> AND #3F FK> SUB #3F FK> JR NZ,NEXT_B; checking for the end of the 7th bank? FK> LD (LL5F22),A Check for lack of space. (what I described above) FK> LD A,#09 FK> LD BC,#04EF FK> OUT (C),A; We tell the modem: “wait, smoke”? FK> JR NEXT_B Something like that. It is turned on, as you can see, in the procedure of reading from the buffer. Here here the parking lot is small, visible to the naked eye - if we have 256 seats, then we shut down the modem. There may be more in the modem buffer (up to 1024). This means we are losing a piece of the log equal to 16384. Next. When reading from the buffer, we turn on RTS with 257 bytes of free space. This is also not a fountain. We need to shut uprts with the remaining free space equal to 1024, and open at 2048. Well, or something within these limits. FK> This is the “piece” for sending a byte to the modem FK> does not raise any questions - everything is logical. (Naturally! :) The rest is even more logical.. ;) As usual, all the best. Paul.

Hi Paul, In a message of to Felix Knajzev (2:5030/529.13@fidonet), you wrote: PD> Brrr.. This is unlikely. Mishka's, as far as I've seen, is quite dense everywhere PD> shuts up.. Although, I believe. ;) What buffer size does Misha use? Chichas while the buffer is exactly 1 byte. less (i.e. without a buffer) is not possible. when (and if) I’ll get to the bidirects - there will be 2k input/output and transmission by interruption. Bye, Michael.