[Pascal on the 99/4A]

Best holiday reading 😁

[GCHAR equivalent in UCSD Pascal?]

I worry about information fragmentation, but I'll leave it up to you. With such a limited number of Pascal users I feel it would be good to have all related knowledge in one place at the risk of unintentionally creating a rogue subforum 🏴‍☠️

[GCHAR equivalent in UCSD Pascal?]

@LarryFromBuffalo Here's GCHAR included in a compiled unit called GRAPHCHAR in the GRAPHICS library. As you can see below you don't need to know how the unit itself works, just how to use it. Just make sure that you have a file called USERLIB.TEXT on your default drive which contains the name of the library, GRAPHICS.CODE, before compiling your program.

 

{gchar test program}

program gchartest;
uses support,
{$u graphics.code} graphchar;

begin
 page(output);
 set_screen(2);
 gotoxy(15, 11);
 write('*');
 gotoxy(0, 2);
 write('character code: ',gchar(12, 16));
end. (* gchartest *)

 

 

PWORK.dsk

[GCHAR equivalent in UCSD Pascal?]

Got it. The trade off here then is having to run the SETLTYPE utility after each compilation to change the program type to M_9900. 

The trick about overflow is neat!

We should really move that conversation to the Pascal thread. Perhaps @OLD CS1 can do that?

[GCHAR equivalent in UCSD Pascal?]

4 hours ago, apersson850 said:

If you aren't going to use it too frequently you can write the whole thing in Pascal. Then you don't need the linking.

But otherwise you're correct.

How would you code it without assembly?

[GCHAR equivalent in UCSD Pascal?]

5 hours ago, apersson850 said:

Now I don't know what kind of game you are planning to convert, but if it's something that has some kind of action, then you should be aware of that if you put such a function as @Vorticon provided above in a pre-compiled unit, then you have a very convenient way of handling it. But you also have the absolutely slowest possible call command to use it. A global external inter-segment call is by far the most complex way there is to invoke a procedure.

So if you intend to call this gchar equivalent frequently I recommend you include it in your main program instead.

Good point, with the understanding that including it in the main program will require linking the external vsbr procedure after each compilation. 

[GCHAR equivalent in UCSD Pascal?]

7 hours ago, TheBF said:

Curiosity question.

 

Is there a way to access the screen management variables in the P-code system?

Where I am going is; is there any point is seeing what mode the system thinks it is in?  (Text, graphics 1, as the two most common ones) 

That way your gchar function could maybe know the line length so that 32 would be replaced by a variable that "knows" the current line length. 

 

Asking for a friend

 

 

Unlike the standard OS, the Pascal VDP registers can be read easily as they are located at >2810 in low memory, so it should be pretty simple to determine which screen mode the system is in by reading VR1 and then take that into account when calculating screen coordinates in the Screen Image Table. The question though is why would you need GCHAR in text mode?

[GCHAR equivalent in UCSD Pascal?]

Here's a test program that includes a GCHAR function. I know it seems a bit complicated but I'll make it into a precompiled UNIT which you can include in any program thar requires GCHAR and not worry about the details (at least for now as you get started in your UCSD Pascal journey). I made GCHAR's parameters exactly as TI BASIC expects them, but this could lead to potential confusion in UCSD Pascal where the screen is zero-based. Also GOTOXY has the parameters reversed compared to GCHAR. I'm thinking it would be better if GCHAR was made to take parameters like GOTOXY. 

 

{gchar test program}

program gchartest;
uses support;

type
 byte = 0..255;
 
 dual = record
   case boolean of
     true :(val :integer);
     false:(bytes : packed array[0..1] of byte);
 end; (* dual *)

procedure vsbr(vdpadr : integer; byteval : dual); external;

function gchar(y, x : integer) : integer;
{x : 1..32, y : 1..24}

var
 vdpadr : integer;
 byteval : dual;
 
begin
 vdpadr := 2048 + (((y - 1) * 32) + (x - 1));
 vsbr(vdpadr, byteval);
 gchar := byteval.bytes[1];
end; (* gchar *)

begin
 page(output);
 set_screen(2);
 gotoxy(15, 11);
 write('*');
 gotoxy(0, 2);
 write('character code: ',gchar(12, 16));
end. (* gchartest *)
 

 

PWORK.dsk

[GCHAR equivalent in UCSD Pascal?]

This is awesome! Welcome to the club! I suggest you post in the Pascal thread in this forum for continuity 

 

Regarding GCHAR, there isn't a direct equivalent in UCSD Pascal on the TI, but it should be pretty straightforward to code a small assembly procedure to achieve the same result. Let me look into it.

[Pascal on the 99/4A]

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.

[New SCSI card]

So what is the advantage of SCSI over the current IDE card as far as storage? 

[the TI99 spring festival is on for June 7,8,9 in Texas with poll of who might attend]

Would have loved to attend but sadly I'm on service that week... 

[TI Related -- Ebay / Heads Up Notice]

I think @Ksarul is working on a modern version on the HRD.

[What is the purpose of the PERMANENT parameter specification in a sub?]

2 hours ago, jschultzpedersen said:

But i like using subs for more complicated code sections because of its local variables. Besides, it adds structure to the code, and the overhead is small compared to using GOSUB-RETURN.

