Superbrain Kermit (4.11 and 4.03) not playing nice.

[Witchy]

Hi folks,

Since I can't, currently, make cpmtools read any of the Superbrain disk images I have I thought I'd try kermit for file transfers since I already have a distribution of 4.03 on one of the disks. Trouble is I don't know which port it was built for. The PC end is Win10 with an FTDI USB-serial converter (COM4).

(I should point out that I'm well versed in RS232 foibles and all the swearing and gnashing of teeth involved therein, but having typed all this I'm now having a nagging doubt about USB converters but with flow control off then the lack of control signals shouldn't be a problem)

Thankfully I remembered how I transferred files down to my Exidy Sorcerer initially using a terminal emulator called RealTerm. Setting both 'Brain and PC baud rates to 300 I squirted text down the main port with PIP FOO=RDR:[E] which echoed what I was typing on the PC end and a CTRL-Z on the PC end wrote the file to disk. Splendid. Main port works. 9600 baud is OK too.

Running Kermit 4.03 just locks the machine up whenever I do anything involving the serial port however, slightly frustrating since it's difficult to pinpoint WHAT makes the machine hang. I know the comms work fine, at least on the main port. Aux port also locks up with flow control on or off.

I grabbed the oldest downloadable Kermit-80 source distro which is 4.11 and split the main CPSKER.HEX into 6 easily transmittable chunks, sent them down to the 'brain then joined them all together with PIP CPSKER.HEX=KER1,KER2,KER3,KER,KER5,KER6. I also sent down CPVBRA.HEX and CPVBRM.HEX which are Superbrain specific modules for using the Aux port and Main port respectively, as well as MLOAD.HEX to build everything.

Joining them together was as easy as

LOAD MLOAD
MLOAD K411AUX.COM=CPSKER.HEX,CPVBRA.HEX
MLOAD K411MAIN.COM=CPSKER.HEX,CPVBRM.HEX

This gave me 2 kermit executables which run as expected.

However, with kermit-95 on the PC set to COM4/9600/8/N/1 I just can't make text files go in either direction, the 2 sides act like the other doesn't exist. I know the main port works so K411MAIN should at least show that it's making an effort. I need to grab the same serial sniffer I used when debugging the Sorcerer, it was a very handy thing to have.

Am I right in thinking that once the comm parameters are set then Kermit should just work out of the box? Time to drag out a machine with a real serial port perhaps...

Cheers!

 

[acollins22]

Hi,

My Superbrain experience is very rusty but I did do some serial transfers back in the day and other than the usual RS-232 issues (it will take 10mins or 10 hours and nothing in between) it all was fine.

I can think of a few places the gremlins could hide...
1) Do you have a way to be sure that the file chucks of Kermit went across OK and have been assembled perfectly? There was the chance for data loss on the transfer.
2) I have had problems with some USB-serial adapters when talking to the real 232 ports on my PDP-11. I suspect they weren't pulling the TX line hard enough in both directions.
3) I seem to remember that you could use PIP to transfer text from the RDR: to a file but that it would write to the disc at the most inconvenient places and drop data.


That's all I can think of at the moment. If anything else occurs to me, I let you know.


Cheers,

Andy.

 

[Witchy]

1) Do you have a way to be sure that the file chucks of Kermit went across OK and have been assembled perfectly? There was the chance for data loss on the transfer.

Only visually, thanks to the format of HEX files I can just type the result to the screen and look for incorrect looking lines, also MLOAD will spot problems too. I'd already tested the main port with PIP FOO=RDR: and sent text down so I knew that if I stayed within the size of the buffer with my chopped-up HEX file I'd be good.

I've just spotted this at the bottom of the Kermit 4.11 build page though:

"Hint: Kermit 4.11 runs on "Generic CP/M systems with IOByte".
It means that Kermit expects to change the lowest two bits (bit 1 and 0) of the IOByte when it wants to use handshake/to signal send/receive readyness. Your BIOS should support this."

I'm running a custom BIOS for hard drive support so I've no idea if it supports IOByte. Maybe I should swap it for a non-specialist one for now.

 

[whartung]

I'm no expert, but wasn't Kermit "specialized" for each platform to run better, but it also has a "generic" CP/M version that uses the stock BIOS, albeit slowly?

Does the Kermit have a way to switch from the specialized mode for your specific hardware and the generic mode?

And, if so, does that work?

As I recall, the generic mode is quite bad, and good only up to 1200 baud.

 

[durgadas311]

...

I've just spotted this at the bottom of the Kermit 4.11 build page though:

