Second Serial Port

[Tom Lake]

I see that the imsaisim code now includes access to the second serial port. This is good news for us. We may be getting it incorporated into the IMSAI 8080esp soon!

Tom L

[John Kennedy]

That'd be great! I'm a modem project I'd love to hook up to it..

[Udo Munk]

I've added the second SIO for testing options with existing software, there have been various IMSAI boards

with SIO's and the I/O ports overlap. We use the implementation as test for how to implement it in the

machine, so don't use yet, the I/O ports will be moved.

[Tom Lake]

Could you put the port numbers in a config file so we could change them without having to recompile?

Tom L

[Udo Munk]

On Sunday, July 14, 2019 at 7:09:51 PM UTC+2, Tom Lake wrote

:

Could you put the port numbers in a config file so we could change them without having to recompile?

This would add another level of complexity to the machine configuration. Recompiling the emulations also is you least

concern, because you need to rebuild all OS's/applications using a device at some other ports.

[Tom Lake]

No I wouldn't have to rebuild anything. If program X used port Y then I'd change the config file to Y before running X. If Program Q used port Z, I'd change the config file to Z before running Q. If you hard code the port number in the firmware to Y for example, then I could run program X but I will have no way to run program Q. My method lets the user choose which port to use to match a particular program. Yours will only let the user run programs that match your pre-defined choice.

Tom L

[Udo Munk]

On Monday, July 15, 2019 at 4:01:21 PM UTC+2, Tom Lake wrote:

No I wouldn't have to rebuild anything. If program X used port Y then I'd change the config file to Y before running X. If Program Q used port Z, I'd change the config file to Z before running Q. If you hard code the port number in the firmware to Y for example, then I could run program X but I will have no way to run program Q. My method lets the user choose which port to use to match a particular program. Yours will only let the user run programs that match your pre-defined choice.

You don't have programs that use port Z, everything available uses the I/O addresses IMSAI assigned 45 years ago.

So you first have to build software using port Z instead of the default one, let me know when you have build lots of stuff

that requires changes of the I/O mapping all the time...

[Tom Lake]

In your first post you said, "there have been various IMSAI boards with SIO's and the I/O ports overlap."

Doesn't that mean that some software wouldn't work with some configurations? 

Tom L

[Udo Munk]

On Monday, July 15, 2019 at 5:13:37 PM UTC+2, Tom Lake wrote:

In your first post you said, "there have been various IMSAI boards with SIO's and the I/O ports overlap."

Doesn't that mean that some software wouldn't work with some configurations? 

Tom L

No, all IMSAI software we have use SIO ports 2/3 and 4/5 for the consoles. In the later MPIO card these

ports also are used but also duplicated again at 18/19 ... So I put the additional SIO at 18/19 to see

if anything uses it, but not so, and these I/O ports collide with the Cyclops controller default addresses.

We'll move the additional SIO to ports not in use, then it can be added to BIOS's for the PUN and RDR

devices, which currently are NULL devices.

[Tom Lake]

Ah, that explains it. Thanks!

Tom L

[Udo Munk]

The second serial port now is implemented in z80pack 1.37-dev available at GitHub:

https://github.com/udo-munk/z80pack/tree/dev

This SIO is channel A on a second SIO2 card configured for IO ports 20H - 2FH.

So the relevant ports are:

AUX     EQU     22H             ;AUX DATA PORT

AUXS    EQU     23H             ;AUX STATUS PORT

AUXC    EQU     28H             ;CONTROL PORT FOR SIO BOARD

The port is added to the CP/M 2.2 BIOS with full IOBYTE support, initial

assign now is:

A>stat dev:

CON: is TTY:

RDR: is PTR:

PUN: is PTP:

LST: is LPT:

With stat con:=uc1: one can switch the console to the second serial port.

Also batch mode is supported, with stat con:=bat: input is from second serial

and output is to line printer.

On the PC emulation you can connect with minicom to the second serial port with:

minicom -D unix#/tmp/.z80pack/imsaisim.sio2

For a first test then try pip pun:=boot.hex or something like this.

[John Kennedy]

Well. You know the next question, right?

[Tom Lake]

My next question would be: When will we be able to use it on the IMSAI 8080esp?

Your question might be different.

Tom L

[John Kennedy]

Yes, that’s the question :)

[Tom Lake]

Oops! Sorry I spoiled your surprise. :)

[TheHighNibble]

Good news! Thanks to the 

• work done by Udo in Z80PACK, especially making a new BIOS for the imsaisim machine 
• availability of a new (dev) release of the esp-idf that addresses some UART timing issues

I have a working implementation of:

