Well this isn't actually about ASM but i thought you low level guys

would know the answers.

I know CPU's interpret Binary values only, basically a 1 represents

on and switches a diodes(transistor) state to on and a 0 shuts the

diode off.

Ascii, well there's no such thing really just a represention of

Binary on the screen to save us the trouble of writing everything

in binary.

If i drag a binary file into notepad i see a bunch of symbols, i

take it thats this is just more Ascii representing Binary?

Second, from VB i opened a file into memory and copied the whole

file into a byte array. Well if i save that array to a text file it

has the form,


So what data type is this?

Basically i want to take these byte array values and construct them

back into a workable binary file?

Thanks for any insight!
Posted on 2004-06-27 17:10:48 by jonnyr
post your VB code
Posted on 2004-06-27 17:17:23 by AceEmbler

but I don't understand your problem.

Ascii is just a visual code for a byte, and one byte contains 8 Bits, which gives you 256 possible options. That are the well-known ASCII-characters 0-255.

When you open a file in VB, it is no problem to save the file array:

'VB code
Dim Buff() As Byte, _
ff As Long

'load the file into an bytearray
ff = FreeFile
Open "C:Test.dat" For Binary As #ff
ReDim Buff(LOF(ff) - 1)
Get #ff, 1, Buff()
Close #ff

'and now save the bytearray
ff = FreeFile
Open "C:Test2.dat" For Binary As #ff
Put #ff, 1, Buff()
Close #ff

Was this your problem or did I missinterpret it?

Posted on 2004-06-28 05:10:22 by ndn4u
I know most of us have come to think of the codepages DOS/Windows uses with their characters for 128-255 as 'standard', but just to keep the terminology straight ASCII is 7-bit and only covers 0-127 :alright:.
Posted on 2004-06-28 05:42:23 by Jibz

this is quiet correctly, but the MS ASCII 'standard' allows to represent a whole byte and that is a great advantage.
But, of course, the future is Unicode !

Posted on 2004-06-28 05:51:07 by ndn4u
Option Explicit

Private Declare Sub CopyMemory Lib "kernel32" Alias _
"RtlMoveMemory" (Destination As Any, _
Source As Any, ByVal Length As Long)

Private Const datID = 101
Private Const datType = "custom"
Dim k() As Long
Dim i As Double
Dim bytes() As Byte
Dim longs() As Long

Private Sub Command1_Click()

Open "c:ytes.txt" For Output As #1
For i = LBound(longs) To UBound(longs)

Print #1, longs(i)
Next i
Close #1

End Sub

Private Sub Command2_Click()

' load data from RES file into zero-based byte array
bytes = LoadResData(datID, datType)

' allocate longs array
ReDim longs(1 To (UBound(bytes)) 4) As Long

' sling from byte to long array
CopyMemory longs(1), bytes(0), UBound(bytes) - 1

' print twenty out for comparison

End Sub

The file is being loaded from a resource file.

So if you look at the print out "c:ytes.txt" you will get a bunch of numbers produced, my question is how do i reconstruct these number back into a working binary file?
Posted on 2004-06-28 05:55:34 by jonnyr

In my opinion, it is absolutely superfluous to put the byte array into a long array, but maybe you need it.
But for saving it, you must have an byte array. Let me explain why:

By now, you have a loop for each value of the longarray. You say:
Print #1, longs(i)

As the Print-instruction uses strings, VB does as if there would stay:
Print #1, CStr(longs(i))

But you don't want to put numbers in the file. You want to put the bytes in the file. For that, you could use your byte array and put an ; after the print-instruction, so that it won't start a new line:

For i = LBound(bytes) To UBound(bytes)
Print #1, Chr$(bytes(i));
Next i

Look at the Chr$()-Instruction, which changes a number into a character, using the ASCII-table.
If you don't have the byte array any more, you can rebuild it in the same way you built the long array:

Call CopyMemory(bytes(0), longs(1), (UBound(long) - 1) * 4)

But for saving a byte array, there is a very more effective methode than printing them in a loop:

ff = FreeFile
Open "c:ytes.txt" For Binary As #ff
Put #ff, 1, bytes()
Close #ff

Posted on 2004-06-28 06:25:24 by ndn4u