First Spear Posted June 5, 2020 Share Posted June 5, 2020 Can anyone show a quick example of how to XOR an item in GRAM so it would “invert” on the display? Thanks. Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 5, 2020 Share Posted June 5, 2020 If you mean just swapping all the 1s for 0s and vice versa, the following assembly snippet would do that from within an interrupt context (assuming R4 already points to the GRAM card): ; Invert GRAM card @R4. Trashes R0, R5 MOVR R4, R5 ; 6 Copy input ptr to output ptr REPEAT 4 SDBD ; 4 \_ Get 2 rows of GRAM MVI@ R4, R0 ; 10 / COMR R0 ; 6 Invert MVO@ R0, R5 ; 9 \ SWAP R0 ; 6 |- Write both rows back out MVO@ R0, R5 ; 9 / ENDR ;---- ; 44 ;* 4 ;---- ; 176 ;+ 6 (from above) ;---- ; 182 cycles If you only have a small number of graphics tiles you need to invert, it may actually be cheaper to store them already inverted in ROM and just load the inverted images. Also, if you're using IntyBASIC for this, that may be the preferred method generally. Does IntyBASIC even offer a facility for reading GRAM? Sure, there's PEEK, but you also have to sync with the vertical retrace. And WAIT : PEEK might not be the worst thing you can do, but I don't think it's a great idea. Quote Link to comment Share on other sites More sharing options...
First Spear Posted June 5, 2020 Author Share Posted June 5, 2020 1 minute ago, intvnut said: If you mean just swapping all the 1s for 0s and vice versa, the following assembly snippet would do that from within an interrupt context [snip] Yes, I was looking for a cheap way to invert some images, but since I am using a lot of ROM anyway for images, might as well just use a little bit more. thanks. Quote Link to comment Share on other sites More sharing options...
carlsson Posted June 5, 2020 Share Posted June 5, 2020 I suppose it isn't as easy as using FG as BG and vice versa, depending on which graphics mode you're working in? Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted June 6, 2020 Share Posted June 6, 2020 On 6/4/2020 at 5:51 PM, intvnut said: If you mean just swapping all the 1s for 0s and vice versa, the following assembly snippet would do that from within an interrupt context (assuming R4 already points to the GRAM card): ; Invert GRAM card @R4. Trashes R0, R5 MOVR R4, R5 ; 6 Copy input ptr to output ptr REPEAT 4 SDBD ; 4 \_ Get 2 rows of GRAM MVI@ R4, R0 ; 10 / COMR R0 ; 6 Invert MVO@ R0, R5 ; 9 \ SWAP R0 ; 6 |- Write both rows back out MVO@ R0, R5 ; 9 / ENDR ;---- ; 44 ;* 4 ;---- ; 176 ;+ 6 (from above) ;---- ; 182 cycles If you only have a small number of graphics tiles you need to invert, it may actually be cheaper to store them already inverted in ROM and just load the inverted images. Also, if you're using IntyBASIC for this, that may be the preferred method generally. Does IntyBASIC even offer a facility for reading GRAM? Sure, there's PEEK, but you also have to sync with the vertical retrace. And WAIT : PEEK might not be the worst thing you can do, but I don't think it's a great idea. Just curious, could the last 3 intructions off MVO@ / SWAP / MVO@ be replaced with SDBD / MVO@? I might not completely know what I am talking about. Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 6, 2020 Share Posted June 6, 2020 2 hours ago, Lathe26 said: Just curious, could the last 3 intructions off MVO@ / SWAP / MVO@ be replaced with SDBD / MVO@? I might not completely know what I am talking about. I wish there was an SDBD MVO@, but there is no such thing. Very early versions of jzIntv supported it, but no real Intellivision does, sadly. It seems like such an obvious thing to have, but it's not there. This change went in before jzintv-009 was released a few months later, on my birthday. In fact, I committed this change 21 years ago tomorrow. Yikes. In a few more years, I will have been working on this for half my life. Double-yikes. revision 1.12 date: 1999-06-06 19:13:36 -0500; author: im14u2c; state: Exp; lines: +6 -2; -- Apparently, SDBD is not allowed w/ MVO. For now, I've modified the MVO@ instruction to issue a warning whenever this pairing is encountered. It'll act as though the SDBD were not there, though. I've also changed the "Intro.." doc accordingly. -- Added a rudimentary breakpoint command to the debugger. Still more work to do there. ... --- op_exec.c 6 Jun 1999 04:30:26 -0000 1.11 +++ op_exec.c 7 Jun 1999 00:13:36 -0000 1.12 @@ -4,7 +4,7 @@ * * Author: J. Zbiciak * - * $Id: op_exec.c,v 1.11 1999-06-06 04:30:26 im14u2c Exp $ + * $Id: op_exec.c,v 1.12 1999-06-07 00:13:36 im14u2c Exp $ * * ============================================================================ * fn_invalid -- Executed when a decoder failure happens @@ -29,7 +29,7 @@ #include "op_decode.h" #include "op_exec.h" -static const UNUSED char rcs_id[]="$Id: op_exec.c,v 1.11 1999-06-06 04:30:26 im14u2c Exp $"; +static const UNUSED char rcs_id[]="$Id: op_exec.c,v 1.12 1999-06-07 00:13:36 im14u2c Exp $"; int fn_invalid (const instr_t *instr, cp1600_t *cp1600) @@ -457,8 +457,12 @@ if (cp1600->D) { + fprintf(stderr,"WARNING: MVO@ w/ SDBD prefix @ %.4X\n", instr->address); + /* CP1600_WR(cp1600, instr->address+1, (r0 & 0xFF)); CP1600_WR(cp1600, instr->address+2, (r0 >> 8)); + */ + CP1600_WR(cp1600, instr->address+1, r0); } else { CP1600_WR(cp1600, instr->address+1, r0); (Note: diff times are in TZ -0000, as compared to the log message in -0500.) 2 Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 6, 2020 Share Posted June 6, 2020 On 6/4/2020 at 5:54 PM, First Spear said: Yes, I was looking for a cheap way to invert some images, but since I am using a lot of ROM anyway for images, might as well just use a little bit more. For what it's worth, an extra tile is only 4 words of ROM. So, unless you're actually inverting a ton of tiles, it's not terribly expensive. And as carlsson pointed out, depending on the graphics mode you could just swap FG/BG. But that's often harder than it seems. In the level select in Space Patrol, I had to invert some of the bitmaps to make the screen look the same as it does in the main game. (!) That's because one uses FGBG mode and the other uses CSTK. FGBG wouldn't let me select the foreground colors I needed, so I inverted the graphics so the color scheme would work. 1 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.