WooHoo! A new software release (v1.4.0) and its a big one!

[TheHighNibble]

October 2019 Release

is now available on GitHub.

Thanks to the following members for all their contributions and help with testing: Udo Munk, John Kennedy, Terry Fox.

Lots of new features including a virtual 'AT' (Hayes) modem over TCP/IP (telnet) and the first update to the desktop GUI.

Check the release notes (carefully). The update is done in 2 steps:

1. Drag-and-drop the firmware update (same as perviously)
2. Drag-and-drop the desktop GUI update (new update.bin file) the same way as for the firmware update.

You will also want to get the latest CP/M 2.2 BIOS (B01) system disk (cpm22b01.dsk) to have a bios that enables all the latest features.

Now the adventure begins while you play with the new features and I procrastinate about updating the web site / config guide that will explain how everything works.

[Tom Lake]

Congrats! Now may I suggest you put off procrastinating? :)

Tom L

[Udo Munk]

Updated firmware, went smooth as expected.

Uploaded update.bin (no uSD card reader available right now), worked very nicely (watched with minicom over USB:-)

Removed old images, uploaded new ones, OK.

Booted CP/M 2.2 B01 and looked around, yep, OS and communication programs all current.

Dialed into telehack.com with kermit via modem, works :)

Very good job Dave, congrats. Will test some more thoroughly over the next days, we have

a long weekend in Germany because 03-Oct is a national holiday. Will report more later ...

[Colin Little]

Very nice - thank you! All upgrades went through without any problem. Love the fonts! 

Need to play more now with all the modem stuff ......

[Udo Munk]

Is there any way to upload memon80.hex without a microSD card reader handy?

Added the config line, but machine bugs that memon80.hex cannot be found, so

I guess it's not included in the update.bin?

[TheHighNibble]

Yes!

The file update.bin is just a vector for getting files onto the uSD using an upload-reboot cycle.

Its actually a gzipped tar file that has been renamed to update.bin 

I implemented the zlib and microtar libraries to unpack (gunzip) and install (untar) the contents to the uSD

You can see what's in the supplied file by doing a 

tar tzf update.bin

Similarly you can create your own update.bin file and then upload it, reboot and watch it install. The contents need to include full paths without a leading '/'.

So to create an update.bin for the memon80.hex file you could unzip the IMAGE.zip file, then:

cd IMAGE

tar czf update.bin imsai/memon80.hex

tar tzf update.bin

Upload (drag-and-drop on the SYS: icon) this new update.bin file and reboot.

Let me know how you get on.

[Udo Munk]

Excellent, thank you! Worked and now memon/80 is my monitor ROM :)

[TheHighNibble]

Great!. Ever thought about a version of memon/80 that resides at D800h and understands IMSAI MPU-B(A) bank switching?

[Udo Munk]

On Wednesday, October 2, 2019 at 11:54:22 PM UTC+2, TheHighNibble wrote:

Great!. Ever thought about a version of memon/80 that resides at D800h and understands IMSAI MPU-B(A) bank switching?

Not really, I'm happy with a resident monitor @ F800 that can boot from disk.

If needed it's very easy to do, set MEBASE to D800 and add OUT + JMP

instructions at label INIT: same as the MPU ROM's do @ D800, that's all:

d800 - LD A,40

d802 - OUT (F3),A

d804 - JP D807

d807 memon continues here

[John Kennedy]

yay! Amazing release, as you can now use your IMSAI to directly "dial" into actual BBS systems over the Internet.

1. I am keen to learn more about how to handle the case of the new built-in "modem", and the two existing Serial ports, and how they appear to CP/M as logical / physical devices, what jumpers can still be set etc etc.

2. We need a special easy-to-use BBS that is a repo of CP/M software to make it easy to XModem down files :-) and maybe a replacement for Google Groups ;-) :-)

[Udo Munk]

I have implemented enough of the telnet protocol, so that everything works with telehack.com.

