Re: Scrolltext

new topic     » goto parent     » topic index » view thread      » older message » newer message

--------------685F0D9EA9FBD73982DC316C



Tor Bernhard Gausen wrote:

> All I wanted to do was to make a txt viewer in mode 18 which
> would allow people to read text files and scroll up and down
> smoothly and with some sort of accelerating speed control.
>
> Sounds very simple, right?
>
> Well, I ran into three problems; a trivial problem,
> a depressing problem and a mysterious problem.
>
> The trivial problem: I don't know how the mode18 bit planes
> are organized (where in memory, and which bit planes are
> most and least significant). Could anyone please help me,
> and/or direct me to a place on the web where I can find
> such information without bothering the EU list?
>
> The depressing problem is that my routine is incredibly slow.
> I'm clearly doing something REALLY wrong, but what?
> The program is slow in mode 19, how slow would it not
> be in mode 18? A smoother, faster, full screen 320x200
> mode scroller was programmed on the 1MHz C64 by the
> 1001 Crew 15 years ago... It should be possible to do
> something at least as good on my P233, even in an
> interpreted language.
>
> The mysterious problem is that at one point on the
> screen, it seems like the raster is skipping one line ...!?!
> Consequently the text seems to be 'sucked' through
> a narrow horizontal portion of the screen.
> Is there something wrong with CHARN's wait_retrace
> routine? Or could the problem be my cheap video card ?
> With my card ("expert color s3" or something) I can't
> use modes 261 etc, but I can use modes 256 and 257.
> This means it's SVGA, right? Not right ? smile
> Well, here's an example of what I'm trying to do:
>
>
> ---------------------------------------------------------------------------------
> include graphics.e
> include machine.e
>
> global constant wait_retrace = allocate(20)
> -- thanks to CHARN for this routine
> poke(wait_retrace, {
>                 #50,            -- PUSH EAX
>                 #52,            -- PUSH EDX
>                 #BA,#DA,3,0,0,  -- MOV EDX, 0x03DA
>                 #EC,            -- IN AL, DX
>                 #24,#08,        -- AND AL, 0x08
>                 #75,#FB,        -- JNZ -5
>                 #EC,            -- IN AL, DX
>                 #24,#08,        -- AND AL, 0x08
>                 #74,#FB,        -- JZ -5
>                 #5A,            -- POP EDX
>                 #58,            -- POP EAX
>                 #C3 } )         -- RET
>
> integer char, key, speed, screen_mem, mem_size
> object junk, text
>
> screen_mem=#A0000
> mem_size= 320 * 200
> speed=1
> char=0
> text = " ***    Man, this is slooowww...    ***"
>
> junk=graphics_mode(19)
>
> while char < length(text) do
>     char +=1 if char=length(text) then char=1 end if
>     key=get_key() if key=27 then abort(1) end if
>     if key='+' and speed < 4 then speed *= 2 end if
>     if key='-' and speed > 1 then speed /= 2 end if
>     if key=' ' then
>         key=-1
>         while key !=' ' do
>             key=get_key()
>         end while
>     end if
>     position(25,1) puts (1,text)
>         for m=1  to 8/speed do
>             call (wait_retrace)
>             mem_copy (screen_mem, screen_mem+320*speed,
> mem_size)
>         end for
> end while
>
> -----------------------------------------------------------------------------------------
>
> You can regulate speed with +/- and freeze with space.
>
> The text does not glide smoothly the way I wanted it to.
> Instead it seems to 'shake' so that it all becomes a blur.
> This gets worse with higher speeds, but is also visible
> at the slowest speed. A similar routine with a horizontal
> scroller is very nice and smooth, but is just as slow.
>
> Would things go faster with a virtual screen?
> How do I write text to a virtual screen, (not to mention
> drawing lines, circles etc. ?)
>
> And if the answer is: "there's no easy way, you have to
> copy characters to the virtual screen one by one (and
> code your own graphics routines (yeah, right!))" then:
> Where in memory can I find the standard character set?
> (Another trivial question I guess).
>
> Thanks,
>
> Tor Bernhard Gausen

Well, I tested out that program, and I found that it goes faster, and the text
doesn't shake,
when you take out the part that calls the vertical retrace routine.  As far as
finding the
standard character set, that is located at the real-mode address F000:FA6E
(hex), which in
Euphoria, would be #FFA6E.  The only thing that sucks, is that location only
holds
information for ASCII characters 0 thru 127.  I know that there is information
for chars 128
thru 255, but I forgot the address.  I do know, however, that it is located at
some real-mode
interrupt vector.  I just forgot which one.

The format for the characters at those locations, though, goes like this... 
Each character,
is 8 bytes long, so, to find the location of a specific character, you would use
the formula
#FFA6E + (character * 8).  Now, each of the 8 bits for every byte contains the
information
for how the character is to be drawn.  Bit 7 is the leftmost pixel, and bit 0 is
the
rightmost pixel.  When a bit is set (1), that means the pixel is set for the
character.  When
it's not, well, it's not, so, you can draw your own background color there, or
not mess with
it at all.

Attached, I have a file containing a routine (2,604 bytes) that helps explain
this.  (It only
works in graphics mode 19.  It can be changed to make calls to pixel(), so it
can work in all
graphics modes.)

--------------685F0D9EA9FBD73982DC316C
 name="abtext.e"
Content-Disposition: inline;
 filename="abtext.e"

--
-- Character displaying example
--
-- Euphoria 2.1 syntax is used
--
-- Created by The AfterBeat
-- Email: afterbeat at hotmail.com or afterbeat at geocities.com
-- ICQ #: 10166297
--

-- Constants --
constant
   VideoMem = #A0000,
   RomCharSet = #FFA6E,
   CharWidth = 8,
   CharHeight = 8,
   StepBackVal = 320 * CharHeight

--
-- draw_text
--
-- text = The text to be drawn
-- fc = The foreground color
-- bc = The background color (use -1 for transparent text)
-- xy = A 2-element sequence for the position {x, y}
--
global procedure draw_text(object text, integer fc, integer bc, sequence xy)
   -- Displays text on the screen (graphics mode 19 is assumed!) --
   atom scrn_addr, char_addr
   integer bitmask

   -- Get the address of the starting location --
   scrn_addr = VideoMem + (xy[2] * 320) + xy[1]

   -- Convert the text to a sequence --
   if not sequence(text) then
      text = {text}
   end if

   -- Get the address of the character --
   for count = 1 to length(text) do

      -- Get the address of the character --
      char_addr = RomCharSet + (text[count] * 8)

      -- Display the character, one row at a time --
      for height = 1 to CharHeight do

         -- Reset the bitmask (to bit 7, value = #80) --
         bitmask = #80

         -- Display a row of the character --
         for width = 1 to CharWidth do

            -- See if the bit is set --
            if and_bits(peek(char_addr), bitmask) then
               poke(scrn_addr + width, fc)

            -- If not, see if transparency is enabled --
            elsif bc != -1 then

-- Okay, that's not enabled either.  Set the pixel to the
               background color. --
               poke(scrn_addr + width, bc)
            end if

            -- Shift the bitmask 1 bit to the right --
            bitmask = floor(bitmask / 2)
         end for

         -- Update the pointers --
         scrn_addr += 320       -- Move to the next row of the screen --
         char_addr += 1         -- Move to the next row of the character --
      end for

      --
      -- Move back to the original y position of the screen,
      -- and update the x position.
      --
      -- So far, this is the fastest way to restore and
      -- update the position I know.  Later I'll try to
      -- find a faster way to do this.  It was written
      -- this way because this routine handles both strings
      -- of text and single characters.
      --
      scrn_addr = (scrn_addr - StepBackVal) + CharWidth
   end for
end procedure

--------------685F0D9EA9FBD73982DC316C--

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu