Pascal on the 99/4A

[+Vorticon]

Here's the (hopefully) final version of IMAGEDEMO which has an updated SAMS access utility which takes into account card size during initialization. Also it fixes the issue of the screen not returning to text mode after the bitmap mode has ended where I essentially save all the default values of the Pascal VDP registers (1-7) just prior to entering bitmap mode and restore them at the time of exit from bitmap mode. Setting just VR1 to text mode did not do it. Interestingly, in Classic 99, this was not needed and I thought that the OS simply reloaded the default values. That did not appear to be the case on real hardware where I got dropped into Graphics mode 1 along with some weird scrolling issues. Note to self: always test on real hardware before releasing anything developed under emulation

SAMSUTIL.dsk

[apersson850]

I've not published my return from bitmap yet in this thread. I can do so. Thus you can compare. But the entry into bitmap implies changing every VDP register, I think, so it makes sense they all need to be restored.

[apersson850]

On 4/3/2024 at 6:16 PM, Vorticon said:

More often than not the p-system feels like it's finely balanced on the tip of a needle, and any unsanctioned activity like bitmap access will upset that balance and lead to unexpected behavior...

I'd rather say that the more you learn about the PME's details, the better you'll find out that it's actually a pretty robust system, well modularized and where virtually all critical code items are referenced by tables in RAM. This makes it possible to exchange parts of the system as needed. Just plug in the new code somewhere and adjust a pointer, in spite of the original code being in ROM.

