Pascal on the 99/4A

[+Vorticon]

Now that I got my brain properly wrapped around the TI's implementation of concurrency, I was able to create a version that actually prints the messages sequentially as expected. While the task itself is simplistic here, it could obviously be made much more interesting, such as cycling between different sensor inputs etc... using global parameters. There may be potential there.

 

program semtest;
var
 i : integer;
 pid1, pid2, pid3 : processid;
 console, sem : semaphore;
 
procedure conwrite(outiam : integer; outmsg : string);
begin
 wait(console);
 writeln('I am ', outiam, ' and my message is ', outmsg);
 signal(console);
end;

process msgwriter(whoiam : integer; mymsg : string);
begin
 repeat
  conwrite(whoiam, mymsg);
  wait(sem);
 until false;
end;

begin
 seminit(console, 1);
 seminit(sem, 0);
 start(msgwriter(0, 'Shakespeare'), pid1, 900, -1);
 start(msgwriter(1, 'monkey'), pid2, 900, -1);
 start(msgwriter(2, 'typewriter'), pid3, 900, -1);
 repeat
  for i := 1 to 3 do
   signal(sem);
 until false;
end.

 

 

 

[apersson850]

Yes, such an outline makes it more deterministic. The first version was perhaps a more true multitasking, where you don't really know exactly in which order things happen.

 

After all these discussions I would happily undertake the work to fix an attach that works. Then it also needs events to link to a semaphore. VDP interrupt, probably with a reduction factor, is an obvious candidate. If RS232 reception is too I'm not sure. Perhaps too slow to go up to Pascal level to handle that. PIO port inputs I've handled before. A key pressed on the keyboard is another obvious thing. Perhaps joystick activity, at least because it's simple enough to test with.

 

The issue is more all other things that go around. Due to other events being organized here it will at least not be until May I can spend time on this.

[+Vorticon]

That would be awesome! VDP interrupt, PIO input, joystick activity and key presses are definitely top candidates. Some kind of interrupt detection around the reception of a character on the RS232 port could actually be quite useful in order to wake up a pended task that reads data from the serial port. I'm thinking of my Heathkit robot project in particular here.

We've waited 43 years, so I don't think there is any rush 

[+Vorticon]

Moving on to my next project: develop a set of utilities of SAMS card access within the pcode system. First test: initialize the card and verify that it is present. I'm plagiarizing Bruce Harrison's code as published in Micropendium (sep/oct 96), and it's not working. I'm not sure if the pcode card needs to be deactivated prior to SAMS access but I tried it both ways: if the pcode card remains active, the system just hangs, whereas if it is inactive I get a black screen and then the system hangs (more interesting to look at I suppose). In looking at the debugger, only SAMS registers 0 to A are being initialized, so something is fishy here.

 

;routines for sams card access
;walid maalouli
;march 2024

        .func samsinit
;initialize the sams card and verify card is present
;returns 0 for absent and 1 for present
;adapted from routine by bruce harrison (rip)
;usage: status := samsinit

        .def procret,pmeret,pcodeon,pcodoff
        mov     r11,@procret
        bl      @pcodoff
        li      r12,1e00h       ;cru address of sams card
        sbo     0               ;turn card on
        li      r1,0feffh
        li      r0,4000h        ;start address of sams registers
nxtpage ai      r1,0101h        ;increment page number starting at 0
        mov     r1,*r0+         ;load page number into sams register
        ci      r0,4020h        ;beyond last register (401eh)?
        jlt     nxtpage
        c       r1,@401eh       ;if match then card present
        jne     nocard
        li      r2,1
        jmp     endinit
nocard  clr     r2
endinit mov     r2,*r10         ;place card indicator on return stack
        sbz     0               ;turn sams card off
        bl      @pcodeon
        mov     @procret,r11
        b       *r11

pcodeon li      r12,1f00h       ;activate the pcode card
        sbo     0
        mov     @pmeret,r12     ;restore the pme pointer
        b       *r11
        
pcodoff mov     r12,@pmeret     ;save the pme pointer
        li      r12,1f00h       ;deactivate the pcode card
        sbz     0
        b       *r11

pmeret  .word
procret .word

        .end

 

[apersson850]

I've never worked with SAMS, but it looks like it's at 4000h, so yes, p-code had to turn off.