• the second physical serial port (RS232-2) working as an alternate console as UC1: under CP/M
• physical serial port (both RS232-1 & RS232-2) configuration via boot.conf
• tested a range of speeds from 110 to 115200 baud (higher or lower speeds don't appear to work)
• 7 and 8 bit data words (CS7, CS8)
• no parity, even parity and odd parity (-, PARENB, PARENB & PARODD)
• 1 and 2 stop bits (-, CSTOPB)

Because of the need to 

• test more generally against the new release of the esp-idf 
• write some documentation and 
• provide a tutorial on flashing new firmware

It will be about a week before I will release the new firmware.

[John Kennedy]

Sweet! You can’t have too many serial ports!

(And by “you” I mean “Tom”)

Looking forward to playing with it!

[Tom Lake]

Sweet! You can’t have too many serial ports!

(And by “you” I mean “Tom”)

You hit your head right on the nail! (or something like that)

Tom L

(often imitated - never duplicated) 

[AB]

Youa re 100% -  one can never have too many serial ports!

Next question for Tom -  -  is Timesharing Basic something we can achieve on IMSAI????  

 

[Tom Lake]

I just got started with the IMSAI recently so I'm not too familiar with it yet. It would need a vectored interrupt capability to service the users.

Also, on the IMSAI 8080esp, there are only two serial ports so you'd only be able to have two users at a time.

Tom L

[TheHighNibble]

OK, the new firmware is released. Unfortunately I haven't had time to update the docs or publish a video on performing firmware updates yet.

So in summary, for the impatient or adventurous:

• Follow the GitHub link in the upper-right-hand corner on https://thehighnibble.com/
• Click through to releases and then the September 2019 release
• Download both FIRMWARE.zip and IMAGE.zip and unzip them
• You only need one file from each zip archive
• IMAGE.zip - you need only imsai/disks/cpm22.dsk
• This is a new copy of the CP/M 2.2 system disk from Z80PACK with a new BIOS that maps CP/M physical devices UC1:, PTR: & PTP: to UART1 
• Copy this to your disk library LIB: then mount it in DSK:A:
• FIRMWARE.zip - you need only imsaisim_esp32.bin
• This is the firmware binary to be flashed to the ESP32
• Drag-and-drop this over the SYS: device icon on the DesktopUI to flash to the ESP32.
• Confirm the first dialog, and wait (10-15 seconds ?) until you see the second dialog confirming the upload was successful
• Reboot the ESP32
• You can now configure the parameters for both UART0 (RS232-1) and UART1 (RS232-2) via the boot.conf file, for example

#UART configuration

UART0=115200,cs8 # ie. 115200, 8N1 - not required because this is default

UART1=9600 cs7 cstopb parenb parodd # ie. 9600, 7O2

• parameters can be separated by spaces or commas
• parameters are case insensitive
• parameters follow the convention used by the screen program under unix/linux/gnu ie.:
• default is 115200,cs8 in other words 115200 8N1
• standard baud rates from 110 to 115200 e.g. 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200
• other may work, but you'll have to experiment
• cs7 - for 7 data bits
• cs8 - for 8 data bits
• cstopb - for 2 stop bits, default is 1
• parenb - for even parity, default is none 
• parenb,parodd - for odd parity
• UART1 can only be used via RS232-2
• you need to jumper the following pins
• Comms:
• Tx2 .-. (horizontal)
• Rx2 .-. (horizontal)
• Patch: 
• R2 - IO5 (vertical)
• T2 - IO22 (vertical)

Once you are flashed, rebooted, jumpered, configured and then mounted and booted the new cpm22.dsk disk image

you can try:

A> stat con:=uc1:

and the CP/M console should now be directed to the serial terminal connected to RS232-2

Easy, isn't it.

[Colin Little]

Many thanks for this, it all works & according to plan and I can switch between the 2 serial ports with STAT CON: (UART1 on external terminal) UART0 on the console -  but here's a strange thing - on the CONSOLE display if I click on SYS: it's now a blank screen. So I configured the boot.conf  file offline in my SD Card reader and clearly all working ..... any ideas?

[Colin Little]

BTW Clicking the GEAR wheel on the SYS: brings up correctly the system & boot.conf files

[Tom Lake]

OK, just to be sure: Should About in SYS: show that the new firmware was loaded? Mine now reads:

About

ESP32 IMSAI 8080 Simulation
1.18-dev (ESP32)

Copyright (C) 2008-2019 by Udo Munk & David McNaughton
CPU: Z80 running at 4MHz
Boot ROM: /sdcard/imsai/mpu-a-rom.hex
CP-A attached [2392]

Build Version v1.2.1

Host System

ESP-IDF Version: v4.1-dev-59-gfecfdb909

Free Memory: 35K

:

:

Does this indicate a successful load?

Tom L

On Monday, September 2, 2019 at 6:29:43 AM UTC-4, TheHighNibble wrote:

OK, the new firmware is released. Unfortunately I haven't had time to update the docs or publish a video on performing firmware updates yet.

 

Easy, isn't it.

[Udo Munk]

On Sunday, August 25, 2019 at 6:15:39 PM UTC+2, AB wrote:

Next question for Tom -  -  is Timesharing Basic something we can achieve on IMSAI????  

IMSAI never provided a Timeharing BASIC and the one from MITS won't run on the clone machine.

MITS BASIC requires SIO, PIC and FDC cards from MITS, but the machine is filled with cards from

IMSAI and Cromemco.

[Udo Munk]

On Monday, September 2, 2019 at 12:29:43 PM UTC+2, TheHighNibble wrote:

Once you are flashed, rebooted, jumpered, configured and then mounted and booted the new cpm22.dsk disk image

you can try:

A> stat con:=uc1:

and the CP/M console should now be directed to the serial terminal connected to RS232-2

Excellent. With this BIOS generic CP/M-80 Kermit should work with the second serial port too. I have build

the generic Kermit version already, but had no time to test this, so it's not included on any disk image yet.

If anyone wants to test this let me know and I'll provide a disk image.

[John Kennedy]

I’d love to try Kermit.

[John Kennedy]

>but here's a strange thing - on the CONSOLE display if I click on SYS: it's now a blank screen

Yup, same for me. Reboot, power off, etc. No difference.

[Colin Little]

If I try to re-flash the ESP-32 again it doesn't come back with the 2nd dialogue either.. However, apart from that everything else is working on both ports, 

[John Kennedy]

Although the CFG: window is empty for me, the gear that brings up the config files still works.

I was able to select boot.conf and add:

#UART configuration

UART0=9600,cs8 

UART1=9600,cs8

Now when I enter 

PIP UC1:=DUMP.ASM

it displays content on my external monitor at 9600 as expected. Success! :-)

