+Vorticon Posted April 4 Share Posted April 4 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 4 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 5 Author Share Posted April 5 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. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 5 Author Share Posted April 5 (edited) 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 7 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 5 Share Posted April 5 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. 8 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 6 Author Share Posted April 6 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 1 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 11 Author Share Posted April 11 (edited) 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: Define a viewport on the screen. Copy the graphics inside the viewport and store in a file (because that's the only way if it's the full screen). Define a new viewport. 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 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 11 Share Posted April 11 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. 3 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 12 Author Share Posted April 12 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. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 18 Share Posted April 18 Best holiday reading 😁 1 5 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 18 Share Posted April 18 Very naughty photo. Your nerds are showing. 4 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted April 20 Share Posted April 20 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: 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 21 Share Posted April 21 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 Classic99 QI399.065 2024-04-20 20-12-33.mp4 turtle.dsk PWORK.dsk 11 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 21 Share Posted April 21 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... 3 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 22 Author Share Posted April 22 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. 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 22 Author Share Posted April 22 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! Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 22 Share Posted April 22 How do you change screen color with the turtlegraphics package? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 23 Share Posted April 23 (edited) 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 5 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 23 Share Posted April 23 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. Classic99 QI399.065 2024-04-22 21-39-41.mp4 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 23 Share Posted April 23 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 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 23 Author Share Posted April 23 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 23 Author Share Posted April 23 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 23 Share Posted April 23 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... Quote Link to comment Share on other sites More sharing options...
apersson850 Posted April 23 Author Share Posted April 23 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 23 Share Posted April 23 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! 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 23 Share Posted April 23 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" 🤯 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.