Likewise, the p-system running on top of the PME is almost completely hosted in the multi-segment file OS:SYSTEM.PASCAL. That file can, segment by segment, be replaced by a new segment with the same name residing on the system disk. At the cost of using more RAM (the PME can execute the segments in OS:SYSTEM.PASCAL directly from the GROM chips it's stored in) you can change whatever you like in the part of the operating system, which is mainly written in Pascal. This is of course not really feasible without access to the source code, but if you do have that knowledge it's technically easy.

Looking at how short the code to enter and exit bitmap mode, a mode not at all planned for in the p-system designers, really is, it's pretty amazing that you can make such a significant change in the memory layout and still return to Pascal level with the bitmap mode active. We aren't talking about something that will live only as long as your assembly program is running. You can continue on Pascal level and do virtually everything except using the normal screen related IO routines, which is very reasonable.

Edited April 5 by apersson850

[+Vorticon]

5 hours ago, apersson850 said:

You can make such a significant change in the memory layout and still return to Pascal level with the bitmap mode active.

Indeed. It does open up a lot of possibilities. Something similar I've done is when I created the graphics extensions on the Coleco Adam computer under CP/M using Turbo Pascal 3. I wrote a complete game in TP3 running entirely in bitmap mode, something usually unthinkable for the CP/M environment. The Adam had the same VDP as the TI.

 

[apersson850]

Here is what unit turtlegraphics uses to come back from bitmap to standard text mode again.

The addresses used where defined in my post about how to enter bitmap.

 

; procedure nobitmap(var buffer: sometype, 1000 bytes large);
;

         .PROC NOBITMAP,1
         .REF VMBR,VMBW,VSBW,VWTR,VFILL
         
         LI   R0,KEYBUF2        ;Restore keyboard buffer
         MOV  *SP+,R1   ;Buffer
         LI   R2,32
         BLWP @VMBR
         LI   R0,KEYBUF1
         BLWP @VMBW
         MOV  R0,@KEYBUFPNT
         
         LI   R0,LAYOUT2        ;Restore keyboard layout area
         LI   R2,120
         BLWP @VMBR
         LI   R0,LAYOUT1
         BLWP @VMBW
         MOV  R0,@LAYOUTPNT
         
         LI   R0,81A0H  ;Disable screen during manipulations
         BLWP @VWTR
         CLR  R0
         BLWP @VWTR     ;No bit-map
         LI   R0,8202H
         BLWP @VWTR
         MOV  R0,@REGCOPY+2     ;PME copies of VDP regs
         LI   R0,832FH
         BLWP @VWTR
         MOV  R0,@REGCOPY+4
         LI   R0,8400H
         BLWP @VWTR
         MOV  R0,@REGCOPY+6
         LI   R0,8518H
         BLWP @VWTR
         MOV  R0,@REGCOPY+8
         LI   R0,8717H
         BLWP @VWTR
         MOV  R0,@REGCOPY+12
         
         LI   R0,SAVE2B ;Restore character definitions
         LI   R2,24     ;chr(128)..chr(255) are blanked
         BLWP @VMBR
         LI   R0,PATTERN1
         BLWP @VMBW
         LI   R0,SAVE2A
         LI   R2,1000
         BLWP @VMBR
         LI   R0,PATTERN1+24
         BLWP @VMBW
         LI   R0,PATTERN1+1024
         CLR  R1        ;Blank unsaved definitions
         MOV  R0,R1
         BLWP @VFILL
         
         LI   R0,COLTAB1        ;Set color to black/transp.
         LI   R1,1000H
         LI   R2,32
         BLWP @VFILL
         
         LI   R0,SAB1   ;Disable first sprite
         LI   R1,0D000H
         BLWP @VSBW
         
         MOV  R11,R7
         BL   @47D2H    ;Put back previous text on screen
         LI   R0,40
         MOV  R0,@2CC6H ;Set screen width for text mode
         
         LI   R0,81F0H  ;Set VDP to text mode
         BLWP @VWTR
         MOV  R0,@REGCOPY
         B    *R7
         

 

[apersson850]

Thinking a bit further about the procedure to enter and leave bitmap mode, I can see that there is one thing which I do not save, and that is character definitions in the range 128..255. The reason for that is of course that I would have had to save them in a file, as there's no room without some kind of memory expansion. My decision was that it was not worth it, since if you actually do use these character definitons, then it's probably because you want to do some minor graphic thing, in which case you don't use bitmap. If you do use bitmap, on the other hand, it's not too likely that you also in the same program want to use special definitions of characters 128..255. Since I have no definitions for them I don't print them on the screen with the wchar function unit turtlegraphics supports anyway.

 

The next step in a possible further development of unit turtlegraphics is probably to allow a copy/paste functionality of the screen. I envision that to work like this:

1. Define a viewport on the screen.
2. Copy the graphics inside the viewport and store in a file (because that's the only way if it's the full screen).
3. Define a new viewport.
4. Paste the copied file into that viewport.

Steps 3-4 can of course be repeated to create multiple copies of the graphics on the screen.

If the viewport is defined to cover the whole screen you'll effectively create screen images, which you can restore by reading in the files.

Pasting a graphic object can be done in several ways, just like when drawing lines. Just overwrite what's there is simplest, but you can also imagine adding it to the existing graphics, subtract it and so on. The current functions in unit turtlegraphics can also handle just the image or the image and color as a unit.

 

Some systems do allow you do manipulate graphics as a separate non-visible object, then copy that to the screen when it's ready. Doable on the 99/4A too, but hardly in a general manner, since the largest images will be troublesome to have in memory together with the bitmap mode and a meaningful software handling them, all at the same time.

 

Anyway, storing these graphic objects as files has the advantage that it works on all systems but can also work almost at RAM speed if there is a RAMdisk defined in the system. If you want to make a program that rolls through a number of screens you can predefine those as files on a disk, copy these files to the RAMdisk when starting the program and then run them from the RAMdisk to reduce delays.

Edited April 11 by apersson850

[+Vorticon]

11 hours ago, apersson850 said:

Some systems do allow you do manipulate graphics as a separate non-visible object, then copy that to the screen when it's ready. Doable on the 99/4A too, but hardly in a general manner, since the largest images will be troublesome to have in memory together with the bitmap mode and a meaningful software handling them, all at the same time.

Actually with the SAMS this is easily doable as you can have a bitmap image on screen and another (or several) in SAMS which you can manipulate at will as long as you know their page and offset locations then transfer them to the VDP as needed. The latter is very quick as demonstrated in my image demo where I actually had to introduce a delay between images in order to make them more viewable. This scheme would be most suited for a large game map which can be displayed through a screen-full viewport and modified off-screen at will.

[apersson850]

Exactly. Which is why I wrote hardly in a general manner. It doesn't work well on a standard machine, since the memory is too small.

[+Vorticon]

Best holiday reading 😁

[+TheBF]

Very naughty photo.  Your nerds are showing.  

[+FarmerPotato]

I found a 2-page document from TI that recommends using the UCSD PASCAL package to
develop assembly language programs for the TI-99/4.  Must pre-date the 4A and the Editor/Assembler. 

 

Does anyone remember seeing it before?

 

Posted in this thread:

 

 

[+Vorticon]

Saw this posted in the BASIC group of FB programmed in Tektronix 4051 Basic and it looked like turtle graphics, so I thought I would try @apersson850's turtle unit and see if I can reproduce it.

Here's the original image:

 

Here's the UCSD Pascal code using the turtlegrahics unit:

program spiral;
uses {$u turtleunit.code} turtlegraphics;

var
 a, w, r : real;
 
begin
 page(output);
 grafmode;
 pen_mode(none);
 a := 0;
 repeat
  w := (a / 240) * cos(3.14159 * (a * 5.5) / 180);
  turnto(round(a));
  r := 3 + a / 22;
  moveto(127, 99);
  move(round(r - w / 2));
  pen_mode(draw);
  move(round((w * 1.5)));
  pen_mode(none);
  a := a + 4;
 until a > 1920;
 repeat
 until false;
end.
 

 

Not bad, considering the significant resolution limitation on the TI

 

turtle.dsk PWORK.dsk

[+Vorticon]

15 hours ago, FarmerPotato said:

I found a 2-page document from TI that recommends using the UCSD PASCAL package to
develop assembly language programs for the TI-99/4.  Must pre-date the 4A and the Editor/Assembler. 

 

Does anyone remember seeing it before?

 

Posted in this thread:

 

 

Never seen this before. 

A set of macros is provided during assembly to 
        facilitate accessing specific TI-99/4 hardware features such as
        the Video Display Processor, or the sound chip.  An I/0 utility 
        is available which may be linked with an assembly routine to
        provide access to peripherals such as disk drive, RS-232, etc. 
        Although the disk format of the PASCAL system is different from
        that used by Extended BASIC, a utility is provided to convert a 
        PASCAL object file to the format required by Extended BASIC.

These extensions would have been quite useful...

[apersson850]

Looks like it's some preferred way at TI (if you don't have a TI 990 mini computer) to write assembly language subroutines before the Editor/Assembler package was introduced.

