November 19, 2017, 04:35:44 PM
News: If someone gives you crap then give them a Bad Star
Pages: [1]   Go Down
Author Topic: Need Some ?rof Logic thinking here. QBasic port to VB.NET and Binary files  (Read 3850 times)
Jason Reed
Administrator
*

Stars: +4/-0
Offline Offline

Gender: Male
Posts: 4437


Pure Evil Administrator


WWW
« on: October 05, 2007, 09:03:06 AM »

Here is what I'm given:

1 dat file which contains apparently hexadecimal data saved as binary which acts as a source file
2 bin files that are produced from the dat file which contain binary data stored as high bit and low bit files with addressing. The binary files are larger than the original source file.
1 QBasic program which is used to produce the binary files from the dat file

Solution Needed: Provide an application that can convert the binary files back to the original hex file.

Step 1: Port the original QBasic program to VB.NET, with the reasoning that once I can get the VB program to do what the QBasic program does it will be easier to write a reversal.

Findings of Step 1:

I have been able to get VB to READ the data and store it to variable the same as the QBasic program. However, when attempting to write the bin files using the same procedure as the QBasic program VB creates something entirely different.

To ensure that the OS doesn't make a difference (the files were created approximately 1980 according to the timestamp). I downloaded a copy of QBasic 1.1 and ran the QBasic program in full. However, it seems that even QBasic is producing different results from the example files given me, as well as being completely different from the way VB.NET output data.

Here's some of the QBasic code that I've got:
THIS PART WORKS OK
Code:
     OPEN "R", #3, "ATT" + SNR$ + ".DAT", 2
     FIELD #3, 2 AS ATTDAC$

     ADRA = 0             
     ADRB = 1000           
     ADRIS = 1300           

     OFFSETA = 0
     OFFSETB = 0
     OFFSETIS = 0

     DIM DA(999)         
     DIM DB(299)
     DIM DIS(299)

     FOR I = 0 TO 200       
GET #3, I + ADRB + OFFSETB
DB(I + 0) = CVI(ATTDAC$)

GET #3, I + ADRIS + OFFSETIS
DIS(I + 0) = CVI(ATTDAC$)
     NEXT

     FOR I = 0 TO 861         
GET #3, I + ADRA + OFFSETA + 1
DA(I + 1) = CVI(ATTDAC$)
     NEXT
     OPEN "R", #1, "ATT" + SNR$ + "L.BIN", 1
     OPEN "R", #2, "ATT" + SNR$ + "H.BIN", 1
     FIELD #1, 1 AS X$               
     FIELD #2, 1 AS Y$               
'  GOTO INIT9

     FOR I = 1 TO &HFFF           
LSET X$ = MKI$(0)         
PUT #1, I
LSET Y$ = MKI$(0)         
PUT #2, I
     NEXT I
     BEEP
INIT9:
     ADRISLS = &H0   
     ADRB = &H4000 
     ADRA1 = &H2000
     ADRA2 = &H6000

     BLISLS = &H1000
     BLA = &H2000   
     BLB = &H4000   
  OFFSET = &H0         

This part however gives me crap apparently in both VB and QBasic (as compared with the example output)
Code:
     FOR I = 30 TO 0 STEP -1
A = 30 - I                     
DAC = DB(30 - I)
ADR = I + ADRB
   GOSUB WRBIN
     NEXT
     FOR I = 30 TO 0 STEP -1
  A = 30 - I                         
  DAC = DIS(30 - I)
  ADR = I + ADRISLS
    GOSUB WRBIN

     NEXT
 
     DACISLS = DIS(0) + BLISLS
     DACB = DB(0) + BLB
     FOR I = 31 TO 999
  ADR = I + ADRB
  DAC = DACB
    GOSUB WRBIN
  ADR = I + ADRISLS
  DAC = DACISLS
    GOSUB WRBIN
     NEXT

     OFFSET = &H1000                   

     FOR I = 0 TO 150