"Hint: Kermit 4.11 runs on "Generic CP/M systems with IOByte".
It means that Kermit expects to change the lowest two bits (bit 1 and 0) of the IOByte when it wants to use handshake/to signal send/receive readyness. Your BIOS should support this."

...

This text sounds strange, as IOByte is defined as redirection to a different physical device. The two low bits of the IOByte define the physical device to use for the console, and I'm not certain why kermit would be using that. At least in my experience, CP/M kermit did not support being run in "server mode" and so kermit needed to use some other logical device - not the console - to communicate with the remote system. This was often the punch/reader device, and the user would set the IOByte as appropriate and kermit should leave it alone. The console is used to talk to kermit itself.

The way I always used kermit from a CP/M machine was: start kermit and "connect to the remote" - this would usually result in your keyboard/screen being connected to the remote login or command shell. From there, you'd start kermit on the remote machine - using this connection/shell - and set the remote kermit to server mode. Then, you disconnect back to the CP/M kermit command interface and start your transfers (either send or receive) - the remote kermit, running in server mode, follows the commands issued by CP/M kermit.

Now, I'm not certain how you configure a PC to do this. I was always contacting "big machines" that ran logins and shells on the port, so it just happened. But, basically, you want to run a COMMAND.COM which has it's "console" (input/output) set to the COM port you are using.

 

[Witchy]

The way I always used kermit from a CP/M machine was: start kermit and "connect to the remote" - this would usually result in your keyboard/screen being connected to the remote login or command shell. From there, you'd start kermit on the remote machine - using this connection/shell - and set the remote kermit to server mode. Then, you disconnect back to the CP/M kermit command interface and start your transfers (either send or receive) - the remote kermit, running in server mode, follows the commands issued by CP/M kermit.

Back in the day I used Kermit in this way to talk between VAXen or PDP to VAX or Rainbow to VAX. I'm treating CP/M Kermit the same way but if I haven't got the I/O right then it's not going to work. What's annoying is the RDR: device works fine even at 9600 baud, but 2 Kermits...nope. Maybe I should get a VAX out of the garage and do it the old way :mrgreen:

*edit* I'm even using a VAX cable - a DEC BC22D-25.

 

[JonB]

Hi Witchy

I found that in order to get Kermit working on the Superbrain I needed a few things:

• The Superbrain variant of Kermit. I posted a version that fixed the clear screen bug on a thread here: http://www.vcfed.org/forum/showthread.php?66938-Kermit-on-the-Superbrain
• Strap pin 17 of the 8251 USART chip above the backspace key to GND (/CTS line). This is a cheat that means you don't have to piss about with jumpering the serial port.
• Use an off-the-shelf NULL modem cable, 25 way to 9 way to connect to your FTDI USB adapter.
• You will need to bootstrap Kermit if it's not already on the Superbrain. This means, transfer in small chunks as Intel Hex format using PIP. Painfully slow. Didn't the boot disk I sent you have it?
• It operates on the MAIN port.
• Make sure the baud rate and protocol match in CONFIG.COM (that caught me out a few times). 9600-8-N-1 seems to work OK.
• Check the RS-232 clock option setting switch by the expansion port. It needs to be 1=off, 2=off, 3=on, 4=on, 5=off (where off is with the left hand side of the rocker - the side nearest the expansion port - pressed down). This sets the port to use the internal clock signal for send and receive and disables the output clock on the port.

You should test with PIP at a low speed before trying Kermit after going through the above list:

• Connect the serial line as above to the PC & Superbrain.
• Launch a terminal program on the PC like Teraterm.
• Set the PC serial port config to 1200-8-N-1, and do the same in CONFIG.COM on the Superbrain.
• Issue the command PIP PUN:=[text file] where [text file] is the name of a text file on your boot disk. Probably you have QD31BIOS.ASM on there? If you see nothing coming up on the PC, then the Superbrain is either not sending or there is something up with the serial port.
• Assuming that worked, you need to test the line in the other direction. On the Superbrain, issue the command PIP CON:=RDR: then go to the terminal program and use a send as text option to send a small text file (1K or less). You should see it coming up on the Superbrain screen. Wait until it completes, then (in the terminal window) hit CTRL-Z (this is the CP/M END OF FILE character). On receipt, the Superbrain should return to the CCP prompt ("A:>").

If all that went OK, you are ready to attempt a Kermit transfer. Try at 1200 baud first, then try to increase the speed. I don't think it works above 9600 baud.

Otherwise, you will need to use a 'scope or other measuring tool to see what is on the various RS232 lines during send / receive attempts. Redo the PIP tests, monitoring the TXD / RXD lines.

