On 1/29/2006 at 1:13 PM J.C. Wren wrote: It's my suspicion that there's very little out there that will interleave two 4-bit-wide images to make a nice 8-bit one. However, there still may be something out there to make two 8 bit images out of a 16-bit one, as that was a very common task when writing old 286 BIOS ROMs. (Yeah, I ended up writing my own anyway). Cheers, Chuck

On 1/29/2006 at 10:16 PM John Allain wrote: I didn't realize that there was a CLI tool that could recompute the hex checksum of each record. (I don't count things like Perl). Cheers, Chuck

On 1/29/2006 at 10:11 PM Richard wrote: True, but then, you can do almost anything in machine language or SNOBOL. ;<) All in all, maybe C is the best tool for the job? Anyone know of a good Unix implementation of IITRAN? Cheers, Chuck

On 1/29/2006 at 11:11 PM Richard wrote: well, would I write a bunch of M4, lex, awk and sed to to merge the nibbles on two hex files? No--it's very straighforward and a no-brainer in C and will pretty much run on anything, even a little Z80 CP/M system.. Would I use C for a text application that involved extensive pattern matching? Probably not. The aforementioned tools (or other ones) are more appropriate. I suppose I could figure out a way to drive screws using a jackhammer, but a screwdriver is the right tool for the job. Cheers, Chuck

I just wrote something that kind of goes the other way - splits a binary file into nybbles, with a checksum. In this case, though, it's converting a sample into a sysex dump, so I used libsndfile which takes care of endianness and bit depth - I only want 8-bit unsigned anyway, so I can load the sample as an array of floats, apply crunching if necessary, and spit it back out as an unsigned char with all the zeros stomped to 1 to get round a hardware weirdness. Then all I need to do is tack a sysex header on the start and end, and fire it out as pairs of nybbles with a 7-bit checksum at the end. Bonus prize of a brand new LA36 ribbon if you can tell me, based on the above description, what the program is used with. Gordon.

On 1/30/2006 at 12:19 AM Don North wrote: Not to seem too flip, but the next time I need a Windows device driver, I should wirte it in Perl? . I blame IITRAN for getting me interested in computer programming. I was an undergrad in physics at IIT getting very bored, when I looked over the shoulder of a classmate during a lecture and later asked him what I was doing. I borrowed the text and finished it in an evening--that Monday I caged a job card and wrote my own program to run on the (bright and shiny new) 360/40. I enrolled in an introductory FORTRAN course and used it to teach myself 360 Assembler and work my way through a supervisor dump. I got to be persona non grata in the very small IIT computer center, but hey, it was the 60's. There was really no program of computer study then, so transfered to Purdue (at the expense my scholarship). My parents were furious--my father told me that working with computers was a low-grade clerical job that no one in his right mind would give up a career in Physics for. Oddly, I realize that if I had a child making the same career decision today, I'd have the same problem as my father. My experience with Unix goes back to about 1980, when, I suspect I was part of a group that did the first port of the Xenix kernel to the 286 (Later, when my colleagues and I were working up FORTRAN compiler for the ETA-10, we used a VAX 11/750 running 4.2BSD as a development platform. It seemed to be the right tool for the job, absent access to larger hardware. I wrote plenty of (insert the name of a monosyllabic Unix utility). I still do, occasionally, if what I want to do is suited to it. But when I look over the detritus of code that I've written over the years, it's usually the FORTRAN or C code that gets reused after more than a decade has passed by. Most of my systems have a Linux boot partition on them--but Windows is what gets booted by default. Recently, I was going through old media and found an 8" CP/M diskette with a ISIS-II--CP/M disk conversion utility on it. Written in FORTRAN, with a very few assembly subroutines (to do basic disk I/O). Probably written in the days of Jimmy Carter, it still is quite readable, even thought I've forgotten most everthing I've ever known about ISIS-II disk structure. OTOH, I don't have any later awk, sed, lex... code that's even 20 years old--quite a few makefiles, though and lots of C code. But I could never make the claim "I stopped writing in any other language". If GPSS or Prolog was uniquely suited to a problem that I had, I'd blow the dust off my reference manual and get coding. Sorry for the length. Cheers, Chuck

In article <5.1.0.14.2.20060130131200.03b29758 at mail.30below.com>, Roger Merchberger <zmerch at 30below.com> writes: I've got a FORTH kernel ROM for the 6502 and I'm trying to figure out how to get it into my CBM 8032. I'd like to get it PROMed so that I can slip it in the PROM slot of the CBM so I'll always have FORTH available on the machine. Then I'd like to code up some ASCII animation hacks for it as a wild compo entry for Pilgrimage. Oh well, someday. I do have a 6502 FORTH that I could load as a .prg from disk, so that's a start. FORTH is good for restricted hardware environments and oh hey, if you have a Sun, the boot stuff is a FORTH variant. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200601301050080652.435B73FC at 10.0.0.252>, "Chuck Guzis" <cclist at sydex.com> writes: I'd say that's accurate. FORTH was designed for microprocessor control in embedded systems. People have added all kinds of layers on top of the kernel over the years, but its typeless nature gets kind of grungy in larger applications. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200601301749.01430.rtellason at blazenet.net>, "Roy J. Tellason" <rtellason at blazenet.net> writes: I believe the FORTH philosophy is that you should write your own I/O WORDs that make sense for your application. The console I/O stuff is only there because FORTH is intended to be an interactive environment (at least for development). You mean your target system doesn't even have a serial port? -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

On 1/30/2006 at 11:33 PM Don North wrote: Actually, once you get the hang of it, it's not too bad--and probably no worse than writing *nix drivers. Probably the toughest parts are the power management and plug-n-pray routines. Some things, like floppy drivers, are actually a driver-within-a-driver; i.e., an outer task that dispatches requests to an inner thread for processing. Microsoft has done a pretty decent job of abstracting a lot of the more common hardware components. Yeah, I know--heresy. But the best part of NT/2K/XP is the kernel. It's all that other stuff that I don't like. IMOHO, the earlier (NT 3.5 and 4) kernels were probably the best (when M$ still had to think about non x86 architectures). Cheers, Chuck

Well, if "things like perl" means "anything with enough generality to recompute checksums", that becomes..uninteresting. :) If it means something more like "Turing-complete languages", it's not much more interesting. But if you're willing to accept a bti of awk, it's doable. I'd probably do something like ...the record... | sed -e 's/../& /g' | cvtbase X d | awk '{sum += $1;} END {printf("%02x\n",255-(sum%256));}' mutatis mutandis if the checksum algorithm is more complicated than a simple "all bytes sum to 0x00". Inserting the resulting checksum into the record is left as an exercise for the reader. (cvtbase is my own, but as used here just converts 0-9A-F hex to decimal; I believe you can do that with dc or bc or some such instead. Or you can pick up ftp.rodents.montreal.qc.ca:/mouseware/hacks/cvtbase.c. :) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B