dudley@nadc.arpa (05/03/83)
I beat the vt180. I have successfully gotten mboot3 running on the little sucker. The port poop revealed in the letter excerpt below is only part of the solution: From: Dick <MEAD@USC-ECLB> Subject: Re: vt180 port poop COMM port values are: DATA=58H STAT=59H TBE=01,RDA=02 CONSOLE values are: DATA=40H STAT=41H (I assume same bit values) One gotcha, I read that interrupts are used in the VT180, so MBOOT3 and other adaptations to this system may need to do some trickery to work at all. I had used the right bits/addresses in one try and still no good. ------- The real trick is that since incoming characters are handled by interrupts, the usart will never seem to have any characters ready when it is polled by mboot3 in the normal fashion. Rather then do what I suggested in an earlier letter, i.e. turn off the interrupts, I did what DEC did in the RDR: device handler in the vt180 bios. That is, I poll the memory locations that the interrupt handler uses to communicate with the bios. In the latest version of CPM that DEC is supplying [2.2 (1.1)], *the magic locations are:* 0f541h = rec'd data available if == 1 0f546h = rec'd character The code to check for status in mboot3 is thus: before: | after: in modctlp | lda 0f541h ani modrcvr | cpi modrcvr | ora a jnz term ;no char rec'd | jz term ;no char rec'd and the code to get the rec'd char is now: in moddatp | mvi a,0 ;clear status ani 7fh | sta 0f541h | lda 0f546h ;get char | ani 7fh I got the magic location values by disassembling the bios RDR: handler. Once you get past the IOBYTE nonsense, the handler loads the IX register with the location of the status table for the RDR: device, and jumps to a routine that polls the memory locations pointed to by the IX register to wait for a char to come in. The magic locations listed above are actually IX+2 and IX+7 in the RDR: handler. These location are likely to change if DEC releases a new version of the bios. I haven't gotten mdm707 running yet, although I'm close. The overlay method won't work since the code size of the routines is so different from that in the standard version of mdm707. Instead, the entire mdm707.asm file must be edited and re-assembled. Since the little toy disks on the vt180 are so small, I do the editing and assembling on another CPM machine and use mboot3 to bring over the com file. Time has not permitted me to finish the debug of mdm707 as a result of all the kludges. Let me know if you get any revelations on the vt180. good luck-- dudley@nadc ~v