With a working Kermit, I can continue my experiments with DIY modems etc.

Two things:

1. Could someone remind me what CP/M device the first serial port works with? 

2. The 'vio_scanlines' setting in system.conf is ignored for me.

[TheHighNibble]

OK, just to be sure: Should About in SYS: show that the new firmware was loaded? Mine now reads:

Build Version v1.2.1

 

Yes, right there:

that's the version you just downloaded from GitHub. 

[TheHighNibble]

but here's a strange thing - on the CONSOLE display if I click on SYS: it's now a blank screen. 

Strange that Tom and I can both still see the info in the SYS: window. Anyone else not have this problem after the update?

If anyone that is getting an empty SYS: window after the firmware update would care to do the following, I will debug the problem. 

• In the browser, navigate to http://imsai8080.local/system or http://192.168.x.x/system (whatever...)
• Cut and past the XML returned into an email to me
• DON'T post or attach it hear it contains your SSID and Pass word for your Wi-Fi

[TheHighNibble]

OK, thanks to the folks that sent me the required debug data I've identified the problem.

The JSON (not XLM, my mistake) returned by .../system now includes some extra details that are not yet displayed in the SYS: window.

One of these is the country returned by your Wi-Fi access point. In the two cases I saw, this field contains extra characters (non-printable control characters or formatting like \n etc...) that makes the JSON invalid.

This explains the variability, my router returns "CH" and nothing else.

I'll make a new firmware that trims this field down to printable characters before sending it out in the JSON.

You could further test this theory by putting your IMSAI 8080esp into AP mode and checking that the SYS: window now displays correctly.

[Tom Lake]

Wow, you are fast! Good work! I'm not sure what my router returns but I'll bet it's a simple, printable string. How would I display it?

Tom L

[TheHighNibble]

Tom,

navigate to http://imsai8080.local/system or http://192.168.x.x/system (whatever...)

follow the directions and look at the "country" field in the JSON output.

[Udo Munk]

On Monday, September 2, 2019 at 5:19:04 PM UTC+2, John Kennedy wrote:

I’d love to try Kermit.

Disk image is available here: https://www.autometer.de/unix4fun/z80pack/ftp/

File genkermit.tgz

[John Kennedy]

Thanks Udo (and Mr Nibble).  Looks like it's working :-)

[Udo Munk]

On Monday, September 2, 2019 at 7:58:07 PM UTC+2, John Kennedy wrote:

Thanks Udo (and Mr Nibble).  Looks like it's working :-)

Very well, thanks for testing and reporting back.

[John Kennedy]

Haha, my Telnet adaptor is mostly working! I can use Telnet over the internet to connect to the IMSAI now!

It's an ESP32 based thingy connected to the new Serial port. Here is me using Telnet on a Mac to connect to it:

[Tony Nicholson]

The v1.2.1 update was surprisingly "easy-peasy".  Thanks Dave and Udo.

I'm now using the second serial port via a terminal server to get and put files via Kermit from SIMH instances of OpenVMS and my PiDP11 running RSTS/E.  Now I'm beginning to contemplate the need for some hard-disk emulation.  241KB floppy images don't hold much do they?? :)

Tony

[TheHighNibble]

Thanks for the feedback, great.

Tonight there will be a v1.2.2 bump release that solves the blank SYS: window for the people getting that problem.

Yeah harddisk is on the wish list, damn right. I want my WordStar 4.

