Jump to content
IGNORED

Need a shell script/perl for converting ASCII value to binary


acadiel

Recommended Posts

Hey guys -

 

Dumping some CC-40 stuff here. For some reason, I'm getting varied results with PuTTY, RealTerm, and ProComm when it deals with RAW ASCII transfers. (For example, I dumped what was supposed to be 2048 bytes as raw, and got 2091. Wasn't CR/LF - so it must have been a terminal translation issue or something.)

 

So anyway, I'm dumping the memory like this:

 

location,ASCII_value

 

So, for the 2K that I dumped, I get something like this:

 

63488,16

63489,2

63490,193

63491,166

63492,180

63493,10

I can very easily lob the first part off (I did it for sanity purposes) with a "cat file | cut -f2 -d,". So that leaves me with 2048 lines of ASCII values.

I'd like to use my Mac/Linux box to essentially go through that file, and do the equivalent of this:

for i = 1 to lines in file

print chr$(i) >>filename.bin

next i

So, at the end, I'll have a nice 2048 byte binary image.

Anyone have a Perl or Shell script that they can whip up to do this?

Thanks!

Link to comment
Share on other sites

You can use the xxd command. First you must create a text file consisting of the hex values, then pass it though xxd.

 

Example: Suppose you have a text file input.hex containing "ff ff 83 7c" as ascii text; then

 

 

xxd -p -r input.hex > output.bin

 

If you have decimal values and need the hex values you can use the printf command to create them.

 

 

#!/bin/bash
VALUE="200"
printf "%2x" $VALUE  > input.hex

 

From here on, happy shell programming. :-)

Link to comment
Share on other sites

Thanks, Michael!

 

The guy who's helping me also figured out a way to do it, but he didn't share it with me (yet). :) He managed to create a binary file directly for me; it looks pretty equivalent to the CALL PEEK and PRINT #1 statements I've been doing (with the exception that the PRINT #1 statements I've been doing have had CR/LFs and some other "record" character in them, so it made a 2048 file to be 8192 bytes.)

 

It's taking approximately 40 minutes to dump a 32K CC-40 cartridge in this manner (with the comma delimited file.) most all of them I've verified so far have been 32K (in the 32K space), with the exception of the E/A one... that one has a 64K EPROM in it. I've been scratching my head on where that one lives, because the entire CC-40 memory map is 64K, and that cart doesn't have a bank switch chip in it... it has to be banking somehow.

Link to comment
Share on other sites

Well now, here's my solution (couldn't resist):

 

 

#!/bin/bash
test -f out.hex && rm out.hex
IFS=$'\n'
for line in `cat $1`
do
  IFS=',' read -a v <<< "$line"
  printf "%02x " ${v[1]} >> out.hex
done

xxd -p -r out.hex > out.bin

 

I guess you do not really need the offset.

 

From n things you consider feasible in bash, there are at least n+1.

Link to comment
Share on other sites

I'll plug that in and see what I get... thanks!!!

 

I figured out the 64K E/A cart. I simply have to do a CALL DEBUG, hit "R" for paging, and change to cart page #1 to get the second 32K of the E/A cart. However, this is not persistent once you leave DEBUG (it went back to bank 0). Also, those turds (I'm using a Marc euphemism here) at TI decided to neuter the ROM bank switching in DEBUG. Even though you can page ROM in CALL DEBUG on the CC-40 by hitting R for paging, and hitting the spacebar to get to "Cartridge Page" and even put in a 0-3, you still get the same 8K. I guess they didn't want folks dumping the ROM.

 

The only alternative is assembly on this beast to trigger a bank switch (and copy to a RAM cartridge), or sending it to a ROM guy (which I don't mind, because I really don't feel like learning how to get into this system.) :-)

 

I've attached a good copy of an example output, BTW... in case you get a chance to test it before I do :)

 

cc40_statistics_5000-cfff_copy1.txt

  • Like 1
Link to comment
Share on other sites

Here's what I had to do:

 

1) I had to get the second ASCII Field by itself: cat cc40_2k_raw.txt | cut -f2 d, >cc40_2k.txt

2) I had to remove the ^M from the newfilename: sed -e "s/^M//" cc40_2k.txt >cc40_2k_noM.txt

3) Ran a convert script on it to concatenate the ASCII: ./convert.sh cc40_2k_noM.txt >cc40_2k.bin

 

Convert script (does all three steps):

sh-3.2$ more convert.sh
# get rid of first field
  cat $1 | cut -f2 -d, >${1}.edited
  sed -e "s/^M//" ${1}.edited >${1}.noM

for i in $(cat ${1}.noM)
  do
    printf \\$(printf '%03o' $i)
done

So, did this on the 2K TMS7xxx ROM (yeah, that thing has 2K MASK ROM in it, very easy to get to), and the carts. It also helped someone emailed me copies of the carts to validate what I was doing was correct.

 

EPROM cartridge images for the CC-40 coming soon. The last thing we need is the actual machine's 32K ROM. Then, people can work on emulation :)

Link to comment
Share on other sites

Found something really interesting while dumping these CC-40 carts (after converting to binary). I essentially dumped the entire 32K memory for each cart, from >5000 to >CFFF in the memory map (straight through). Lee, I believe, dumped the cartridges with an actual programmer.

 

The first 12K of my dumps (out of the 32K) were actually at the BOTTOM of Lee's dumps. In essence, the CC-40 is placing a small bit of primitive copyright protection against using the memory dump method I used to do cartridge dumps by relocating the last 12K of the cartridge to the beginning of the cart memory space when you do a CALL PEEK. Easy solution; take the first 12K of the memory dump method and cut it, and paste it on the end of the ROM image. Then mine matched Lee's dumps.

 

I've attached all of the CC-40 files in my Dropbox if anyone wants them. I have dumps of all of the known cartridges:

 

Advanced EE

EA

Finance

Games 1

Mathematics

Memo Processor

Pascal

Statistics

 

I also have the 2K Mask ROM that lived on the TMS CPU from >F800->FFFF in the archive. The only remaining item is the actual CC-40 32K ROM (which is why I need a halfway functioning one to send to someone to dump). Then, the MESS/MAME people can do their magic and try to get us CC-40 emulation.

 

https://dl.dropboxusercontent.com/u/19597743/ti-99-4a/CC-40%20DUMPS.zip

 

Enjoy!

My dump	(1K offset)	Lee's dump (1K offset)	CC-40 Memory Map
>0000->0FFF		>5000->5FFF		>5000->5FFF
>1000->1FFF 		>6000->6FFF		>6000->6FFF
>2000->2FFF		>7000->7FFF		>7000->7FFF
>3000->3FFF		>0000->0FFF		>8000->8FFF
>4000->4FFF		>1000->1FFF		>9000->9FFF
>5000->5FFF		>2000->2FFF		>A000->AFFF
>6000->6FFF		>3000->3FFF		>B000->BFFF
>7000->7FFF 		>4000->4FFF		>C000->CFFF
Link to comment
Share on other sites

OK, I'll keep a copy of your dumps. Next thing important for an emulation are schematics; if we don't have that, some architectural overview would be required at least.

 

I can put you in charge of the "hap" person who's going to be working on this. Look for an email. :)

Link to comment
Share on other sites

  • 1 month later...

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