Here is a video from testing the PC based machine:

https://youtu.be/SwtvFHiUgQs

The telnet modem might need further improvements, there are hundreds of telnet BBS's and I cannot

test all and everything. Testers and bug reports welcome, thanks.

[Terry Fox]

Congrats!!  It is working fine here.  My IMSAI has been running for several days now, and I can connect to it whenever I want from anywhere in the house.

The hard drive is also extremely nice when working on projects.  My original IMSAI and Altairs had three physical drives (SA-800) so I could put the OS and "system tools" on A, Whatever program I was using at the time (WS, assembler, C compiler) in B, and the actual work product in C.  With the hard drive working, I can put it all on I, with work product either there on one of the floppies.

The firmware update is working really nice as well!  Wonderful update!

Terry

On Wednesday, October 2, 2019 at 7:34:32 AM UTC-4, TheHighNibble wrote:

[AB]

Good evening folks - I think I flubbed this up a bit.  Trying to achieve two things tonight:  the latest upgrade, and get the HDD set up (I: drive.)

• imsaisim_esp32.bin drag and drop... I think went in ok (after reboot sys: reports version 1.4.0 )
• update.bin - attempted drag & drop to update.bin file onto the SYS: icon … I assume it worked (it asks me: Upload update.bin [20005223 bytes] to …/flash? - - I say Y and after a few seconds I see "File /sdcard/update.bin successfully uploaded)
• cpm22b01.dsk - I removed my SD Card and manually copied that to imsai/disks on my windows PC.  I also copied the hd-ws4.hdd

When I reboot I get BDOS error like Tom did for drive I:.  

I have the HARDISK=hd-ws4 present in boot.conf and system.conf.

I did not do anything regarding memon80.hex as I have no clue what that's all about :-)

Guidance always appreciated!

thanks

Andy

 

On Wednesday, October 2, 2019 at 7:34:32 AM UTC-4, TheHighNibble wrote:

[John Kennedy]

#HARDDISK image (don't include the .hdd extension)

HARDDISK=hd-ws4

This goes into boot.conf only.

Have you created a hard disk file on your SD card though?

[Terry Fox]

In addition to putting the hard disk image in disks, and adding the HARDDISK line in boot.conf, I had to update my boot disk in drive A to add hard drive support.

1.  with the sdcard in your windows machine, go to the /disks directory.

2.  Rename cpm22.dsk to something like cpm22old.dsk

3.  Rename cpm22b01.dsk to cpm22.dsk.  This new boot disk has hard drive support.

4.  Put card back in IMSAI, turn back on, restart.  It should work.

Good luck.  I hope that fixes it.  I had the same problem until told by thehighnibble to do this.

Terry

[Udo Munk]

On Monday, October 7, 2019 at 4:26:54 AM UTC+2, AB wrote:

Good evening folks - I think I flubbed this up a bit.  Trying to achieve two things tonight:  the latest upgrade, and get the HDD set up (I: drive.)

• imsaisim_esp32.bin drag and drop... I think went in ok (after reboot sys: reports version 1.4.0 )

Good.

• update.bin - attempted drag & drop to update.bin file onto the SYS: icon … I assume it worked (it asks me: Upload update.bin [20005223 bytes] to …/flash? - - I say Y and after a few seconds I see "File /sdcard/update.bin successfully uploaded)

Good.

• cpm22b01.dsk - I removed my SD Card and manually copied that to imsai/disks on my windows PC.  I also copied the hd-ws4.hdd

Good.

When I reboot I get BDOS error like Tom did for drive I:.

You might still have the old CP/M 2.2 dloppy mounted in the disk. You need to mount the B01 version in drive A:.

When you boot and the BIOS message says B01 drive I: will work:

54K CP/M VERS 2.2 B01

A>

 

I have the HARDISK=hd-ws4 present in boot.conf and system.conf.

This goes into boot.conf only, the entry in system.conf won't do anything and better is removed.

I did not do anything regarding memon80.hex as I have no clue what that's all about :-)

This is Montior program for such system to work at a low level with the system. You don't

need it if you don't know what it is about, just ignore for now.

[Udo Munk]

On Monday, October 7, 2019 at 5:11:40 AM UTC+2, Terry Fox wrote:

In addition to putting the hard disk image in disks, and adding the HARDDISK line in boot.conf, I had to update my boot disk in drive A to add hard drive support.

1.  with the sdcard in your windows machine, go to the /disks directory.

2.  Rename cpm22.dsk to something like cpm22old.dsk

3.  Rename cpm22b01.dsk to cpm22.dsk.  This new boot disk has hard drive support.

4.  Put card back in IMSAI, turn back on, restart.  It should work.

One addition, there is no point in keeping older versions of the CP/M 2.2 disk arround,

these just have less features implemented in the BIOS. It is save to remove them from

the system and use only B01. It might save you time and confusion, if you just cannot

boot an old version anymore, which won't support drive I: or something else.

[AB]

Thanks!  The process of renaming the cpm22.dsk to cpm22old.dsk did the trick.  

cheers

Andy

[Tony Nicholson]

I finally got a round tuit and upgraded to the October 2019 V1.40 release from V1.23.

All seems to have upgraded well and I'm liking the extra "hard" disk space on drive I: and a bit more CP/M TPA memory (now running from a 60K CP/M VERS 2.2 B01 boot floppy).

However, the new virtual modem on SIO-2B (CP/M's UC1: device) means I can't use the second serial port (RS232-2) any more.  I read through the release notes and there's no mention of a way to "disable" the virtual modem.  Is there a way to do this?

Failing that, can I ask for such a capability to be an enhancement request?  Alternatively, perhaps you could fudge this by implementing an ATDUC1 "modem dial command" to redirect the modem via the physical second serial port.  Control back to the modem could be done with a '+++' and an ATZ or ATH would hangup the serial port connection.

Tony

PS: Are you going to release the source code for the IMSAI8080esp ?  I'd probably tinker with this myself if it were available (and contrubute any changes back to the project).

[Udo Munk]

On Tuesday, October 15, 2019 at 6:52:26 AM UTC+2, Tony Nicholson wrote:

However, the new virtual modem on SIO-2B (CP/M's UC1: device) means I can't use the second serial port (RS232-2) any more.  I read through the release notes and there's no mention of a way to "disable" the virtual modem.  Is there a way to do this?

The modem won't stop you using the second serial port, there is no need to disable it.

The Intel IOBYTE uses 2 bits to assign the console to some physical device, 2 bits allow to select between 4 different devices.

If you have more than 4 physical devices you can't use all of them by setting the IOBYTE, but that doesn't make them unusable.

The command stat val: shows the possible settings:

Iobyte Assign:
CON: = TTY: CRT: BAT: UC1:

With stat con:=val: you set the console to one of these devices.

stat con:=tty: - console is set to the tty port which is the first serial port or the USB tty.

stat con:=crt: - console is set to the IMSAI VIO board

stat con:=bat:

Batch is a console device that allowed to run batch jobs, input comes from the second serial port, output goes to

the printer. I have some doubts that anyone is using it these days, however, I assigned it same as DRI did.

stat con:=uc1: console is a user defined device, UserConsole1

And UC1 by default the serial port for the modem.

These are the defaults defined in the BIOS, the BIOS source is included on the disk together with submit scripts

for building a new system, so all and anything can be changed to your needs :)

So lets have a look at the console functions:

;
;       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      TTYIST          ;00 - TTY:
        DW      CRTIST          ;01 - CRT:
        DW      AUXIST          ;10 - BAT:
;       DW      AUXIST          ;11 - UC1:
        DW      USRIST          ;11 - UC1:

;
;       CONSOLE INPUT CHARACTER INTO REGISTER A
;
CONIN:  CALL    DISPATCH        ;GO TO ONE OF THE PHYSICAL DEVICE ROUTINES
        DB      1               ;USE BITS 1-0 OF IOBYTE
        DW      TTYIN           ;00 - TTY:
        DW      CRTIN           ;01 - CRT:
        DW      AUXIN           ;10 - BAT:
;       DW      AUXIN           ;11 - UC1:
        DW      USRIN           ;11 - UC1:

;
;       CONSOLE OUTPUT CHARACTER FROM REGISTER C
;
CONOUT: CALL    DISPATCH        ;GO TO ONE OF THE PHYSICAL DEVICE ROUTINES
        DB      1               ;USE BITS 1-0 OF IOBYTE
        DW      TTYOUT          ;00 - TTY:
        DW      CRTOUT          ;01 - CRT:
        DW      LPTOUT          ;10 - BAT:
;       DW      AUXOUT          ;11 - UC1:
        DW      USROUT          ;11 - UC1:

As you can see UC1 is setup to use the modem port, but by commenting this out and uncommenting the functions using the

second serial port you could change the assignment for UC1. Probably no one wants to edit the BIOS and build and sysgen

a new CP/M all the time, so I also wrote submit scripts, which allow to adjust this in the running system :)

If you run 'submit porta' the UC1 console will use  the second serial RS232 port, if you run 'submit portb' the UC1 console

will use the modem port. The assigment will survive a warm boot (CTL-C), a cold boot (Ext. Clear) of course loads the

BIOS from disk again.

Now you are able to select which port is connected with UC1 for programs like generic Kermit.

The provided qterm won't use UC1, you can select the port to talk to anytime with CTL-^ U, where port A is the second

serial and port B is the modem.

Hope this is complete and understandable, if not just ask what you're missing.

[Tony Nicholson]

On Tuesday, October 15, 2019 at 8:54:17 PM UTC+11, Udo Munk wrote:

On Tuesday, October 15, 2019 at 6:52:26 AM UTC+2, Tony Nicholson wrote:

However, the new virtual modem on SIO-2B (CP/M's UC1: device) means I can't use the second serial port (RS232-2) any more.  I read through the release notes and there's no mention of a way to "disable" the virtual modem.  Is there a way to do this?

The modem won't stop you using the second serial port, there is no need to disable it.

The Intel IOBYTE uses 2 bits to assign the console to some physical device, 2 bits allow to select between 4 different devices.

If you have more than 4 physical devices you can't use all of them by setting the IOBYTE, but that doesn't make them unusable.

 [snip]

Thanks Udo.  I should have done some more investigating of the new BIOS source-code and system disk before sending my message.

Your explanation fired off some of my dormant brain cells regarding CP/M 2.2's input/output details.

By around 1984 I had migrated my systems away from using CP/M 1.4 and CP/M 2.2 to CP/M-Plus - where the newer DEVICE feature allowed access to up to 16 character devices.

The PORTA.SUB and PORTB.SUB submit files you provide give the flexibility to switch between the virtual modem and serial port I was asking for.

I trust this all gets consolidated and written up in the documentation :)

Thanks

Tony

[Udo Munk]

On Tuesday, October 15, 2019 at 11:44:17 PM UTC+2, Tony Nicholson wrote:

Thanks Udo.  I should have done some more investigating of the new BIOS source-code and system disk before sending my message.

No problem, others might find it helpful too.

Your explanation fired off some of my dormant brain cells regarding CP/M 2.2's input/output details.

Good :) 

By around 1984 I had migrated my systems away from using CP/M 1.4 and CP/M 2.2 to CP/M-Plus - where the newer DEVICE feature allowed access to up to 16 character devices.

We will get at this later too, when the machine got a MMU and more bnked memory.

The PORTA.SUB and PORTB.SUB submit files you provide give the flexibility to switch between the virtual modem and serial port I was asking for.

Excellent. 

I trust this all gets consolidated and written up in the documentation :)

Thanks

Tony

Welcome,

Udo