[apersson850]

On 4/21/2024 at 3:24 AM, Vorticon said:

Not bad, considering the significant resolution limitation on the TI

The best thing I see with it is that you more or less took the original code, changed the syntax from BASIC to Pascal and it ran!

[+Vorticon]

How do you change screen color with the turtlegraphics package?

[senior_falcon]

Not trying to hijack the thread, but I couldn't resist seeing this in The Missing Link. This is in CPU overdrive on my geriatric Dell computer. It takes about 2.5 minutes at normal speed.

5 CALL LINK("COLOR",3,2):: CALL SCREEN(2)
10 FOR A=0 TO 1440 STEP 3
20 CALL LINK("PUTPEN",96,120,A)
23 W=(A/180)*COS(A*5.5*180/PI)
25 R=9+A/17
26 CALL LINK("PU"):: CALL LINK("FWD",R-W)
27 CALL LINK("PD"):: CALL LINK("FWD",W*2)
30 NEXT A
40 GOTO 40

 

Edited April 23 by senior_falcon

[+Vorticon]

1 hour ago, senior_falcon said:

Not trying to hijack the thread, but I couldn't resist seeing this in The Missing Link. This is in CPU overdrive on my geriatric Dell computer. It takes about 2.5 minutes at normal speed.

5 CALL LINK("COLOR",3,2):: CALL SCREEN(2)
10 FOR A=0 TO 1440 STEP 3
20 CALL LINK("PUTPEN",96,120,A)
23 W=(A/180)*COS(A*5.5*180/PI)
25 R=9+A/17
26 CALL LINK("PU"):: CALL LINK("FWD",R-W)
27 CALL LINK("PD"):: CALL LINK("FWD",W*2)
30 NEXT A
40 GOTO 40

 

