I found out recently that egroups are planning on altering their email
advertising to move the messages to the top of their mails, so I thought
I'd let the list know

Incidentially, they offer a no adverts option for $5us /month....

--
    _  Richard Munn  RAMTronics Software
   //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

On 14 Aug 00, rednuht@... (rednuht) wrote:

> [THIS POSTING HAS NO LINES EXCEDING 70 CHARS]

Thanks. :)

> My Space Invaders has been going well and I finally thought I was
> getting the hang of this, but no.

Although this may sound a bit mean, I do hope that the rest of your "Space
Invaders" code doesn't look like the piece you e-mailed... :)

> My function does not work (displays first 192 bytes(screen worth))
> If the six 'INC TRL' lines are uncommented then it does scroll the first $FF
> bytes. So can anyone tell me why the LD TRL, ADD 6, ST TRL does not...
> Load the value of TRL into the ACC, Add six to the ACC and then
> store the ACC back into TRL?
> Also the TRH never gets to its original value plus 3, any idea?
> I know this will not get me quite to the end of my data but its a start.

>       LD   TRL
>       ADD  6               ; bytes per line

6 without an # refers to a memory address...

>       ST   TRL
>       BN   PSW,OV,.morescroll       ; check to see if
>                                     ; we have exceded the 8 bit boundary
>       INC  TRH                      ; now we are in 16bit territory

Also, to find out if your addition created a value bigger than 8 bits, you
have to check the _carry_ flag, not the overflow flag.  Better use

         ld trl
         add #6
         st trl
         ld trh
         addc #0     ; add with carry, so no need to check PSW register
         st trh

>       BNE  #>credits+3,.morescroll  ; check the high byte

Also, I guess it would be more efficient (and secure) to use a counter for
the number of lines that you want to scroll instead of checking... um, to
be honest I'm not exactly sure _what_ you try to check here. ;)

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

<< ALL LINES IN THIS POST ARE LESS THAN 70 CHARACTERS IN LENGTH >>

<< WARNING LONG POST, MAY REQUIRE ACCOMPANYING DRINK >>

I hate answering my own posts especialy with another question, but
here goes.

The VRMAD2 bit 0 most deffiniatly works correctly in the emulator
and on the real VMU, so what the hell was I on about?

(Below the routines I detail what and why I was doing).

Well below I have two routines the one called WORKS, supprising
works perfectly (Emulator and VMU) (i have trimmed off all the
PUSHs and POPs from both routines, so take it as read that
everything is preserved).

The second routine is called EMULATORONLY and, yes you guessed
it, only works on the emulator, but why?

If I add a BR to .quitin when the counter gets to 0 it correctly
draws the top half of the screen from the correct place in memory.

If I then duplicate the routine(with the added BR) and change the
starting values to xbnk=1 and VRMAD2=1 it then it correctly draws
the bottom half of the screen from the right place in memory.

so my question is why, in its current form (as below), does the
VMU crash (locks up and the game icon goes out while the clock and
flash icons come on) but the emulator works 100% OK?



BSWAP EQU 0    ; bank swapper bit

WORKS:
     SET1 VSEL,4    ; autoincrement please
     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
     MOV  #$80,2    ; the pointer to the LCD memory
     XOR  ACC    ; clear the ACC
     ST   xbnk    ; start with the top 16 pixels
     CLR1 VRMAD2,BSWAP    ; start with the top 16 pixels
.blit:
     LD   VTRBF    ; load 8 pixels of screen data
     ST   @R2    ; save it to the LCD memory
     LD   VRMAD1
     BNZ  .continue    ; if its zero then we need to change the bank
     MOV  #$80,2    ; the pointer to the LCD memory
     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
     SET1 VRMAD2,BSWAP ; next bank please
     BN   xbnk,BSWAP,.b2 ; have we finished yet?
     BR   .quitin
.b2:
     SET1 xbnk,BSWAP    ; next bank please
     BR   .blit
