Jump to content

Vorticon

+AtariAge Subscriber
  • Posts

    5,908
  • Joined

  • Last visited

  • Days Won

    5

Vorticon last won the day on March 23 2023

Vorticon had the most liked content!

4 Followers

About Vorticon

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    USA
  • Interests
    Retrocomputing, electronics, astronomy, tabletop wargaming, tennis

Recent Profile Visitors

18,659 profile views

Vorticon's Achievements

Quadrunner

Quadrunner (9/9)

5.3k

Reputation

  1. 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 🏴‍☠️
  2. @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
  3. 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?
  4. Good point, with the understanding that including it in the main program will require linking the external vsbr procedure after each compilation.
  5. 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?
  6. 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
  7. 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.
  8. 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.
  9. So what is the advantage of SCSI over the current IDE card as far as storage?
  10. I think @Ksarul is working on a modern version on the HRD.
  11. I rarely use GOSUB. Using SUB instead allows for clearer and modular code that is easier to maintain.
  12. 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.
×
×
  • Create New...