The Superbrain uses MC1488 and MC1489 level shifters to convert TTL signals to RS232 level signals and back again. These often fail as they are the first point of contact with external equipment. Therefore, I'd suspect these first, before the USART.

----------------------------------

Reviewing what you wrote, I think you are nearly there. I bet it's just waiting for /CTS, so strap the line low and see what happens.

I'm not sure that Superbrain Kermit supports server mode. It is a variant of Kermit-80 v4.11. I use Kermit REC and SEND commands and transfer files one at a time from TeraTerm.

 

[Witchy]

Reviewing what you wrote, I think you are nearly there. I bet it's just waiting for /CTS, so strap the line low and see what happens.

Well f'k my old boots, you're right. CTS strapped low and it works! Seems much faster with Kermit 4.11 than with 4.03 though, so we just need to fix the screen CLS problem and it'll be peachy! Next question is, will ZORK work and will my B: drive hold up long enough to transfer it... let's find out!

 

[Witchy]

OK, after the usual wailing and gnashing of teeth we have a result, and for once it's nothing to do with my FTDI USB adapter. I couldn't for the life of me get files to transfer down that were bigger than 32K (or 16K depending on what BUFFER-SIZE I used). It would just hit that limit then stop. Serial sniffers didn't show anything untoward other than retransmissions from the server side.

Yesterday I built a MyZ80 workflow with the Kermit 4.11 source so I quickly built a version for the AUX port (set braina to TRUE and brainm to FALSE in CPXTYP.ASM), broke the resulting CPSKER.HEX into 3 chunks and sent it down to the 'brain. PIP'd it all back together and created KERM411A.COM by using MLOAD KERM411A.COM=CPSKER.HEX,CPXTYP.HEX.

Added a null-modem cable adapter to my already null modem cable to straighten things out (AUX port is wired as a DTE, main port is DCE), set BUFFER-SIZE to 16 and lo and behold I got ZORK1.DAT (74k) transferred down in one chunk. Woohoo!

So, if anyone else is reading this after going round in circles with Kermit on a 'brain remember to use the AUX port because using the main port WILL make you want to pull your nails out.

 

[alan8086]

OK, after the usual wailing and gnashing of teeth we have a result, and for once it's nothing to do with my FTDI USB adapter. I couldn't for the life of me get files to transfer down that were bigger than 32K (or 16K depending on what BUFFER-SIZE I used). It would just hit that limit then stop. Serial sniffers didn't show anything untoward other than retransmissions from the server side.

Yesterday I built a MyZ80 workflow with the Kermit 4.11 source so I quickly built a version for the AUX port (set braina to TRUE and brainm to FALSE in CPXTYP.ASM), broke the resulting CPSKER.HEX into 3 chunks and sent it down to the 'brain. PIP'd it all back together and created KERM411A.COM by using MLOAD KERM411A.COM=CPSKER.HEX,CPXTYP.HEX.

Added a null-modem cable adapter to my already null modem cable to straighten things out (AUX port is wired as a DTE, main port is DCE), set BUFFER-SIZE to 16 and lo and behold I got ZORK1.DAT (74k) transferred down in one chunk. Woohoo!

So, if anyone else is reading this after going round in circles with Kermit on a 'brain remember to use the AUX port because using the main port WILL make you want to pull your nails out.

View attachment 65377View attachment 65378

Thankyou Jon and Witchy for this thread - I know it will be most useful to me soon!

 

[Witchy]

Another thing to remember that I've just realised. We've been complaining about Kermit 4.11 not clearing the screen when doing a SHOW so this afternoon I looked at the code and compared it to the user manual's control sequences - they're correct. When I was installing WordStar3 though I set it for Superbrain and it too didn't drive the screen properly.

I booted a SBII disk with DOS4 (and had to NORMAL it as ever) and both WordStar and Kermit clear the screen properly so this means the fault lies with the version of DOS both me and JonB are using on our SB1s.

 

[JonB]

Hmm better look into that. I didn't know that SHOW is supposed to clear the screen. But as I said, I already fixed the CLS for the download progress screen. Maybe the SB II has different escape sequences for CLS, or an extra one? I can't see them doing that..

I was able to configure ZORK I II and III to clear the screen on the SB I, though (using the Compustar CS30 BIOS).

 

[Witchy]

Is this the right point to say that the ZORK 1 floppy on Dave Dunfield's site has a routine already on it to drive a Superbrain?

 

[JonB]

Yes. That's how I configured it.

Of course, I can't be bothered to actually play it. Never been good at those sorts of things.

 

[Witchy]