.continue:
     INC  2    ; no auto increment on the LCD memory :(
     BR   .blit ; still more to go
.quitin:



EMULATORONLY:
     SET1 VSEL,4    ; autoincrement please
     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
     MOV  #$80,2 ; the pointer to the LCD memory
     XOR  ACC    ; clear the ACC
     ST   xbnk    ; start with the top 16 pixels
     ST   VRMAD2 ; start with the top 16 pixels
     MOV  #$81,C ; count down half the screen
.blit:
     LD   VTRBF  ; load 8 pixels of screen data
     ST   @R2    ; save it to the LCD memory
     DEC  C    ; counter
     LD   C    ; counter
     BNZ  .continue    ; if its zero then we need to change the bank
     MOV  #$81,C    ; just so we get here again
     MOV  #$7F,2    ; the pointer to the LCD memory
     MOV  #$80,VRMAD1   ; the pointer to our off screen buffer
     MOV  #$FF,VRMAD2   ; next bank
     INC  xbnk    ; next 16 pixels please
     LD   xbnk
     BE   #$02,.quitin   ; we are updating the LCD icon memory today
.continue:
     INC  2
     BR   .blit   ; still more to go
.quitin:



Backgound info:

My Space Invaders game was 99% complete but the screen flashed
alot when things got fast, so I wanted to use the work RAM as a
offscreen buffer and to make the conversion less painless I decided
to use $80 as the loaction in the work RAM for the first byte of
data as with the LCD RAM.

I then need the above routine to blit the work RAM memory to the
LCD RAM.

P.S.
The Space Invaders game is now 100% complete (as far as I am
concerned) and as soon as I have added a comment to every line
(you heard right, EVERY LINE (excluding blank ones)) and put
together a groovy web page for it I will let everyone have access.



=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

Hi all

I tested all my code on the emulator and it worked fine, but crashed on
the actual VMU.

it would appear that bit 0 in the VRMAD2 switches the work RAM banks
fine on the emulator but fails on the VMU.

can anyone else confirm this as its driving me mad, i can not see how
to get round it.

=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

http://dreamcast.ign.com/news/23872.html

A leopard skin effect VM... Groovy ;-)

Any developers running on windows interested in a made-in-VB program
which does the following functions :-
-DCI2VMS
-VMS CRC Calc
-VMS2DCI
-VMI Creation <- Untested

???

If yes, then I'll just go here :-
http://www.fluxworks.com/m2vmstudio.zip

Please read the readme file first, and this zip does not contain the
VB Runtimes, the place to get them is located in the readme1st.htm
file.

Cheers

PS :  Uploading right now, so give me 15 mins

--- Richard Munn <richard.munn@...> wrote: >
> > http://rvmu.port5.com/software.html#vmux (seems to have problems
> with
> > large files) but has access to the source code.
>
> Can you describe the bug?

With 2k VMS files it always worked fine (used it for the ARRWDEMO) but
when I got upto 4k the resulting DCI file was only 41 bytes and no
errors reported (i only found out when i tried to upload it to the
nexus and it said there was not enough room on the card (it was
empty)).

Sorry but instead of investigating this futher i simply started to use
the dos executable from the address in my previous post.
(which does not need a VMI file so is much quicker for testing).



=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

>> So if it's ignored when reading, putting 00h there is just fine?
>> Or 20h (32 as decimal) would be correct?
>
>
>Depends what you are doing with it, I thought you wanted to read saved
>DCI files, if you want to create DCI files I really would not know, but
>at least two people have,

Actually, I'm trying to update MacVMUtil so it converts VMS files to DCI
the proper way. In Previous versions I just fill 00 in there. I dont know
why that data would be needed, but if it is, can you clearly explain how
to find it? I know it cant be 32 because I've seen a few different DCI
files, and they all use different numbers.

Thanks again.

> http://rvmu.port5.com/software.html#vmux (seems to have problems with
> large files) but has access to the source code.

Can you describe the bug?


=====
_  Richard Munn  RAMTronics Software
_ //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...

__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

--- Paul Kratt <sblur@...> wrote: >
<SNIP>>
> So if it's ignored when reading, putting 00h there is just fine?
> Or 20h (32 as decimal) would be correct?


Depends what you are doing with it, I thought you wanted to read saved
DCI files, if you want to create DCI files I really would not know, but
at least two people have,

see
http://rvmu.port5.com/software.html#vmux (seems to have problems with
large files) but has access to the source code.
and
http://www.franken.de/users/deco/myfiles/myfiles.html