You must save and restore R12 too. The PME uses R8-R15 in Pascalws.

Edited March 21 by apersson850

[+Vorticon]

18 minutes ago, apersson850 said:

I've never worked with SAMS, but it looks like it's at 4000h, so yes, p-code had to turn off.

You must save and restore R12 too. The PME uses R8-R15 in Pascalws.

I am saving and restoring R12 so I don't think that's the issue. And since I am not using R8-R15, there is no need to save them either. The behavior is odd...

[Asmusr]

10 minutes ago, Vorticon said:

I am saving and restoring R12 so I don't think that's the issue. And since I am not using R8-R15, there is no need to save them either. The behavior is odd...

It looks OK, and it didn't crash for me. However I don't have a p-code card. Can't you see in the debugger where it's crashing? Do you have interrupts switched off?

[+Vorticon]

20 minutes ago, Asmusr said:

It looks OK, and it didn't crash for me. However I don't have a p-code card. Can't you see in the debugger where it's crashing? Do you have interrupts switched off?

Do I need to disable interrupts when accessing the SAMS card? Also when you say it's working for you, how are you testing the code?

As to finding out where it's crashing, I wouldn't know where to even start looking since the code could be stashed anywhere by the system. All I can see is that only SAMS registers 0 to A are being initialized for some reason.

 

Edit: I inserted an infinite loop right after the JLT NXTPAGE statement and it never gets to it, which makes sense since not all the SAMS registers are being initialized, so the issue must be happening when SAMS register >401B gets accessed, which is referencing the >B000 memory block. Something tells me I'm overwriting some system variable somehow, but that should not be possible since the mapper was not turned on. 

[+TheBF]

2 hours ago, Vorticon said:

Do I need to disable interrupts when accessing the SAMS card?

I don't disable interrupts and have never had an issue.

 

Also something @Lee Stewart sorted out for me; the initialization values only need to be 1 byte.

In order to use cards with more than >FF pages (1Meg) think of the initialization value as an integer from 1 to n,

but swap bytes before moving the value into the SAMS card registers. It works.

 

With the SAMS card competing for the >4000 address block with your Pascal Card you will have to do everything in Assembler I guess.

Because all the the lower registers are used for Pascal you might want to bite-the-bullet and go with a SAMS workspace and BLWP into your code.  ??

 

[+Vorticon]

I need to get the card working first though. I still don't know what's going on here. I'm going to test it out on real hardware tonight and see if it makes any difference (probably not).

[+Vorticon]

31 minutes ago, TheBF said:

Also something @Lee Stewart sorted out for me; the initialization values only need to be 1 byte.

In order to use cards with more than >FF pages (1Meg) think of the initialization value as an integer from 1 to n,

but swap bytes before moving the value into the SAMS card registers. It works.

I'm not too clear on this. Can you please elaborate a little more?

[+Vorticon]

We I'll be damned... When I tried it on real hardware it worked perfectly! Something must be off with the Classic 99 emulation of the pcode card or SAMS card. @Tursi any thoughts?

I'll post a disk image tomorrow to try on MAME.

[+TheBF]

You beat me to it

It's all about that initial value 0101. 

Your real card is 1M byte I think.

 

Classic 99 has 32M bytes. 

 

1Mb has 256 (>FF) pages so you can the same number in each side  of the SAMS register

For bigger cards you 

start with  0001  SWPB -> SAMS register 

Then 0002 SWPB ->  next SAMS register 

 

I only have Forth code but if you can grok it from your past experience it shows what I mean. 

Spoiler

\ SAM 1M memory card common code  Nov24 2022 Brian Fox
\ update Feb 2024
DECIMAL
  24 USER 'R12  \ address of R12 in any Forth workspace
HEX
: SAMSCARD  ( -- ) 1E00 'R12 ! ; \ select sams card CRU addr.

HEX
\ *set the CRU address in 'R12 before using these words*
  CODE 0SBO  ( -- ) 1D00 ,  NEXT, ENDCODE
  CODE 0SBZ  ( -- ) 1E00 ,  NEXT, ENDCODE
  CODE 1SBO  ( -- ) 1D01 ,  NEXT, ENDCODE
  CODE 1SBZ  ( -- ) 1E01 ,  NEXT, ENDCODE

