Help running Atari 800 terminal emulator from MIT

[Lars Brinkhoff]

Hello,

I have found a precursor or parallel offshoot from Jack Palevich's terminal emulator Chameleon. It was found on PDP-10 backup tapes from MIT's Logo lab (a part of the infamous AI lab).

The source code assembles without errors using a cross assembler running on ITS (the Incompatible Timesharing System). The output from the assembler is a binary block-structured file. I have converted this to an Atari DOS executable file. I tried to run it on the Atari800 emulator, but I just get a blank screen. I would appreciate some hints how to run this program.

The source code is available in this GitHub pull request:
https://github.com/PDP-10/its/pull/2034

I'm attaching the converted binary file and assembler listing, assembled with BINARY defined. From a comment: "Binary i.e. Testing phase where no copy is kept of the code, we just jump right to it." which assembles a JMP BEGIN at addres 0600.

chameleon.zip

[evilmoo]

So just from a cursory glance of the binary file, it looks like there's no part of the file to set RUNAD ($02E0) to 0600, so the binary gets loaded in to memory, but not executed.

 

Also it's been a long time since I've looked at atari100, so I'm not 100% sure it will directly load a DOS file directly without a DOS disk image loaded first.

[+Stephen]

Might also be that loading down low at $600 won't work.  Certainly can't do that with any of the 100 or so DOSes we have on the system.

[evilmoo]

39 minutes ago, Stephen said:

Might also be that loading down low at $600 won't work.  Certainly can't do that with any of the 100 or so DOSes we have on the system.

The bulk of it starts at $6000.  For whatever reason, there's just this stub at $0600:

 

[0002] Block:  0600-0608 (0009)
0600  4C 07 60    JMP   $6007

And a few other non-code bytes I omitted.

[+Stephen]

Crazy thought - could have there been a reason to be using BASIC cart, loading this, and when wanting to invoke it, doing a "? USR(1536)" which would jump into the code?  Course - if calling anything from BASIC, you have to clean the stack so that doesn't make sense.  Just thinking out loud.

[Lars Brinkhoff]

12 hours ago, evilmoo said:

So just from a cursory glance of the binary file, it looks like there's no part of the file to set RUNAD ($02E0) to 0600, so the binary gets loaded in to memory, but not executed.

 

Also it's been a long time since I've looked at atari100, so I'm not 100% sure it will directly load a DOS file directly without a DOS disk image loaded first.

 

Thanks!  I'll try adding a start address, maybe both 0600 and 6000.  From the atari800 source code I thought it would use the first load address as a default start address, but maybe not.

 

Would you recommend another Atari 800 capable emulator that can run on Linux?

[Lars Brinkhoff]

9 hours ago, Stephen said:

Crazy thought - could have there been a reason to be using BASIC cart, loading this, and when wanting to invoke it, doing a "? USR(1536)" which would jump into the code?  Course - if calling anything from BASIC, you have to clean the stack so that doesn't make sense.  Just thinking out loud.

 

Interesting!  The manual for Chameleon v2 does say a BASIC cartridge is a requirement:

https://archive.org/details/APXChameleonManual/page/n11/mode/2up

Edited June 17, 2021 by Lars Brinkhoff

[GoodByteXL]

3 minutes ago, Lars Brinkhoff said:

Would you recommend another Atari 800 capable emulator that can run on Linux?

I use Altirra thanks to WINE on Linux.

[Lars Brinkhoff]

10 hours ago, evilmoo said:

The bulk of it starts at $6000.  For whatever reason, there's just this stub at $0600

It's due to this part: https://github.com/PDP-10/its/blob/master/src/atlogo/supdup.1#L982-L987

I believe the program could have been transferred from the PDP-10 over the serial line during development.

 

There is another entry point if you instead define DISKFI during assembly: 

https://github.com/PDP-10/its/blob/master/src/atlogo/supdup.1#L895-L975

Maybe this was used to transfer the program and then have it write itself to a floppy disk file.

[Lars Brinkhoff]

I tried adding a start vector at 02E0, both 0600 for the stub and 6000 for the main program.  But the result is the same as without.

 

Here is a screenshot.  There is some graphics in addition to the cursor which maybe indicate something was trying to run.

 

From the manual I would expect a splash screen.  The source code says it should look something like

CHAMELEON TTY BY JHP

(C)1981 MIT LOGO LAB

[sanny]

If supdup.lst is the source code, the entry point to the program appears to be $6007, not $6000.

[sanny]

It seems to work for me:

 

I've used DOS 2.0s. Start atari800 like this

 

$ atari800.x11 -atari -ntsc -basic -rdevice -H1 . ~/some/where/dos20s-test.atr

 

In the current directory (H1:) I've placed the chameleon.exe file, renamed to CHAM.COM.

When the Atari starts up, type

 

DOS    (leave BASIC)

L

H:CHAM.COM

M

6007

 

 

[Lars Brinkhoff]

38 minutes ago, sanny said:

$ atari800.x11 -atari -ntsc -basic -rdevice -H1 . ~/some/where/dos20s-test.atr

 

 

Thank you very much!  I had no idea about those command line arguments.

[Lars Brinkhoff]

3 hours ago, sanny said:

DOS    (leave BASIC)

L

H:CHAM.COM

M

6007

 

I had to update atari800 to have it accept your command line arguments.  I built it off GitHub.

The DOS commands seem to go well, but when the program starts I get this.

 

Maybe my .atari800.cfg is wrong?  I have these lines.

ROM_OS_B_NTSC=/home/lars/.atari800/ATARIOSB.ROM
ROM_BASIC_A=/home/lars/.atari800/ATARIBAS.ROM
ROM_BASIC_B=/home/lars/.atari800/ATARIBAS.ROM
ROM_BASIC_C=/home/lars/.atari800/ATARIBAS.ROM
MACHINE_TYPE=Atari OS/A
 

