(I’ll even take 9600 7E1)

trs80gp comes to the rescue!

So I started to read the RS-232 manual to see whats going on. I started to wonder if at some point during the whole thing the driver maybe was hardcoded to go 300. I didn’t want to believe this, since I did move from 300 to 1200 with the Dataphone 212A. It would have meant that despite having a 1200 baud modem, it was talking at 300 on the back end. How embarrassing.

After reading the manual, it seemed there were 4 registers that would be of interest.

Register

So I worked to figure out how to know when anything happens to those registers. So I found out from the trs80gp and the developers that I could set it so any input or output to these registers would stop it.

So in the picture above, I set the debugger to catch any updates to those 4 ports, and if you look at E8-EB, its what is currently written. That’s’s what the default must be in NewDos/80. Ok, so I fire it off.

I see it send 06H to EA. Ok, not interested in that right now. I tell it to continue. We get all the way to it being online and ready and then stops.

If you look, it is sending 55 out to E9, which is the one I really care about. That’s the speed! I check the table from the manual again

Which, oddly, makes no sense. 55 would mean that its doing “130” in and out. But wait, why would 130 be between 130 and 600, and even be considered switch selectable. BECAUSE ITS A TYPO! There’s the 300 baud! For some reason there’s something in the code that sets it to 300 baud. So I look at the line that prints the “System initialized” message.

10 A$="System initialized and waiting for call":GOSUB100:T5=USR1(0)

Well, there we go. Whatever this USR1 is, with number 0, is setting it to 300baud. Ok, so I need to find out what number I have to pass to get it to understand I am looking at 9600. Back to trs80gp I go.

Since it has the ability to do memory breakpoints, I guessed a start and end address. I figure EE80 to EE9F. I run it, and it stops at EE86

The Scenario

Ok, this looks like the routine. If you look at “AF”, the “A” is 00, what we see in the line of basic. So, I change it to 1. I also change the debugger, since I don’t need to step through it, I only set it to stop at EE86 since the port debugger will stop it at EE9D for me. I enter 1, and GO. SUCCESS, sorta. It ends up changing to 22, which according to the table is 110 baud, nice. 2 gets me 44, or 150 baud. Odd, but closer. Now 3. That gives me 55, or what we assume is 300 baud.

But why make 0 and 3 the same. <SHRUG>. Ok, well, still higher. 4 is 66. That’s 600 baud. We’re going, but slowly. I decide to jump to 7. Its CC. 4800, SO CLOSE. So I go to 9, figuring I’ll jump over 7200 and go straight to 9600. Um, weird, I get 55 which again is 300 baud. HAHAH, I went to far. 8. 8 is the answer. I’ve found it, I’ve found how to set it to 9600! I run it again, put in 8, and waited for that glorious EE to show up. AND!

Um, excuse me, that’s not EE what I want, that’s 55. I run it again, and try again just in case I made a mistake. Ok, maybe something bigger. 9? Nope, 55. 10? Nope, 55. OH, wait, this is HEX, so I jumped from 9 to 16. Then we move to A, 55. B, 55. C, 55. D, 55. E, 55. F, 55. (Are you seeing the same disappointing trend I am). I decided a few more. 11, 55. 12, 55. I decide to give up. Time to investigate more.

Hey Tuc, remember when you did assembly almost 40 years ago?

So I decided to debug the code to see if maybe something would point me in the right direction. FORTUNATELY, we used to have the source code. It was really weird looking, but I knew I could edit and recompile it. So I looked for the block that matched the debugging.

09380 ALA LD A,L
09390 CP 08H
09400 JR NC,ALB
09410 CP 01H
09420 JR NC,ALC
09430 ALB LD A,(AML)
09440 AND 07H
09450 INC A
09460 ALC LD HL,ALP
09470 LD B,0000H
09480 LD C,A
09490 ADD HL,BC
09500 LD A,(HL)
09510 OUT (0E9H),A
09520 RET

So I take a look, and it makes a bit of sense. I’m sure I can follow along in the debugger. I look over the ALC bit first. It loads HL with the address of ALP. In the actual debugger, that comes to EF90. I point the memory part of the debugger to see if it will even GO 9600. I see

Kinda weird, EF90 would be 00, but we see 55. But if you look over at what is EF98, is our brass ring. EE. But why aren’t I getting it!?

So ok, lets start at the top and step by step.

09380 ALA LD A,L

That’s loading A with whats passed, nothing wrong here

09390 CP 08H

Ok, so its taking A and comparing to 8, which it is.

09400 JR NC,ALB

Ok, so I remember JR is “Jump Register”. That’s sorta like “goto”. I didn’t remember what NC was, but I figured if it was specifically listed, it would go there. And it didn’t.

Regis, I’d like to phone a friend

I didn’t quite understand what was happening, and needed some help, so I ended up posting on the Tandy Discord in “Troubleshooting”. A user named “Rocket Fueled” corrected my misconception, with one of the authors of trs80gp (“G Phillips”) expanding on it. The NC stands for “No Carry”, or as per a manual about Z-80 instructions :

This instruction provides for conditional branching to other segments of a program depending on the results of a test on the Carry Flag. If the flag is equal to 0, the value of displacement e is added to the Program Counter (PC) and the next instruction is fetched from the location designated by the new contents of the PC. The jump is measured from the address of the instruction op code and contains a range of –126 to +129 bytes. The assembler automatically adjusts for the twice incremented PC.

Clear a mud, huh? Well, its actually just saying “If the number is => the CP, then do the JR”. Apparently, if I wanted it to get to ALC unscathed with A as 8, the CP needs to be 9. WTELF?! You’re telling me BESIDES the fact that I ran a 1200baud modem at 300 baud for years, the program had been WRONG even in a version number 8.03a. That’s totally unreal. How the hell would it be wrong so long? Probably just because it knew I’d need it one day at 9600. 😉

IT’S A BIRD, IT’S A PLANE, IT’S SUPERZAP TO THE RESCUE!

So with a bit of searching the interwebs, I learned that the compiled instruction for “CP 08H” would be “FE08”. Using Superzap, I opened the RACSDVR/CMD file, and searched for FE08. One entry. So, I told Superzap I wanted to change it to FE09. I saved and exited.

Needed to edit “LOGIN/RAC”. Edited line 10 to reflect –

10 A$="System initialized and waiting for call":GOSUB100:T5=USR1(8)

Saved, and rebooted. Once again, I ended up at the System Initialized message. Hesitant, I connected the Mac back with Serial 2 at 9600, 8N1. Incoming call. I HAVE….um….a bit of garbage, but at least its something.

I changed to 7E1. SUCCESS!!!! IT WORKS!! I can type, it can type, we have success.

Ok, so its 7E1. I can probably find where its setting it to that, and zap that to. Not sure I want to. Given that the system didn’t expect any lowercase at the time, I’m concerned that people trying to use lowercase will have issues. Leaving it at 7E1 for now. So now I need to edit the Lantronix for the right bits. I do. And –

SUCCESS!!!!! (And a bit more embarrassment at the fact I misspelled “response”.)

So about port 2323, since I can telnet directly to the Lantronix ITSELF, I made the port for the actual serial port as 2323. As for the password, well, it’s sorta late tonight. More about it tomorrow. (Or so it might seem)