: SAMS-ON   ( -- ) SAMSCARD 1SBO ;  \ enable mapper
: SAMS-OFF  ( -- ) SAMSCARD 1SBZ ;  \ disable mapper

HEX
4000 CONSTANT SAMSREGS

\ * SAMSINI sets card to "pass-through" condition
\   Tests the size of the SAMS card upto 1.4 Mbytes
DECIMAL
: SAMSINI ( -- )
  CR ." 1M SAMS card "
    SAMSCARD    
    0SBO        
    0                     \ register value 
    SAMSREGS  22 CELLS    \ registers base address, # SAMS regs
    BOUNDS ( -- >4030 >4000)
    DO
        DUP >< I !    \ swap bytes and write 16 bits to reg
        I C@  OVER <>  ABORT" failed"
        1+
    2 +LOOP
    DROP
    0SBZ
    ." initialized"
;

 

 

[+TheBF]

Edit: 

 

For bigger cards you 

start with  0000  SWPB -> SAMS register 

Then         0001 SWPB ->  next SAMS register 

then          0002  SWPB -> next SAMS register

 

 

[+TheBF]

Topic shift:  RS232 receive code

 

Since my system is using RS232 for the user console, I got to notice something when I was working on an XMODEM program. 

This is applicable to your code below @VORTICON and might explain why you can't get transfers going faster. 

        .proc   getpacket,1
;get an xmodem packet
;usage: getpacket(bytearray)

        .ref    pcodeon,pcodoff,rs232on,rs232of,uartdis,procret
        mov     r11,@procret
        bl      @pcodoff
        bl      @rs232on
        mov     *r10+,r1        ;get array pointer
        a       @uartdis,r12    ;uart base cru address
        li      r2,131          ;number of bytes to get
        sbz     -27             ;activate cts line
bufchk  tb      21              ;check if receive buffer is empty
        jne     bufchk
        stcr    *r1+,8          ;store byte into array
        sbz     18              ;reset buffer cru bit 21
        dec     r2
        jne     bufchk          ;132 bytes transferred?
        sbo     -27             ;inactivate cts line
        bl      @rs232of
        bl      @pcodeon
        mov     @procret,r11
        b       *r11
        

 

My terminal was acting weird when I typed into it after I rebuilt my kernel. 

If held a key the repeat was stopping and starting and when I pasted text into it, it was slower and stopping and starting like it never did before 

I tracked it down to the lines  SBZ -27    and  SBO -27  that control the RTS/CTS handshaking. 

 

In my original code I changed R12 back to the base address and set/reset bit 5.

This makes me suspect that -27 is the wrong value to reach back to bit 5 from CRU address >1340. 

 

using your code as an example here is what worked smoothly in my code and might get you more speed

        .proc   getpacket,1
;get an xmodem packet
;usage: getpacket(bytearray)

        .ref    pcodeon,pcodoff,rs232on,rs232of,uartdis,procret
        mov     r11,@procret
        bl      @pcodoff
        bl      @rs232on
        mov     *r10+,r1        ;get array pointer

        li      r2,131          ;number of bytes to get
        sbz      5             ;activate cts line
;       ** CHANGED ** 
        a       @uartdis,r12    ;uart base cru address

bufchk  tb      21              ;check if receive buffer is empty
        jne     bufchk
        stcr    *r1+,8          ;store byte into array
        sbz     18              ;reset buffer cru bit 21
        dec     r2
        jne     bufchk          ;132 bytes transferred?
;       ** changed **        
        li      r12,1300        ; You should SAVE R12 somewhere at the top to use here 
        sbo     5             ;inactivate cts line
        
        bl      @rs232of
        bl      @pcodeon
        mov     @procret,r11
        b       *r11
        

 

[+Lee Stewart]

6 hours ago, Vorticon said:

Moving on to my next project: develop a set of utilities of SAMS card access within the pcode system. First test: initialize the card and verify that it is present. I'm plagiarizing Bruce Harrison's code as published in Micropendium (sep/oct 96), and it's not working. I'm not sure if the pcode card needs to be deactivated prior to SAMS access but I tried it both ways: if the pcode card remains active, the system just hangs, whereas if it is inactive I get a black screen and then the system hangs (more interesting to look at I suppose). In looking at the debugger, only SAMS registers 0 to A are being initialized, so something is fishy here.

 