A = 30 + I                         
DAC = DB(A)
ADR = I + ADRB
   GOSUB WRBIN


     NEXT
 

     FOR I = 0 TO 150
  A = 30 + I                     
  DAC = DIS(A)
  ADR = I + ADRISLS
    GOSUB WRBIN


     NEXT
 

     A = 30 + 150
     DACISLS = DIS(A) + BLISLS
     DACB = DB(A) + BLB
     FOR I = 151 TO 999
  ADR = I + ADRISLS
  DAC = DACISLS
    GOSUB WRBIN
  ADR = I + ADRB
  DAC = DACB
    GOSUB WRBIN
     NEXT


     OFFSET = 0
     FOR I = 60 TO 860
  A = I                               
  DAC = DA(A)
  ADR = I + ADRA1
    GOSUB WRBIN
  EADR1ALT = EADR: ADR1ALT = ADR
  ADR = I + ADRA2
    GOSUB WRBIN
     NEXT

     A = 861 - 60
     DAC = DA(A) + BLA
     FOR I = 860 TO 999
  DAC = DA(A) + BLA
  ADR = I + ADRA1
    GOSUB WRBIN
  DAC = DA(A)                       
  ADR = I + ADRA2
    GOSUB WRBIN
     NEXT


     A = 60
     DAC = DA(A) + BLA
     FOR I = 0 TO 59
  ADR = I + ADRA1
    GOSUB WRBIN
  ADR = I + ADRA2
    GOSUB WRBIN
     NEXT
WRBIN:
     ADR1 = ADR MOD &H1000
     EADR = ADR - ADR1 + (ADR1 \ 100) * &H100 + (((ADR1 MOD 100) \ 10) * &H10 + ADR1 MOD 10) + OFFSET
     LSET X$ = MKI$(DAC MOD &H100)
     PUT #1, EADR + 1
     LSET Y$ = MKI$(DAC \ &H100)
     PUT #2, EADR + 1
RETURN

Any assistance on why the binary data isn't being written correctly in the bin files will be most appreciated.
Logged

-- signature --

Martin Wallace
Founders
*

Stars: +1/-0
Offline Offline

Posts: 3602


God is dead, I have surpassed him.


WWW
« Reply #1 on: October 05, 2007, 09:57:15 AM »

No idea  happydance

If you are sure that the bin files were definately created by the code you have then I think you have answered your own question : The OS makes a difference.

I think you are getting in a tangle by assuming you can recreate the QBasic program - for all you know it may be 'part' of a process for which you don't have the complete processing for.

If it was me I would dump the old code and start from scratch by working out what the requirements of the process were, based on the provided input and the sample output.
Logged

Every time god kills an angel, I masturbate.

Jason Reed
Administrator
*

Stars: +4/-0
Offline Offline

Gender: Male
Posts: 4437


Pure Evil Administrator


WWW
« Reply #2 on: October 05, 2007, 10:04:35 AM »

Ewww that's going to be icky. I'm going to need to see if I can find a way to make the data in those input and output files have some literal meanings or something because if I open them all I get is odd characters in a text editor or a bunch of hex in a hex viewer.

I really don't fancy going through it one bit at a time but I might just need to do that.

As for the QBasic code, it seems complete to me actually at least I don't get any errors when running. I was afraid that the OS would do something. The originals were built most likely on old DOS technology.

Was DOS 16 or 8 Bit? Maybe that is a key I need to help work around. I know Win2K is a 32 bit OS but I'm not sure about anything before it actually (they were before I actually started programming).

Thanks for the thoughts Martin. I'll see what I come up with and let you know how it worked out.

BTW I downloaded a free copy of QuickBasic 4.5  mf_Dr_Evil Talk about going Old School yes
Logged

-- signature --

Martin Wallace
Founders
*

Stars: +1/-0
Offline Offline

Posts: 3602