[Udo Munk]

I have put an 'official' disk image with kermit and xmodem into the GitHub repo:

https://github.com/udo-munk/z80pack/tree/dev/imsaisim/disks/library

If you need the manual for CP/M kermit you'll find the matching one here:

https://www.autometer.de/unix4fun/z80pack/ftp/manuals/Software/

For xmodem no manual is required, just type xmodem without arguments

for quick help. Also the configuration file is very well commented and

the source file is included on the disk too.

For hard disk emulation I'll create a new thread, that will make it easier later

for others searching for informations.

[John Kennedy]

Thanks Udo!

[John Kennedy]

Timezones are confusing. When you say "tonight"...?

[TheHighNibble]

Yes, sorry, missed that deadline. Working on it now. Will update soon.

[TheHighNibble]

Thanks, that's great. I'll add this comms.dsk disk image to the patch release.

I have had success with kermit, both with get and send of files from/to a host/server.

With CP/M xmodem I have been able to /R(eceive) files from (lrzsz) sx on an OSX host, 

but everything I try to /S(end) from CP/M xmodem results in checksum or CRC errors (both modes) on (lrzsz) rx on the OSX host!

Any suggestions from your experience? Its been so long since I last used xmodem.

[TheHighNibble]

OK The patched firmware v1.2.2 is now on giHub and:

- fixes the issue with the SYS: device not rendering for some people

- adds the comms.dsk disk image that Udo released, containing xmodem.com and kermit.com

Guess I'd better get on with updating the config guide and putting up a video on flashing a new firmware.

[Tom Lake]

I didn't have a problem after 1.21 but NOW I have a problem after flashing 1.22.

The four disk drive icons show EMPTY when I point at them and they have the red slashed circle on them. However, I can boot CP/M 2.2 and do a DIR of all four disks!

I can't eject any of them or load any other disks.

Tom L

[Tom Lake]

I don't know what happened but after closing and reopening Chrome a couple times everything shows normal now with the proper disk icons even though I tried refreshing several times before.

Tom L

[TheHighNibble]

Chrome caching, drives me crazy. No pun intended.

[Udo Munk]

On Saturday, September 7, 2019 at 7:40:36 AM UTC+2, TheHighNibble wrote:

Thanks, that's great. I'll add this comms.dsk disk image to the patch release.

I have had success with kermit, both with get and send of files from/to a host/server.

With CP/M xmodem I have been able to /R(eceive) files from (lrzsz) sx on an OSX host, 

but everything I try to /S(end) from CP/M xmodem results in checksum or CRC errors (both modes) on (lrzsz) rx on the OSX host!

Any suggestions from your experience? Its been so long since I last used xmodem.

Just tested again with the PC emulation, currently I don't have any RS232 equipment to use with the replica.

Need to get cables, gender changer, patch boxes, terminal server ... sometime again, all gone long ago.

With the PC emulation it works OK, doesn't matter if you start sender or receiver first, there is nothing one

could do wrong as far as I can tell. 

A>b:xmodem bios.asm /s

File open

Sending via RDR/PUN with checksums

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

OK

Sent 177 blocks

[John Kennedy]

Lovely :-)

[Tony Nicholson]

On Saturday, September 7, 2019 at 3:40:36 PM UTC+10, TheHighNibble wrote:

[snip]

With CP/M xmodem I have been able to /R(eceive) files from (lrzsz) sx on an OSX host, 

but everything I try to /S(end) from CP/M xmodem results in checksum or CRC errors (both modes) on (lrzsz) rx on the OSX host!

Any suggestions from your experience? Its been so long since I last used xmodem.

I can't get XMODEM to /S(end) either.  Receiving is OK.

I tried using minicomm on a Raspberry Pi via the console - "XMODEM file.ext/X0/S/C" and

to my VAXMODEM program on OpenVMS, and TeraTerm VT on Windows 10.

When I first started using the console to boot-strap XMODEM via an ASCII Intel HEX upload

into CP/M PIP - I changed the IMSAI8080esp system.conf file settings for SIO-1 to not strip

parity and nulls -

# SIO 1, Ports 2/3 connected to terminal
sio1_upper_case        0
sio1_strip_parity    0
sio1_drop_nulls        0

Does there need to be similar settings for the second serial port?  I see the comments in

system.conf refer SIO-2 as the VIO keyboard and not the Auxiliary port that's used by the

BIOS for the AUX device (IMSAI I/O port 22h/23h).

Kermit works though (as expected) since it only passes printable ASCII.  I've used GET

and PUT with both c-kermit and the old BLISS Kermit-32 on OpenVMS - both running in

SERVER mode.

Tony

[TheHighNibble]

Yes, the system.conf comments are now out of date.

You can uncomment/add the lines:

sio2_upper_case 0

sio2_strip_parity 0

sio2_drop_nulls 0

As they do act on the new SIO port and not the VIO keyboard.