;routines for sams card access
;walid maalouli
;march 2024

        .func samsinit
;initialize the sams card and verify card is present
;returns 0 for absent and 1 for present
;adapted from routine by bruce harrison (rip)
;usage: status := samsinit

        .def procret,pmeret,pcodeon,pcodoff
        mov     r11,@procret
        bl      @pcodoff
        li      r12,1e00h       ;cru address of sams card
        sbo     0               ;turn card on
        li      r1,0feffh
        li      r0,4000h        ;start address of sams registers
nxtpage ai      r1,0101h        ;increment page number starting at 0
        mov     r1,*r0+         ;load page number into sams register
        ci      r0,4020h        ;beyond last register (401eh)?
        jlt     nxtpage
        c       r1,@401eh       ;if match then card present
        jne     nocard
        li      r2,1
        jmp     endinit
nocard  clr     r2
endinit mov     r2,*r10         ;place card indicator on return stack
        sbz     0               ;turn sams card off
        bl      @pcodeon
        mov     @procret,r11
        b       *r11

pcodeon li      r12,1f00h       ;activate the pcode card
        sbo     0
        mov     @pmeret,r12     ;restore the pme pointer
        b       *r11
        
pcodoff mov     r12,@pmeret     ;save the pme pointer
        li      r12,1f00h       ;deactivate the pcode card
        sbz     0
        b       *r11

pmeret  .word
procret .word

        .end

 

 

Bruce Harrison’s code works fine up to 1 MiB SAMS, but fails above that due, I think, to a misunderstanding, early on, of how the SAMS card operates. Having the same value in both bytes of the word copied to the SAMS registers works  up to 1 MiB because only one byte matters (MSB, actually). Always putting the same value in the LSB as the MSB means you don’t need to worry about which byte needs the value. Above 1 MiB, you need to treat SAMS properly, because, now, both bytes are important. There are a couple of ways to think about this: (1) only pages from 0 to the maximum page (>FF for 1 MiB, >1FFF for 32 MiB as in Classic99) or (2) banks and pages, with each bank having 256 pages. Either way, the word copied to a SAMS register is the same.

 

Using the bank:page scenario, you can put the zero-based bank# in the MSB and the zero-based page# of that bank in the LSB for ease of coding/understanding and swap the bytes just before copying to a SAMS register. Or you can put the bank# in the LSB and that bank’s page# in the MSB and copy to a SAMS register without swapping bytes. When your code copies >0101 to a SAMS register, you are invoking page 1 of bank 1. For 1 MiB SAMS, this is really page 1 of bank 0 because only bank 0 exists, i.e., the LSB is ignored. However, for Classic99, you actually are invoking bank 1, which was not your intention. It is for this reason, I never use the Harrison scenario, even when it is safe up to 1 MiB—it just is bad practice.

 

The following has a better chance of working in Classic99 (changes to initial value and increment of R1):

;routines for sams card access
;walid maalouli
;march 2024

        .func samsinit
;initialize the sams card and verify card is present
;returns 0 for absent and 1 for present
;adapted from routine by bruce harrison (rip)
;usage: status := samsinit

        .def procret,pmeret,pcodeon,pcodoff
        mov     r11,@procret
        bl      @pcodoff
        li      r12,1e00h       ;cru address of sams card
        sbo     0               ;turn card on
        li      r1,0ff00h
        li      r0,4000h        ;start address of sams registers
nxtpage ai      r1,0100h        ;increment page number starting at 0
        mov     r1,*r0+         ;load page number into sams register
        ci      r0,4020h        ;beyond last register (401eh)?
        jlt     nxtpage
        c       r1,@401eh       ;if match then card present
        jne     nocard
        li      r2,1
        jmp     endinit
nocard  clr     r2
endinit mov     r2,*r10         ;place card indicator on return stack
        sbz     0               ;turn sams card off
        bl      @pcodeon
        mov     @procret,r11
        b       *r11

pcodeon li      r12,1f00h       ;activate the pcode card
        sbo     0
        mov     @pmeret,r12     ;restore the pme pointer
        b       *r11
        
pcodoff mov     r12,@pmeret     ;save the pme pointer
        li      r12,1f00h       ;deactivate the pcode card
        sbz     0
        b       *r11

pmeret  .word
procret .word

        .end

 

...lee