Talking of screen clearing, I've got my SBII QD on the bench after giving its PSU a good recap yesterday (it looks daft now with all the little caps on it) and strangely enough the images that boot to a graphics screen on the SBI boot to inverse-plus-black-on-black on the SBII apart from 'qd_bios4'. Of course there may be a reason for this since it would appear this machine has a BIOS 4 chip in it, but even NORMAL.COM can't rescue the others so there's definitely a different method of screen control going on. Time to grab the SBII manual!

 

[Witchy]

Time to grab the SBII manual!

Hm. Nope, the controls are identical between the 2 machines. Must be a BIOS thing then?

 

[JonB]

Don't confuse the boot ROM with the CP/M BIOS.

The boot ROM does set the screen, but only the bare minimum to enable the prompt to be displayed.

The reverse screen issue is down to the CP/M BIOS on the floppy disk's boot tracks. Use the disk I sent, it should present proper white on black characters on a SB II.

In other unconnected news, I have discovered a bug with the SB II uIDE BIOS. Timeouts occurring while waiting for the IDE device to be ready. It appears to be the screen interrupt service routine; so now the question is, do I issue EI / DI instructions around the uIDE I/O instructions (as I did on the Amstrad PCW) or should I go "proper clever" and incorporate uIDE I/O into the ISR? There's a third option, which would be to connect the uIDE to CPU 2 and get it to handle things, but there's not enough space in the ROM to implement the scheme.

 

[JonB]

Witchy, I am beginning to wonder if we really do have a proper SB II BIOS on these boot disks.

Could you run the following program on your SB II under MBASIC.COM and let me know what result you get, please? I have a sneaky suspicion the result is a blank screen with BASIC OK prompt about 1/3 of the way down; in which case, the BIOS isn't implementing the attribute escape sequences properly. In other words, like a SB I BIOS.

100 CY = 20
110 CX = 5
120 REM Clear screen and then show some of the SuperBrain II video attributes.
130 REM
140 PRINT CHR$(12)
150 REM first line is normal
160 GOSUB 510
170 PRINT "SuperBrain II Video Attribute Demo"
180 REM
190 REM Now turn on inverse video and reprint line.
200 REM
210 CX = 7:GOSUB 510
220 PRINT CHR$(27); " R";
230 PRINT "SuperBrain II Video Attribute Demo"
240 REM
250 REM Now turn on half intensity and reprint line
260 REM
270 REM
280 CX = 9:GOSUB 510
290 PRINT CHR$(27);" H";
300 PRINT "SuperBrain II Video Attribute Demo"
310 REM
320 REM Turn inverse back off and turn underlining on
330 REM
340 CX = 11 :GOSUB 510
350 PRINT CHR$(27); " r"; CHR$(27);" U";
360 PRINT "SuperBrain II Video Attribute Demo"
380 REM
390 REM Turn half intensity off but leave underlining on
420 REM
430 CX = 13:GOSUB 510
450 PRINT CHR$(27);" h";
470 PRINT "SuperBrain II Video Attribute Demo"
471 REM
472 REM Now normalize the video attributes
473 REM
474 PRINT CHR$(27):" N"
480 PRINT
490 PRINT
500 END
510 PRINT CHR$(11)
520 PRINT CHR(27);"Y"; CHR$(CX + 31);CHR$(CY + 31);
530 RETURN

 

[Witchy]

Use the disk I sent, it should present proper white on black characters on a SB II.

It does, nice 50Hz too. It's green on black on this machine thanks to a 'Philips Engineering sample' green tube that smells lovely when its warm. Giving the SBII floppy drives a service to see if it helps them format disks, but drive B has a sticker on it saying 'timeout' and I'm not sure if that points to its current behaviour of not being able to get past the last couple of tracks.

There's a third option, which would be to connect the uIDE to CPU 2 and get it to handle things, but there's not enough space in the ROM to implement the scheme.

Is this a ROM size problem or a 'number of pins preventing use of a larger ROM' problem? It's the perfect task for CPU2 since that's what it does after all.

 

[Witchy]

I have a sneaky suspicion the result is a blank screen with BASIC OK prompt about 1/3 of the way down; in which case, the BIOS isn't implementing the attribute escape sequences properly. In other words, like a SB I BIOS.

Strangely enough I was on the verge of typing that in from the user manual so you've saved me the bother, ta! It's typo city though, all the CHR$(27) lines are wrong including 520 so I've fixed all those and this is what I get:



Interestingly my BIOS chip has '4.2' stamped on it. *edit* ah but it's the BIOS on the floppy you're talking about. Kermit 4.11 that I built the other day DOES drive the screen correctly however.



Strange.

*edit 2* I've noticed the SBRAIN32 disk image boots OK, 64k DOS 3. That doesn't do the screen attrs correctly either...