However, I still have had no luck.

I also experience that if I set the UART1 baud rate higher than 19200, I can successfully use UC1: as the console, but Kermit file transfers begin to experience high error rates and frequently fail!

Let me know how you get on.

[TheHighNibble]

OK, I've identified the problem. Subtleties of the esp-idf: I didn't realise that it was modifying line endings. 

The default behaviour of the library is to convert CRLF to LF.

You'd think the default would be "do nothing".

So anywhere there is a consecutive CRLF, the CR is getting dropped on the way to the UART.

Just fiddling around with the best solution and then will release another patch to the firmware.

[TheHighNibble]

Very happy with the result with this. I've coded the UART1/RS232-2/2nd SIO "native" (esp-idf uart api), avoiding the standard C-library IO routines (newlib & vfs).

Both xmodem and kermit are sending and receiving successfully at speeds from 300 to 230400 baud.

As indictaed earlier: you do need to also edit system.conf and uncomment/add the lines:

sio2_upper_case 0

sio2_strip_parity 0

sio2_drop_nulls 0

I'll post a v1.2.3 release with this change shortly. Once I get some confirmation from a few people that can test and get similar results we'll call it GA.

[TheHighNibble]

The v1.2.3 release is now available on GitHub

[Udo Munk]

In the latest z80pack version on GitHub the configuration and comments

are corrected and are:

# SIO 1, Ports 2/3 connected to terminal

sio1_upper_case         0

sio1_strip_parity       1

sio1_drop_nulls         1

sio1_baud_rate          9600

# typical baud rate values are 110, 300, 1200, 2400, 4800, 9600,

# 19200, 38400, 57600, 115200 - 0 = unlimited baud rate

# SIO 2, Ports 34/35 connected to UNIX socket

# use 8bit here, so that serial file transfers work

sio2_upper_case         0

sio2_strip_parity       0

sio2_drop_nulls         0

sio2_baud_rate          0

# typical baud rate values are 110, 300, 1200, 2400, 4800, 9600,

# 19200, 38400, 57600, 115200 - 0 = unlimited baud rate

[Colin Little]

Great! now successfully works on SEND (I too have minicom on Raspberry Pi @ 9600)

[Tony Nicholson]

On Sunday, September 8, 2019 at 5:28:57 PM UTC+10, TheHighNibble wrote:

The v1.2.3 release is now available on GitHub 

[snip]

Thanks for looking into this Dave.

I had come to the conclusion that the serial port was not 8-bit clean and was about

to wire up a "RS232 T-piece" so that I could sniff at the data flows.

I can confirm that the second serial port with the v1.2.3 release now works with

XMODEM for both /S(end) and /R(eceive).   However, I cannot get the console

port to work for XMODEM /S(end).  It does work to /R(eceive) a file.

I'm using the console in USB-serial mode (not via the RS232-1 connector) with

UART0=115200,cs8 and using the /X0 switch on XMODEM.  Also I've noticed

whenever I open the web page at imsai8080.local then the console port is siezed

by the web-interface TTY: and has to be force disconnected.  Perhaps the first serial

port uart api routines are swallowing characters too?

Tony

[Udo Munk]

On Sunday, September 8, 2019 at 12:14:43 PM UTC+2, Tony Nicholson wrote:

I can confirm that the second serial port with the v1.2.3 release now works with

XMODEM for both /S(end) and /R(eceive).   However, I cannot get the console

port to work for XMODEM /S(end).  It does work to /R(eceive) a file.

The console port is not 8bit clean, in the default configuration it strips parity and drops

0 bytes:

# SIO 1, Ports 2/3 connected to terminal

sio1_upper_case         0

sio1_strip_parity       1

sio1_drop_nulls         1 

Edit and change the values to 0, then it also is 8bit clean. The BIOS is 8bit clean for all

serial ports, I thought it might be better to move such stuff into the SIO configuration,

because it is not necessary then to change the BIOS and rebuild the OS's.

[TheHighNibble]

Tony,
I think you are right about UART0/RS232-1/TTY:
I didn’t want to change the code paths effecting this device without more time to test.

It’s not as straight forward as UART1 that is initialised by my code and totally under my control.
UART0 is initialised by the bootloader, shared by the ESP32 console for logging, has stdin/stout/stderr mapped to it. There are some api calls I can test that should fix the line ending handling on this too, but I want to have time to test and make sure I don’t stuff up the console &/or the TTY: over UART0 device.

Another point you make is worth revisiting. The way the TTY: window auto connects when the desktop UI loads. When this happens it steals the connection from UART0. Maybe I should check if VIO is enabled (BIOS loaded) and not auto connect in this case. I’ll think about it, but if you have other suggestions let me know.

[Tony Nicholson]

On Sunday, September 8, 2019 at 8:37:31 PM UTC+10, TheHighNibble wrote:

Tony,
I think you are right about UART0/RS232-1/TTY:
I didn’t want to change the code paths effecting this device without more time to test.