[+Lee Stewart]

I should add that reading a SAMS register only gets you the page# of the bank:page scenario, which would be why the following instruction surely failed in Classic99:

        c       r1,@401eh       ;if match then card present

 

This is because the page# is stored in the SAMS register, but the bank# affects only the latches on the SAMS card.

 

...lee

[Asmusr]

7 hours ago, Vorticon said:

Do I need to disable interrupts when accessing the SAMS card? Also when you say it's working for you, how are you testing the code?

I guess not. I only asked because I was running with interrupts disabled when it worked for me, and it sounded like something was interrupting your code. But the reason it worked for me was that I was using JS99er, which only supports 1MiB of SAMS.

 

This discussion makes me wonder, the 74LS612 memory mapper in the SAMS card has 12 bit registers, but in a real 1MiB SAMS card, can you also load data into the 4 most significant bits? Those bits would not be used, of course, since the card only has 1 MiB RAM, but is it possible to read back all 12 bits from the registers at >4000 - >401f? It's interesting for emulation whether the values written to the LSBs of those registers just disappear. 

[Asmusr]

To answer my own question, according to Nouspikel https://www.unige.ch/medecine/nouspikel/ti99/superams.htm "The remaining pins D0-D4 [should be D0-D3] are grounded" so they cannot be read back on an 1MiB card. But then another question: are the registers only available at >4000 - >401f or can you also access them at >4020 - >403f etc.?

[+Vorticon]

11 hours ago, Lee Stewart said:

Bruce Harrison’s code works fine up to 1 MiB SAMS, but fails above that due, I think, to a misunderstanding, early on, of how the SAMS card operates. Having the same value in both bytes of the word copied to the SAMS registers works  up to 1 MiB because only one byte matters (MSB, actually). Always putting the same value in the LSB as the MSB means you don’t need to worry about which byte needs the value. Above 1 MiB, you need to treat SAMS properly, because, now, both bytes are important. There are a couple of ways to think about this: (1) only pages from 0 to the maximum page (>FF for 1 MiB, >1FFF for 32 MiB as in Classic99) or (2) banks and pages, with each bank having 256 pages. Either way, the word copied to a SAMS register is the same.

 

Using the bank:page scenario, you can put the zero-based bank# in the MSB and the zero-based page# of that bank in the LSB for ease of coding/understanding and swap the bytes just before copying to a SAMS register. Or you can put the bank# in the LSB and that bank’s page# in the MSB and copy to a SAMS register without swapping bytes. When your code copies >0101 to a SAMS register, you are invoking page 1 of bank 1. For 1 MiB SAMS, this is really page 1 of bank 0 because only bank 0 exists, i.e., the LSB is ignored. However, for Classic99, you actually are invoking bank 1, which was not your intention. It is for this reason, I never use the Harrison scenario, even when it is safe up to 1 MiB—it just is bad practice.

Thank you for that great explanation. Now I fully get the issue. Harrison complained in his article about the lack of proper documentation for the AMS card and he had to cobble together an understanding of its functionality through a combination of source code evaluation and asking others like Rich Gilbertson and Lew King. Besides, anything beyond 1 meg was probably not on anyone's horizon back in the day, and frankly even today there is hardly anything out there that requires more than that except perhaps the wonderful Stevie editor by @retroclouds. 

 

11 hours ago, Lee Stewart said:

I should add that reading a SAMS register only gets you the page# of the bank:page scenario, which would be why the following instruction surely failed in Classic99:

        c       r1,@401eh       ;if match then card present

 

This is because the page# is stored in the SAMS register, but the bank# affects only the latches on the SAMS card.

Not sure I understand that. Wouldn't that comparison happen on the full word of the SAMS register? Edit: figured it out with @FALCOR4's document below.

 

12 hours ago, TheBF said:

In my original code I changed R12 back to the base address and set/reset bit 5.

This makes me suspect that -27 is the wrong value to reach back to bit 5 from CRU address >1340. 

 (>1380 - >1340 - 6) / 2 = 29! You might be right unless I'm missing something. I'll test it out tonight.

[Tursi]

10 hours ago, Vorticon said:

We I'll be damned... When I tried it on real hardware it worked perfectly! Something must be off with the Classic 99 emulation of the pcode card or SAMS card. @Tursi any thoughts?

I'll post a disk image tomorrow to try on MAME.

Yeah, the Classic99 SAMS is a 32MB card and self-initializes, neither of which is normal.

 

[+TheBF]

1 hour ago, Vorticon said:

Thank you for that great explanation. Now I fully get the issue. Harrison complained in his article about the lack of proper documentation for the AMS card and he had to cobble together an understanding of its functionality through a combination of source code evaluation and asking others like Rich Gilbertson and Lew King. Besides, anything beyond 1 meg was probably not on anyone's horizon back in the day, and frankly even today there is hardly anything out there that requires more than that except perhaps the wonderful Stevie editor by @retroclouds. 

 

Not sure I understand that. Wouldn't that comparison happen on the full word of the SAMS register? 

 

 (>1380 - >1340 - 6) / 2 = 29! You might be right unless I'm missing something. I'll test it out tonight.

 I tried -29 as well and got the same jittering response when I hold a key down. ???

I just went back to my original code so I could work on something else.

[+FALCOR4]

2 hours ago, Vorticon said:

Thank you for that great explanation. Now I fully get the issue. Harrison complained in his article about the lack of proper documentation for the AMS card and he had to cobble together an understanding of its functionality through a combination of source code evaluation and asking others like Rich Gilbertson and Lew King. Besides, anything beyond 1 meg was probably not on anyone's horizon back in the day, and frankly even today there is hardly anything out there that requires more than that except perhaps the wonderful Stevie editor by @retroclouds. 

 

Not sure I understand that. Wouldn't that comparison happen on the full word of the SAMS register? 

 

 (>1380 - >1340 - 6) / 2 = 29! You might be right unless I'm missing something. I'll test it out tonight.

Lee's explanation on how SAMS cards greater than 1 Meg need to be addressed is spot on.  It is probably smart to just assume that any software that is written for SAMS is for cards that are over 1 Meg and that would make it universal for any SAMS card.

 

 

SAMS registers explained_Srt_AP edits.rtf

[+Vorticon]

With the card initialization and detection sorted out, next I wrote a routine to find out the size of the card (number of pages). Well guess what? It's not working either 😭. It appears that the assigned register (here >4004 pointing to >2000 in low memory) will dutifully write to that memory location regardless of the value of the page/bank value assigned to it. That can't be right, but I checked with the debugger and it seems that way. The way I'm finding out the number of available pages is by assigning an incremental page/bank value to register >4004, writing a value in r2 (>FFFF) to >2000, then comparing >2000 to R2 again. If it matches, then the page is OK and we continue, otherwise we have reached the end of the available pages. That's how Harrison did it.

 

.func   samssize
;returns the number of pages available
;usage: sizeint := samssize

        .ref    pcodeon,pcodoff,procret
        mov     r11,@procret
        bl      @pcodoff
        li      r12,1e00h       ;cru address of sams card
        sbo     0               ;turn on card
        clr     r4              ;page counter
        li      r1,0ffffh       ;page/bank register value
        li      r2,0ffffh       ;test value
        mov     @2000h,r5       ;save contents of the >2000 low memory address
        sbo     1               ;turn on mapper
incpage ai      r1,1            ;add page/bank starting at 0/0
        swpb    r1
        mov     r1,@4004h       ;map address >2000 to page/bank
        mov     r2,@2000h       ;write test value to >2000
        c       r2,@2000h       ;did it write correctly?
        jne     endpage
        swpb    r1
        clr     @2000h
        inc     r4              ;if yes then increment page counter 
        jmp     incpage         ;try next page
endpage sbz     1               ;disable mapper
        mov     r5,@2000h       ;restore original contents of >2000
        sbz     0               ;turn off sams card
        dec     r4
        mov     r4,*r10         ;return page counter
        bl      @pcodeon
        mov     @procret,r11
        b       *r11

 

[+Lee Stewart]

6 hours ago, Vorticon said:

Not sure I understand that. Wouldn't that comparison happen on the full word of the SAMS register? Edit: figured it out with @FALCOR4's document below.

 

@FALCOR4 confirmed that real hardware does not store the bank#. You should just ignore the LSB returned because it will be a repeat of the page#.

 

On the other hand, I checked Classic99 and it does return the bank# in the LSB. For consistency with hardware, it really should not do that. Oh, well.

 

...lee