Vorticon

Best holiday reading 😁

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 🏴‍☠️

@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

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?

How would you code it without assembly?

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

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?

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

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.

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.

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

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

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

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

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.

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

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

I applied my little scheme above to detect large capacity SAMS cards and it works. Classic99 QI399.065 2024-04-04 05-18-45.mp4 And here it is on real hardware with my 1mb card:

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

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...

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.

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

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

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.

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?