It’s not as straight forward as UART1 that is initialised by my code and totally under my control.
UART0 is initialised by the bootloader, shared by the ESP32 console for logging, has stdin/stout/stderr mapped to it. There are some api calls I can test that should fix the line ending handling on this too, but I want to have time to test and make sure I don’t stuff up the console &/or the TTY: over UART0 device.

I understand the complications - so fixing this probably is not that urgent (especially

now we have a working second serial port).

 

Another point you make is worth revisiting. The way the TTY: window auto connects when the desktop UI loads. When this happens it steals the connection from UART0. Maybe I should check if VIO is enabled (BIOS loaded) and not auto connect in this case. I’ll think about it, but if you have other suggestions let me know.

On my S-100 system I have the console device set to multiple devices (it runs

CP/M-Plus and the DEVICE command lets you use multiple devices at a time

e.g. 'DEVICE CON:=VIDEO,SIO1[9600,XON]').

This causes console output to go to multiple ports and console input is read

from the first device with an available character.  Maybe the web UI could do this

too for the TTY: device (i.e. send output to both the first serial port/console and

the web UI and for console input return whichever device has a character available).

[John Kennedy]

IMSAI8080esp updates are like busses.. you wait for a month and three come at once! :-). (Only kidding, very happy to see the continued support).

If you can recognize where these screenshots are from, you'll know that I must have gotten the second serial port connected to my fModem hack properly - it lets me connect over Telnet to internet sites (for example, a BBS or this one - towel.blinkenlights.nl).

One thing is clear - Kermit works, but it's not a proper terminal with VT52/100 emulation. Has anyone gotten a CP/M based terminal (QTerm, Bye etc) working on the IMSAI and can point me to a .dsk? That's the missing piece in getting "online" properly.

-John

On Saturday, July 13, 2019 at 7:49:55 PM UTC-7, Tom Lake wrote:

I see that the imsaisim code now includes access to the second serial port. This is good news for us. We may be getting it incorporated into the IMSAI 8080esp soon!

Tom L

[Tony Nicholson]

On Monday, September 9, 2019 at 8:05:31 AM UTC+10, John Kennedy wrote:

[snip]

One thing is clear - Kermit works, but it's not a proper terminal with VT52/100 emulation. Has anyone gotten a CP/M based terminal (QTerm, Bye etc) working on the IMSAI and can point me to a .dsk? That's the missing piece in getting "online" properly.

One of the cursed features of CP/M was the plethora of different flavours of

terminals - for example see any Wordstar installation and the variety of choices

for the console device.  I think the Web UI does a cut-down VT100 style ANSI

emulation (so when you use Kermit it should behave correctly if the system

you connect to knows this).

In my old 1980's vintage S-100 bus machine I have an enhanced Fulcrum

VIO-X2 video card and I wrote various CP/M-Plus RSX modules to get the

console to convert from ANSI to its ADM31 emulation.  Other approaches

used were to modify the comms program to bypass the BIOS character

I/O routines and hardcode specific routines to access the physical UART

devices and do emulation.  Somewhere I have a copy of YAM (Yet Another

Modem program) that was written in BDS-C with similar modifications, as

was an attempt written in TurboPascal.

This was "all part of the fun" of early hobbyist computing!

[Udo Munk]

On Monday, September 9, 2019 at 12:05:31 AM UTC+2, John Kennedy wrote:

One thing is clear - Kermit works, but it's not a proper terminal with VT52/100 emulation. Has anyone gotten a CP/M based terminal (QTerm, Bye etc) working on the IMSAI and can point me to a .dsk? That's the missing piece in getting "online" properly.

You are running this from the VIO CRT, this is a LSI compatible terminal, not a DEC compatible terminal.

Try switching the console to the TTY, this emulates a DEC VT-100. 

[John Kennedy]

Huh, in my mind it was exactly the other way round. The TTY view is perfect! Movie night!

[Udo Munk]

On Monday, September 9, 2019 at 7:35:16 AM UTC+2, John Kennedy wrote:

Huh, in my mind it was exactly the other way round. The TTY view is perfect! Movie night!

Excellent. Also watch which Wordmaster editor you are using on which terminal.

wm-ansi works with the TTY terminal and wm-lsi with the VIO CRT.

@ Dave: maybe display the terminal emulation in the title bar of the terminal windows? The

VIO firmware emulates a LSI ADM3A.

[Udo Munk]

On Monday, September 9, 2019 at 1:43:51 AM UTC+2, Tony Nicholson wrote:

One of the cursed features of CP/M was the plethora of different flavours of

terminals - for example see any Wordstar installation and the variety of choices

for the console device.

Not a CP/M feature, all systems from that time had to deal with this. Just look

at termcap or tirminfo terminal definititions on any UNIX system, there are

hundreds of terminals defined.

DRI didn't provide something similar, so everyonw wrote their own terminal