Edited June 17, 2021 by Lars Brinkhoff
Typo.

[sanny]

Hmm, I have just these lines (atari800 isn't completely set up on this machine):

 

ROM_OS_BB01R2=/home/chris/atari/atarixl.rom

ROM_5200=/home/chris/atari/5200.rom

ROM_BASIC_C=/home/chris/atari/ataribas.rom

ROM_400/800_CUSTOM=/home/chris/atari/atariosb.rom

MACHINE_TYPE=Atari XL/XE

 

I think MACHINE_TYPE just specifies the default.

 

$ md5sum /home/chris/atari/atariosb.rom /home/chris/atari/ataribas.rom
a3e8d617c95d08031fe1b20d541434b2  /home/chris/atari/atariosb.rom
0bac0c6a50104045d902df4503a4c30b  /home/chris/atari/ataribas.rom

 

 

[Lars Brinkhoff]

I stepped through the code using the emulator monitor.  I get stuck in an endless loop here:

 

        LDA     RTCLOC+1        ;Time in 4 second slices
        CLC
        ADC     #1

COPYW:  CMP     RTCLOC+1
        BNE     COPYW

Apparently RTCLOC isn't updated.  The source code has this definition:

RTCLOCK =       $0012   ;REAL TIME CLOCK (IN 16 MSEC UNITS)

I see in documentation elsewhere $14 should be incremented every vsync and overflow into $13 and then $12.  From what I see in the monitor, these three locations never change.

[Lars Brinkhoff]

The application supplies its own VBLANK routine.  At the end it jumps to the system routine at E7D1.  This in turn ends up vectoring through 226, CDTMA1.  But this address is 0, which causes major failure.

 

Am I missing some part of the system that is supposed to fill in the 226 vector?

[Lars Brinkhoff]

Got it.  Disabling this made 226 take on the correct value.

ENABLE_SIO_PATCH=0

 

[sanny]

I now got your display with the flickering on  the left side.

 

I didn't remember what I did do when it worked, but yes, I had disabled the SIO patch.

 

Now it works again.

 

You can disable the SIO patch with "-nopatch" on the command line.

[Lars Brinkhoff]

33 minutes ago, Lars Brinkhoff said:

The application supplies its own VBLANK routine.  At the end it jumps to the system routine at E7D1.

This hard-coded address only works for OS A.  The OS B address is E7AE, which is where RTCLOCK is incremented.

 

I didn't find an NTSC OS A, but the PAL version works ok.  Now I do get the second line, and then the main mode is entered.  Here, GLASS means "Glass TTY" mode.

 

[+bhall408]

19 hours ago, Stephen said:

Crazy thought - could have there been a reason to be using BASIC cart, loading this, and when wanting to invoke it, doing a "? USR(1536)" which would jump into the code?  Course - if calling anything from BASIC, you have to clean the stack so that doesn't make sense.  Just thinking out loud.

Normally you do multiple PLAs (to retrieve passed information), but if you didn't do that it would just be wasted bytes on the stack, not the end of the world.

 

Here is a "do nothing" example for calling when 2 parameters are passed

 

U=USR(ADR(DECAP$), ADR(MSG$), LEN(MSG$))
 

 

Entry:
	cld	; have seen this in other USR routines

	pla	; get the number of arguments
	
; Get the address of the string
	pla	; hi of string
	pla	; lo of string
	
; Get the length of the string
	pla	; hi of length of string
	pla	; lo of length of string

; clear the return value
	lda #0
	sta RETVALL	
	sta RETVALH	

; return to basic
	rts
	

 

[sanny]

It seems that the program was developed when OS/A was the ROM code.

 

Since it comes from MIT (AFAIU), I guess they had NTSC machines.

 

The OS/A version for NTSC appears to be lost. ?

[+Stephen]

35 minutes ago, sanny said:

It seems that the program was developed when OS/A was the ROM code.

 

Since it comes from MIT (AFAIU), I guess they had NTSC machines.

 

The OS/A version for NTSC appears to be lost. ?

OS/A - do you mean the standard Atari OS, Revision A from very early machines, or OS/A as a replacement ROM?  We have a few versions of the former.

Apologies if this is not what is needed.

+ Atari OS vA NTSC.rom

[sanny]

thanks!

 

I was under the impression that it's "lost", since I couldn't find it.

[Hackerjack]

Jack Palevich here. Found this discussion while searching the web, hope it's not too late to reply.

 

My memory is pretty hazy, but I think what happened is that I gave a copy of my Chameleon terminal emulator app source code to Leigh Klotz and Patrick Sobalvarro, and they extended that version to work with the programming environment of the MIT Logo Lab.

 

I had originally written Chameleon to support the commercially popular ADM-3A and VT-52 terminals, and then I added SupDup support (a virtual terminal that was popular on MIT's computers.) SupDup (short for super-duper) was more efficient in its encoding scheme than the other terminal emulators of that day.

I never worked on Atari Logo, but I did enjoy discussing 6502 programming with Leigh and Patrick.

Anyway, from looking at the sources for the Logo Lab's version of Chameleon, it looks like they added support for some custom terminal emulators and a custom file transfer protocol. Pretty cool!

I graduated from MIT in January of '83, and lost contact with the Logo Lab engineers around that time.

When I first started writing Atari assembly language apps, OS/A was the only ROM, and I wasn't clear on the idea of "official entry points", so I may have accidentally jumped into the wrong part of the ROM. But I am pretty sure I had figured things out after December '81, due to the same bug happening in my game "Shoot!" published in Compute! magazine. Maybe this code was forked from my terminal emulator before then.