Your values result in a nicer spiral than the ones I used. Shouldn't however line 23 be W=(A/180)*COS(A*5.5*PI/180) in order to convert the A * 5.5 to radians? I like the PUTPEN function which relocates the turtle and sets the angle all in one shot. Saves an instruction.

I stole your values  Takes about 1:24 to complete, so close to 50% faster than TML.

program spiral;
uses {$u turtleunit.code} turtlegraphics;

var
 a, w, r : real;
 
begin
 page(output);
 grafmode;
 pen_mode(none);
 a := 0;
 repeat
  w := (a / 180) * cos(a * 5.5 * 3.14159 / 180);
  turnto(round(a));
  r := 9 + a / 17;
  moveto(127, 99);
  move(round(r - w));
  pen_mode(draw);
  move(round((w * 2)));
  pen_mode(none);
  a := a + 3;
 until a > 1440;
 repeat
 until false;
end.
 

 

[senior_falcon]

35 minutes ago, Vorticon said:

 Shouldn't however line 23 be W=(A/180)*COS(A*5.5*PI/180) in order to convert the A * 5.5 to radians?

I think that is right. I must have gone dyslexic for a moment. Now I am totally baffled as to why my way would work at all!!!

I am tempted to compile this, but it would have to be converted to integer math. Maybe I will get around to it.l

 

[apersson850]

21 hours ago, Vorticon said:

How do you change screen color with the turtlegraphics package?

The turtlegraphics unit is in a "proof of concept" phase, and has been like that for 35+ years. There are some functions in the different write modes that don't work and some other stuff that's not implemented.

But if you include uses support and then set the screen color the normal way, I think that's compatible with the turtlegraphics unit too, since it only changes a VDP register.

 

Update: I checked in one of my test programs. It does uses support and then starts with this sequence.

 (* Gives a darker background *)
 set_scr_color(ord(black),ord(red2));
 grafmode;

The color change is done prior to entering bitmap mode. Not sure what happens if you do it with bitmap mode active. But the default background color for screen items is transparent, so the backdrop should be visible.

Edited April 23 by apersson850

[apersson850]

6 hours ago, Vorticon said:

I like the PUTPEN function which relocates the turtle and sets the angle all in one shot. Saves an instruction.

That's correct. I tried to stay as close to the implementation of turtlegraphics in Apple Pascal for Apple ][ as I could, to make it as easy as possible to run programs originally designed for that computer. It wasn't possible to match it completely, since the Apple has a different way of handling colors than the TI. Not the same video processor.

Edited April 23 by apersson850

[+Vorticon]

8 hours ago, senior_falcon said:

I think that is right. I must have gone dyslexic for a moment. Now I am totally baffled as to why my way would work at all!!!

When I initially tried it, the computer crashed until I realized the radians conversion was incorrect. So odd you're getting a usable output...

[apersson850]

21 minutes ago, Vorticon said:

When I initially tried it, the computer crashed until I realized the radians conversion was incorrect. So odd you're getting a usable output...

He probably has some AI-inspired BASIC interpreter according to the "Do what I mean, not what I say" principle.

 

To be (slightly) serious, cosine is a periodic function, so with some luck you get something similar, regardless of what kind of data you put in.

Edited April 23 by apersson850

[senior_falcon]

2 hours ago, apersson850 said:

He probably has some AI-inspired BASIC interpreter according to the "Do what I mean, not what I say" principle.

If you came up with a programming language like that, you would be a VERY wealthy man!

[+TheBF]

15 minutes ago, senior_falcon said:

If you came up with a programming language like that, you would be a VERY wealthy man!

 

"Write the game snake in Python"  🤯