configuration for every application that had to deal with diffrent terminals.

Way back then we ported termcap and a termcap based curses to CP/M,

but this was quite large and not really helpfull. A better option was using

the qterm overlay for adapting programs for diffrent terminals.

[Mark Lawler]

Working to try out my 9pin RS-232 ports.  I was trying to follow these instructions, but received an error after issuing the "stat con:=uc1:" cp/m command.  Are these steps still valid or should I be looking at a different thread?  Thanks!  Here is the error received:

A>stat con:=uc1:

Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core 1 register dump:

PC      : 0x4009605a  PS      : 0x00060333  A0      : 0x8008e1a2  A1      : 0x3ffe5010

A2      : 0x0d524f52  A3      : 0x00060320  A4      : 0x00000001  A5      : 0x0000abab

A6      : 0xb33fffff  A7      : 0x00000000  A8      : 0x0000cdcd  A9      : 0x00000001

A10     : 0x0000abab  A11     : 0x00000000  A12     : 0x3f4037a6  A13     : 0x3f403482

A14     : 0x3ffe5198  A15     : 0x3ffe5190  SAR     : 0x0000001e  EXCCAUSE: 0x0000001d

EXCVADDR: 0x0d524f52  LBEG    : 0x400f16fe  LEND    : 0x400f1706  LCOUNT  : 0x00000000

ELF file SHA256: df34191b148a588f866558fc0f0b4b277a2457a47881fc5251dd80e6ca437c2a

Backtrace: 0x40096057:0x3ffe5010 0x4008e19f:0x3ffe5040 0x4008e1d4:0x3ffe5060 0x40083efe:0x3ffe5090 0x40083f2c:0x3ffe50c0 0x40094d7a:0x3ffe50e0 0x40094d98:0x3ffe5100 0x400f1309:0x3ffe5120 0x400f172b:0x3ffe5180 0x401673f9:0x3ff

Best,

-Mark

On Monday, September 2, 2019 at 3:29:43 AM UTC-7 TheHighNibble wrote:

OK, the new firmware is released. Unfortunately I haven't had time to update the docs or publish a video on performing firmware updates yet.

So in summary, for the impatient or adventurous:

• Follow the GitHub link in the upper-right-hand corner on https://thehighnibble.com/
• Click through to releases and then the September 2019 release
• Download both FIRMWARE.zip and IMAGE.zip and unzip them
• You only need one file from each zip archive
• IMAGE.zip - you need only imsai/disks/cpm22.dsk
• This is a new copy of the CP/M 2.2 system disk from Z80PACK with a new BIOS that maps CP/M physical devices UC1:, PTR: & PTP: to UART1 
• Copy this to your disk library LIB: then mount it in DSK:A:
• FIRMWARE.zip - you need only imsaisim_esp32.bin
• This is the firmware binary to be flashed to the ESP32
• Drag-and-drop this over the SYS: device icon on the DesktopUI to flash to the ESP32.
• Confirm the first dialog, and wait (10-15 seconds ?) until you see the second dialog confirming the upload was successful
• Reboot the ESP32
• You can now configure the parameters for both UART0 (RS232-1) and UART1 (RS232-2) via the boot.conf file, for example

#UART configuration

UART0=115200,cs8 # ie. 115200, 8N1 - not required because this is default

UART1=9600 cs7 cstopb parenb parodd # ie. 9600, 7O2

• parameters can be separated by spaces or commas
• parameters are case insensitive
• parameters follow the convention used by the screen program under unix/linux/gnu ie.:
• default is 115200,cs8 in other words 115200 8N1
• standard baud rates from 110 to 115200 e.g. 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200
• other may work, but you'll have to experiment
• cs7 - for 7 data bits
• cs8 - for 8 data bits
• cstopb - for 2 stop bits, default is 1
• parenb - for even parity, default is none 
• parenb,parodd - for odd parity
• UART1 can only be used via RS232-2
• you need to jumper the following pins
• Comms:
• Tx2 .-. (horizontal)
• Rx2 .-. (horizontal)
• Patch: 
• R2 - IO5 (vertical)
• T2 - IO22 (vertical)

Once you are flashed, rebooted, jumpered, configured and then mounted and booted the new cpm22.dsk disk image

you can try:

A> stat con:=uc1:

and the CP/M console should now be directed to the serial terminal connected to RS232-2

Easy, isn't it.

On Saturday, 24 August 2019 21:06:10 UTC+10, TheHighNibble wrote:

Good news! Thanks to the 

• work done by Udo in Z80PACK, especially making a new BIOS for the imsaisim machine 
• availability of a new (dev) release of the esp-idf that addresses some UART timing issues

I have a working implementation of:

• the second physical serial port (RS232-2) working as an alternate console as UC1: under CP/M
• physical serial port (both RS232-1 & RS232-2) configuration via boot.conf
• tested a range of speeds from 110 to 115200 baud (higher or lower speeds don't appear to work)
• 7 and 8 bit data words (CS7, CS8)
• no parity, even parity and odd parity (-, PARENB, PARENB & PARODD)
• 1 and 2 stop bits (-, CSTOPB)

Because of the need to 

• test more generally against the new release of the esp-idf 
• write some documentation and 
• provide a tutorial on flashing new firmware

It will be about a week before I will release the new firmware.

[udo....@freenet.de]

The firmware crashed and that should not happen. Which version of the firmware are you using, if it's not the latest

available one you should update to that. Besides adding features also some bugs were located and fixed.

The latest version is here:

https://github.com/thehighnibble/firmware/releases

[Mark Lawler]

Thanks.  Wow, I am on an older one...  Startup screen shows release 1.37-dev (it came with the IMSAI 8080 kit I built last month).  I'll do the upgrade.  Thanks!

[Mark Lawler]

Oh, I take that back.  I was reading a build # from the initial startup screen.  In the IMSAI 8080 desktop SYS: screen it says I'm running build Version v1.6.1 with webfrontend-v1.6.0.

[Mark Lawler]

I reflashed to the latest release anyways, following the instructions, and rebooted.  Issuing the cp/m command "stat con:=uc1:" still results in the following crash:

>Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core 1 register dump:

PC      : 0x4009605a  PS      : 0x00060333  A0      : 0x8008e1a2  A1      : 0x3ffe5010

A2      : 0x0a0d524f  A3      : 0x00060320  A4      : 0x00000001  A5      : 0x0000abab

A6      : 0xb33fffff  A7      : 0x00000000  A8      : 0x0000cdcd  A9      : 0x00000001

A10     : 0x0000abab  A11     : 0x00000000  A12     : 0x3f4037a6  A13     : 0x3f403482

A14     : 0x3ffe5198  A15     : 0x3ffe5190  SAR     : 0x00000011  EXCCAUSE: 0x0000001d

EXCVADDR: 0x0a0d524f  LBEG    : 0x400f16fe  LEND    : 0x400f1706  LCOUNT  : 0x00000000

ELF file SHA256: df34191b148a588f866558fc0f0b4b277a2457a47881fc5251dd80e6ca437c2a

Backtrace: 0x40096057:0x3ffe5010 0x4008e19f:0x3ffe5040 0x4008e1d4:0x3ffe5060 0x40083efe:0x3ffe5090 0x40083f2c:0x3ffe50c0 0x40094d7a:0x3ffe50e0 0x40094d98:0x3ffe5100 0x400f1309:0x3ffe5120 0x400f172b:0x3ffe5180 0x401673f9:0x3f

Best,

-Mark

[udo....@freenet.de]

OK, no idea then and so far we don't have reports like this with 1.6.1. Guess Dave will have to look at the symbol table and sources, where and why it panics.

[TheHighNibble]

Hi Mark, I'll get on to it. Might take a couple of days as its a busy week at my day job.

[TheHighNibble]

Mark,

it looks like you've already found the solution to this (reading your post in the a thread).

The solution is given in this thread/post https://groups.google.com/g/imsai8080esp/c/JLpksS0cGiA/m/c2P6Q5ZpAwAJ

Under CP/M 2.2 there aren't enough device names for everything. So UC1: defaults to the virtual 'AT' modem.

• The two scripts porta.sub and portb.sub on cpm22b01.dsk patch the (in memory) BIOS for UC1: to map to port A and port B respectively.
• But the default, starting condition, is for UC1: to map to port B
• Where portA is the second UART on the IMSAI8080esp (UART1 or RS232-2)
• and portB is the virtual 'AT' Modem
• see: https://thehighnibble.com/imsai8080/configure/#serial-communications-rs232-usb

Maybe Udo could give a suggestion how to make this mapping permanent so that becomes to new default after a reboot.

[udo....@freenet.de]

By default the BIOS addresses the modem ports, because I assumed that everyone would like to try

modem connections with the machine first. But in the BIOS routines using the second serial port

instead as the default already is prepared. Let's have a look at the sources, B02 in this case. You

might still run B01, which is functional identical, I just renamed the symbols used for the various

ports, so that it is better understandable. For example:

;

;       CONSOLE STATUS, RETURN 0FFH IF CHARACTER READY, 00H IF NOT

;

CONST:  CALL    DISPATCH        ;GO TO ONE OF THE PHYSICAL DEVICE ROUTINES

        DB      1               ;USE BITS 1-0 OF IOBYTE

        DW      TTY1IS          ;00 - TTY:

        DW      CRTIST          ;01 - CRT:

        DW      TTY2IS          ;10 - BAT:

;       DW      TTY2IS          ;11 - UC1:

        DW      MODIST          ;11 - UC1:

You could comment the line with MODIST und uncomment the one before with TTY2IS, similar in routines

CONIN, CONOUT. Then generate a new systems with the modified BIOS and it will use the second serial by

default.