> >so for the two bytes (1 word) representing this information in the
> VMI,
> >the first 14 bits( of 16) are zero and only bits 1 and 0 mean
> anything.
> >so...
> >if bit 1 is set the file is protected (can't be copied),
> >if its a game/app then the value of this Word is either
> >$0003 (%00000000,%00000011) - its a game and its copy protected or
> >$0001 (%00000000,%00000001) - its a game and it not protected
>
> That's little Endian, so Shouldn't it be $0300 and $0100?
> Oh! That makes $0200 a protected data file, correct?

opps, yep it is the other way round
$0200 is a non game that is protected.

(You will need a fixed width font for the next bit)

Hex   | Game  |  Protected | Binary              | Roman Numerals
------+-------+------------+---------------------+----------------
$0000 |  n    |     n      | %00000000,%00000000   (just kidding)
$0100 |  y    |     n      | %00000001,%00000000
$0200 |  n    |     y      | %00000010,%00000000
$0300 |  y    |     y      | %00000011,%00000000


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

On 08 Aug 00, rednuht@... (rednuht) wrote:

> > Anyway, the following is a short routine that I occasionally use in my
> > programs:
> >
> > FindLine:

[snip]

> WOW!
>
> I had to get my calculator out and manually try your routine a couple
> of times and it really works!.
>
> it just so damm short, was it the logicaly the 1st thing you tried?
> my code goes on for miles!

I don't know what routine I first used to determine the screen line
addresses... it all mostly depends on what works best with the particular
program or game in question.

In my "Pacman" game for example I built a table of line offsets in RAM,
creating a 'virtual screen' with 6 additional lines at the top and bottom
(all with offset $ff).  Then I used the vertical sprite-position within
the level (relative to the visible area) as a pointer into that table, and
whenever I got offset $ff I knew that this sprite-line was outside of the
visible screen and shouldn't be written...

Sure, there were probably better ways to do this, but oh well.

> you are my hero!

AwwWwww... *blushes* ;)

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

At 8/20/00 04:31 AM , biggs_avalanche@... wrote:
> for those with the benefit of DirectX >= 1.0, I've a new port to
> windows for you. Feel free to give feedback, but please, not too
> harsh :). It does have some EARLY debugging support (just
> displaying some registers), but I could modify it so to call those
> special "unused" opcodes for debugging (or better yet somebody else
> could :). I guess the biggest benefit of this program is that the
> window can be resized (finally a larger display!).
>
> Oh yeah, to those who think this is a bit excessive... I did indeed
> try making this program with the Windows GDI functions in all its
> forms, but it proved too slow.


not at all, actually, i've been working on the Win32 interface myself. =)
I planned to use Direct-X to speed up drawing too, GDI was just too slow,
but I haven't got around to it yet.

Right now, I just got it looking like a cool skinned, borderless, window
app (sort of like WinAmp). Infact it could be made to take custom skins
fairly easily, but for now everything is just hard coded. I was making a
dialog where you could select the fore/background colors when i decided
that i was spending too much time playing with the emulator instead of
working on games. so i just put it on hold for now.

i didn't mention anything because, for one, it's not done, and two, i
didn't know if anyone was interested. i was kind of just making it for
myself. If anyone would like to take a look at VeMUs (my name for it),
just drop me a line, i'll be out of town for the next 2 days though...hmm,
in fact, starting just about now...gotta run!  ;-)

l8r.

for those with the benefit of DirectX >= 1.0, I've a new port to
windows for you. Feel free to give feedback, but please, not too
harsh :). It does have some EARLY debugging support (just
displaying some registers), but I could modify it so to call those
special "unused" opcodes for debugging (or better yet somebody else
could :). I guess the biggest benefit of this program is that the
window can be resized (finally a larger display!).

Oh yeah, to those who think this is a bit excessive... I did indeed
try making this program with the Windows GDI functions in all its
forms, but it proved too slow.

you can find the emu here:
http://rpging.simplenet.com/directvms.html

>this is directly taken from Marcus's site
>"DCI-files" are another Nexus specific file format. A DCI-file contains
>only the blocks of a single file. The first 32 bytes of the file is the
>directory entry for the file (see above), exactly as it appears in the
>flashrom (no byte swapping). The "location of first block" field should
>be ignored when reading."
>
>so im guessing you want to skip 32 bytes to the begining of the file
>contents.

So if it's ignored when reading, putting 00h there is just fine?
Or 20h (32 as decimal) would be correct?

>so for the two bytes (1 word) representing this information in the VMI,
>the first 14 bits( of 16) are zero and only bits 1 and 0 mean anything.
>so...
>if bit 1 is set the file is protected (can't be copied),
>if its a game/app then the value of this Word is either
>$0003 (%00000000,%00000011) - its a game and its copy protected or
>$0001 (%00000000,%00000001) - its a game and it not protected

That's little Endian, so Shouldn't it be $0300 and $0100?
Oh! That makes $0200 a protected data file, correct?

Thanks again!

--- Paul Kratt <sblur@...> wrote: > Hello.
> I have a quick question about DCI and VMI files.
> And someone told me they had problems using a DCI file converted with
> my
> VMUtil program, so the first thing I could think of is this:
> In DCI files, what is "Location of First Block?" I was expecting the
> first block to start at 00, (because that's what I put) but every DCI
>
> file I've looked at does not do this. What is the location of the
> first
> block, and how do I find this? Thanks!
>

this is directly taken from Marcus's site
"DCI-files" are another Nexus specific file format. A DCI-file contains
only the blocks of a single file. The first 32 bytes of the file is the
directory entry for the file (see above), exactly as it appears in the
flashrom (no byte swapping). The "location of first block" field should
be ignored when reading."

so im guessing you want to skip 32 bytes to the begining of the file
contents.


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--- Paul Kratt <sblur@...> wrote: > Hello.
> I have a quick question about DCI and VMI files.
> First of all, on Marcus's page for VMI file types, it says something
> like this
>
> 15...2          1           0
> Not       Protected 1   Game 1
> Used        Not 0       Data 0

so for the two bytes (1 word) representing this information in the VMI,
the first 14 bits( of 16) are zero and only bits 1 and 0 mean anything.
so...
if bit 1 is set the file is protected (can't be copied),
if its a game/app then the value of this Word is either
$0003 (%00000000,%00000011) - its a game and its copy protected or
$0001 (%00000000,%00000001) - its a game and it not protected


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Hello.

I have a quick question about DCI and VMI files.

First of all, on Marcus's page for VMI file types, it says something like
this

15...2          1           0
Not       Protected 1   Game 1
Used        Not 0       Data 0

Ok, that's kinda what it says. Anyway, what does this mean? Does this
mean that only the first byte is used, and if it is 00h, it's an
unprotected data file, if it's 01h it's and unprotected game, if it's 10h
it's protected data, and 11h protected game?

And someone told me they had problems using a DCI file converted with my
VMUtil program, so the first thing I could think of is this:
In DCI files, what is "Location of First Block?" I was expecting the
first block to start at 00, (because that's what I put) but every DCI
file I've looked at does not do this. What is the location of the first
block, and how do I find this? Thanks!

--- MORB <MORB@...> wrote:
> I just uploaded a windows binary on my homepage
> (http://cdbssoftware.net/morb)
>
> --
> Antoine 'MORB' Chavasse / CdBS Software
>

My hero !!

Round of applause !!

I'll try it out 2nite.

=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

rednuht wrote:
>
> --- MORB <MORB@...>> Personnaly, I solved this problem by
> grabbing the source of the
> > emulator, and I replaced the $50 opcode (one of the flash access
> > instruction, which i never use) with a function that dumps an
> > arbitrary
> > ram address. I can then insert it anywhere in my code to dump various
> > values.
> >
> > --
> > Antoine 'MORB' Chavasse / CdBS Software
> >
>
> Have you got a compiled version on DOS or Windoze?
> I m starting to get desperate.

Oops... I forgotten :)

I just uploaded a windows binary on my homepage
(http://cdbssoftware.net/morb)

--
Antoine 'MORB' Chavasse / CdBS Software

rednuht wrote:
>
> --- Brian Chapman <bjchapman@...> wrote: > i don't have a VMU yet
> so i cant do any bench marking but i was
> > curious...the frame buffer has 4 pad bytes after every 12, as long as
> > it's
> > okay (?) to write to these pad bytes wouldn't it make for a faster
> > clrscr
> > to just write to all bytes in one tight inner loop? it seems logical
> > to
> > me
> <SNIP>
> "Danger Will Robinsons Danger!"
>
> yep it would be be faster but the increase would be pretty
> insignificant(the routine is already running in the faster mode).
>
> But the real questions are is there any ram to write to and will all
> future VMUs support writes to these parts of memory.
>

You can easily modify the routine to skip these unused bytes, and it
still may be faster that the usual clrscr routine...

Here is my clearscreen routine (which is almost the same as the one
proposed by Brian):

clearscreen:
	   mov      #0,xbnk

.bankloop:
	   mov      #$80,2
	   mov      #8,b

.halfscrloop:
	   mov      #12,c

.h2lineloop:
	   mov      #0,@R2
	   inc      2
	   dbnz     c,.h2lineloop

	   ld       2
	   add      #4
	   st       2
	   dbnz     b,.halfscrloop

	   bp       xbnk,0,.done

	   mov      #1,xbnk
	   br       .bankloop

.done:
	   ret

I think it still may be a bit faster than the usual clrscr, because it
doesn't check at each byte if it should skip the 4 unused bytes, and
beside I think it is much more readable  this way :)

--
Antoine 'MORB' Chavasse / CdBS Software

--- MORB <MORB@...>> Personnaly, I solved this problem by
grabbing the source of the
> emulator, and I replaced the $50 opcode (one of the flash access
> instruction, which i never use) with a function that dumps an
> arbitrary
> ram address. I can then insert it anywhere in my code to dump various
> values.
>
> --
> Antoine 'MORB' Chavasse / CdBS Software
>

Have you got a compiled version on DOS or Windoze?
I m starting to get desperate.

=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--- Brian Chapman <bjchapman@...> wrote: > i don't have a VMU yet
so i cant do any bench marking but i was
> curious...the frame buffer has 4 pad bytes after every 12, as long as
> it's
> okay (?) to write to these pad bytes wouldn't it make for a faster
> clrscr
> to just write to all bytes in one tight inner loop? it seems logical
> to
> me
<SNIP>
"Danger Will Robinsons Danger!"

yep it would be be faster but the increase would be pretty
insignificant(the routine is already running in the faster mode).

But the real questions are is there any ram to write to and will all
future VMUs support writes to these parts of memory.


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

i don't have a VMU yet so i cant do any bench marking but i was
curious...the frame buffer has 4 pad bytes after every 12, as long as it's
okay (?) to write to these pad bytes wouldn't it make for a faster clrscr
to just write to all bytes in one tight inner loop? it seems logical to
me, but of course i don't have much experience with these kind of
processors. (or maybe it doesn't really matter?)

well, here's my clrscr:

fastclr:
     push    acc
     push    c
     push    xbnk
     push    2
     mov     #0,xbnk     ; start with top half of screen.
     clr1    ocr,5       ; enter RC mode.
.clrbnk
     mov     #$80,2
     mov     #$80,c
.loop
     mov     #0,@R2      ; -
     inc     2           ; - inner loop
     dbnz    c,.loop     ; -
     bp      xbnk,0,.exit
     mov     #1,xbnk     ; now do the bottom half.
     br      .clrbnk
.exit
     set1    ocr,5       ; exit RC mode.
     pop     2
     pop     xbnk
     pop     c
     pop     acc
     ret

> Uhhh... pardon?

hmm.  I think my smtp server went bananas in the middle of a mail
transmission (my mail client tells me that the message wasn't sent at all -
looks like part of the header got through!)

--
    _  Richard Munn  RAMTronics Software
   //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

> btw, i just downloaded the soul caliber vms from sega and after
> disassembling it, it appears to be using the work ram for stuff too. i'm
> not sure exactly what because i haven't studied it much yet...prolly
> double buffer, but some of it's little games suffer from flicker so i'm
> not positive.

Yes, all the official VM games that I've looked at all seem to use work ram
as a screen buffer (I guess that's the way sega's documentation says to do
it!)

--
    _  Richard Munn  RAMTronics Software
   //  www   : http://come.to/ramtronics
\X/   email : richard.munn@...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Uhhh... pardon?


>
>__________________________________________________
>Do You Yahoo!?
>Talk to your friends online with Yahoo! Messenger.
>http://im.yahoo.com
>
>
>
>       post:  vmu-dev@eGroups.com
>unsubscribe:  vmu-dev-unsubscribe@eGroups.com
>    archive:  http://www.egroups.com/group/vmu-dev/
>        faq:  http://rvmu.port5.com/faq.html
>

On Sat, Aug 12, 2000 at 06:21:00AM +0100, tyro@... wrote:
> Gasp!  You know how to compile a _Windows_ version?  How did you do that?
> Whenever I tried it with DJGPP / Allegro and the Windows libraries, I just
> got a bunch of error messages I couldn't make much sense of.

I had only minor problems compiling the windows version with lcc32, but the
resulting executable did not run and I know noting about windows programming.
For DJGPP/Allegro you have to use the dos* files, I think, I don't have
DJGPP/Allegro yet.

On Sat, Aug 12, 2000 at 06:39:29PM -0000, Brian Enigma wrote:
>     After a couple of days of tracing, I discovered that the VMI files
> I have been creating ended up padding the text fields with spaces
> instead of nulls.  Fixing this made a HUGE difference!

I think this has been the only real error, when uploading just the VMS
file your original code worked without any modifications.

Soeren

--- weimin@... wrote: > Your right I've been a bit vague....
More like how's the best way to
> make the display, think the flex grid control would do?
> --- In vmu-dev@egroups.com, rednuht <rednuht@r...> wrote:
> >
> > --- weimin@p... wrote: > Thanks for all the great info Guys!
> > > anyone know
> > > how to implement a simple hex editor in VB?

http://mh1.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=1&txtCodeId=107\
06

don't reinvent the wheel


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com