I rarely use GOSUB. Using SUB instead allows for clearer and modular code that is easier to maintain. 

[Pascal on the 99/4A]

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.

 

[Pascal on the 99/4A]

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

[Alex Kidd on Miracle Island - Playable Demo]

I was wondering how you managed to do that fantastic wavy background effect. So this game is strictly F18A dependent?

 

[Pascal on the 99/4A]

I applied my little scheme above to detect large capacity SAMS cards and it works.

Spoiler

 .func samsinit
;initialize the sams card and verify card is present
;returns 0 for absent, 1 if <= 1Mb and 2 if > 1 Mb 
;usage: statusint := 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
        cb      r1,@401eh       ;if match then card present
        jne     nocard
        li      r1,0102h
        mov     r1,@401eh
        c       r1,@401eh
        jeq     lgcard
        li      r2,1
        jmp     endinit
lgcard  li      r2,2
        jmp     endinit
nocard  clr     r2
endinit li      r1,0f00h
        mov     r1,@401eh
        mov     r2,*r10         ;place card indicator on return stack
        sbz     0               ;turn sams card off
        bl      @pcodeon
        mov     @procret,r11
        b       *r11

 

And here it is on real hardware with my 1mb card:

[Pascal on the 99/4A]

Well one way that would universally work would be to write a discordant value, say >0102 to the registers, then on a first pass test the MSB. If it passes, then test for the whole word. If it passes again then we have a card larger than 1 meg, otherwise it's smaller or equal. 

        LI  R1,>0102
        MOV R1,@>401E
        CB  R1,@>401E
        JNE NOCARD
        C   R1,@>401E
        JNE SMCARD
        JMP LGCARD

 

[Pascal on the 99/4A]

I got the keyboard scanning routine to work in bitmap mode following @apersson850's method of relocating the keyboard buffers, but I also needed to restore the Pascal VR1 in low memory prior to exiting the routine as it seemed that the KSCAN routine was affecting it somehow. Otherwise I would get a garbage screen from an incorrectly set VR1. I don't have a clear explanation for this because the scanning routine copies the Pascal VRs to the RAMPAD and KSCAN is supposed to only use that area and should not affect the Pascal VR's. 

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... Still waiting for that wig Anders...

[Pascal on the 99/4A]

1 hour ago, Tursi said:

Classic99 is perfectly accurate for the 32MB card it's emulating, thank you.  If it didn't return both bytes you wouldn't be able to tell what page was mapped.

 

Now whether that 32MB card will ever be released I don't know.

True, but it's still problematic if one wants to support current existing hardware. 

There used to be an option to choose the size of the SAMS in Classic99, but it's now grayed out. 

[Pascal on the 99/4A]

40 minutes ago, TheBF said:

And in fact the hardware on the 1M card does the same as we can see in the image.

Here I turn on the card and then dump the registers at >4000.

 

 

 

 

Not on my 1meg card. The detection failed just as in MAME with my original code. Are there different versions of the card?

[Pascal on the 99/4A]

3 hours ago, gferluga said:

Yes... ./mame ti99_4a -window -nomouse -skip_gameinfo -autoframeskip -natural -ioport peb  -ioport:peb:slot2 samsmem -ioport:peb:slot8 bwg -ioport:peb:slot8:bwg:2 525dd -ioport:peb:slot3 pcode -flop1 "software/ti99_pcode/SAMSUTIL.dsk"

 

It's actually a bug in my code. When reading the SAMS registers, a real SAMS card will only return the MSB (the page #) but not the LSB, whereas Classic 99 will return both as a word instead of a byte. MAME accurately emulates the SAMS behavior, including how the registers are read, which is why the program failed to detect the card. Same behavior on real hardware.

Attached is a corrected version (replacing a C instruction by a CB one...) which fixes the issue. Sorry about that.

 

SAMSUTIL.dsk

[Pascal on the 99/4A]

So here's my question about backing up the VDP RAM. The lower 4K will hold the standard character definitions which will get overwritten by a bitmap image. I did notice that even without manually restoring that area, somehow the definitions get restored when I return from bitmap. How is that possible?

I knew about the keyboard buffer, but not the layout area. Is that the area which hold the key information you mention (120 bytes)?

Also what about the Pascal VDP registers? You update them in your code after changing the standard VDP registers and I'm not too clear as to why.

It's really important for me to understand fully how to do the bitmap switch back and forth while preserving as much function as possible, hence why I am peppering you with questions. You're the only person alive as far as I know with such in-depth knowledge of the system and I'm trying to leech as much of that priceless info as possible before it's too late! 😁

I also heard that you will be writing a series of articles on the p-system for the Chicago User Group newsletter. I'm looking forward to reading those.

[Pascal on the 99/4A]

1 hour ago, apersson850 said:

Why save the VDP memory prior to doing bitmap graphics? There's nothing to save, since that's the whole reason for why you can reserve the space.

It seemed like the safe thing to do as I frankly was not sure if there was something worth preserving. It was painless enough to do  

One question: Do I need to update the Pascal VDP registers vr1-7 in low memory when I switch to bitmap before calling the keyboard scan routine?

Also your code mentions a keyboard layout area. What is that?