Jump to content
IGNORED

IntyBASIC XOR GRAM Item?


Recommended Posts

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

 

image.thumb.png.ff02510358248c88d1c2dd5d0113e88a.png

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...