Almost running, paper tape format?

Discuss software for the Micro-KIM and KIM-1

Almost running, paper tape format?

Postby sr » Feb Tue 05, 2008 7:48 am

Micro-KIM built and interfaced with Linux laptop. Basic commands like ' ' and '.' work when sent down the RS-232 connection. Now all that appears to stand between me and some sweet retro eight-bit wumpus-playing is ability to download the KIM-tape files.

I am using a command-line program called ascii-xfr to send data to the KIM. ascii-xfr is the program behind minicom's ASCII-mode upload function, so I shouldn't be doing anything on the command line that minicom isn't doing already. The KIMPAPER readme says that the KIM wants to see a '\r', '\n' and six '\0's at the end of each line (the data portion of the line, I'm getting pre-encoded from this web site), and an XOFF (0x13) at the end of the file. So far, I have not had any luck with either a *nix-format (only '\n' at EOL), CRLF line termination, or CRLF and the six NULLs. Ditto for trying to send the 0x13 at the end.

To summarize, I get the KIM prompt on resetting the uKIM and sending '\n' from the terminal, so the KIM and I have communication; I type 'L', without any space or newline, to begin the program; then I send my prepared file, which consists of the ASCII payload from the web site and some set of control characters. The output to the terminal is a string of characters, invariably including ". ERR .". If the file I'm sending begins ";180200", *(0x200) does _not_ change after the send, and typing "200 G" does not result in any noticeable results.

Tantalizingly close! Please help me get over this hump! I am aware of the Pascal program that prepares data files for the KIM, but it's been a few years since I've done Pascal (I was a froshman in college!), and if there's anything at all subtle, I'll miss it.
sr
 
Posts: 8
Joined: Dec Thu 20, 2007 12:49 am

Postby mfortuna » Feb Tue 05, 2008 10:23 am

I'm pretty sure you need to hit newline after the "L", but I'm not home to confirm that. Try hitting newline.

Mike
mfortuna
 
Posts: 49
Joined: Dec Wed 12, 2007 2:30 pm

...and now it works!

Postby sr » Feb Wed 06, 2008 11:01 am

Had a look at the prepared output files in the kimpaper directory on the CD and duplicated that format. EOL indicated by CRLF, no NULLs; EOT indicated by just stopping transmission, no CRLF or NULLs. What finally made the KIM accept my input was setting a character delay. I wonder if this was just a backdoor way of giving the box enough time to calculate the checksum (in which case a line delay might be more appropriate), or this is simply the way to make this work.

I don't have the laptop with me, but the final transmit script went something like---

Code: Select all
#!/bin/sh
#
inps='wump1 wump2 wump3 wump4'

L <<FOO
L
FOO

for i in $inp; do
 echo -- $i
 lf2crlf <$1 >out
 ascii-xfr -sen -c10 L >/dev/ttyS0
 ascii-xfr -sen -c10 out >/dev/ttyS0
 sleep 1
done


This prepares a list of files to send (wump[1234]) and an input file consisting of the character 'L'. It then loops over the file names, sends the 'L' to the KIM, sends the file, and delays for one second to allow the KIM time to digest things. I do not believe that ascii-xfr accepts input from the command line or here document (hence the L file), and the one-second delay between files seemed necessary. As in, if I didn't have it the KIM wouldn't accept the next file. Consider lf2crlf a program or script for replacing '\n' with "\r\n" and skipping the final '\n' in the file. It started as a compiled program, because I thought it would need to add NULLs, but I think that as it's turned out, it can be implemented with a sed script.

Now if I could only get wump to run. "350 G" puts "YoU=A" on the display, but I can't get beyond this. Anyway, checking memory shows that my files are in the KIM, and getting someone else's program debugged and running is not top priority.
sr
 
Posts: 8
Joined: Dec Thu 20, 2007 12:49 am

Re: Almost running, paper tape format?

Postby chassum » Jun Tue 26, 2012 6:37 pm

Thanks for the posting guys. I just want to confirm I'm running minicom in linux and have my ascii file transfer set for:
/usr/bin/ascii-xfr -sen -c10 -l200

Just now I loaded the clock.txt prog from the CD and it worked great.

cheers,
-chassum
User avatar
chassum
 
Posts: 23
Joined: Apr Mon 23, 2012 1:53 pm


Return to Software

Who is online

Users browsing this forum: No registered users and 0 guests

cron