God is dead, I have surpassed him.


WWW
« Reply #3 on: October 05, 2007, 12:01:07 PM »

Are the BIN files some kind of file image dump?

In which case the problem is most likely they are FAT16 dumps while your working currently on NTFS.

I'm a little confuzzled about what it is you're trying to do to be honest.
Logged

Every time god kills an angel, I masturbate.

Jason Reed
Administrator
*

Stars: +4/-0
Offline Offline

Gender: Male
Posts: 4437


Pure Evil Administrator


WWW
« Reply #4 on: October 05, 2007, 03:04:58 PM »

My company sometimes needs to program EPROMS for some boards we build. The EPROMS basically are data storage for particular settings of the board. The EPROMS have three channels called A, B and ISLS. These three channels have certain values assigned to them. These values are stored in the EPROMS as 12 bit values (three hex characters). There are so many values that they all can't be stored in a 32KB EPROM (right now we're talking pretty old technology) so we need to split it into two EPROM therefore two EPROM bin files. The QBasic application that they've given me is suppose to take the source file which I can only guess is assembly language (the guy told me it was hex data) and reads this source file two bytes at a time (converting the data into an integer along the way) starting from a specific record. It then stores the information into one of three arrays. From what I can see the data always comes out as three hexadecimal characters all the way through the process. This part I can recreate without a problem. I can get the same information as the QBasic program, although I have to do some witchery to process the data correctly. Basically when I read two bytes of data using VB instead of getting DBE I would get BED so I have to swap them around in VB to make it work.

Now when I attempt to create the two BIN files is where I'm running into trouble. The BIN files apparently are binary information with the data stored at particular addressing. This addressing is used in the EPROMS to call back the values. For example if the firmware asks for address &H1000 the EPROMS would give back DBE. The BIN files are created the above example shows. However, instead of being done two bytes at a time they are done one byte at a time. This is because we need to split them between high bit and low bit. Basically using my example above the address &H1000 of the low bit EPROM would return BE while the same address on the high bit EPROM would return D. The firmware puts them together and gets DBE which tells it what value to set something else on the board. Now my problem is I'm trying to do this same process with VB and for some reason I'm getting wrong data. The data isn't reversed as I expected it to be (otherwise the file hashes would be swapped) it is just not giving me the same data.

The only thing I'm seeing however is that the QBasic running on my computer gives me a different result as well. So Either 1 the problem comes from the program was originally written to run on a 16 or 8 bit computer and thus my 32 bit system is handling the values differently, OR I'm using the wrong process ... Or both I guess.

I'm going to try two different approaches. One will be to dissect the original hex file and the two binary files and see if I can find the pattern and then write my code to generate that pattern. The other approach may be to run the QBasic application under a DOS Emulator and see if that makes it work then I know it is a OS issue as well and I can try to compensate (maybe)...

If all else fails I can always wait until one of the actual programmers comes back from vacation and let him deal with it, but there's no fun in that.
Logged

-- signature --

Jason Reed
Administrator
*

Stars: +4/-0
Offline Offline

Gender: Male
Posts: 4437


Pure Evil Administrator


WWW
« Reply #5 on: October 08, 2007, 05:34:48 AM »

After some more investigation I think that it isn't the way integers are handled at all but how Windows may be reading the binary data.

I'm using the FileOpen function of VB because there doesn't seem to be any other way to write or read from a file randomly. Using the FileGet and FilePut to read and write to the particular records/addresses of the files. I noticed that when trying to read record/address &H0 that I get an error from VB. However when I read record/address &H1 I get the data from &H0.

Adding an offset doesn't seem to help actually which is rather odd. I think my next attempt I'm going to pile the entire binary data into a byte array and see what I get from that. Maybe that would be more like what I'm after. Then if I can do that then I can just try writing the entire array back to file.
Logged

-- signature --

Pages: [1]   Go Up
Print
 
Jump to: