11/07/2017 at 08:28 •
UPDATE: Whoa Whoa Whoa..... (at the bottom).
So, the question, earlier, came up regarding how the DRAM gets refreshed, if the /REFRESH pin is N/C (which it appears to be, according to the schematic).
There's still the issues of BANK and /PROMCS, and how those are related to the DRAM... My guess, again, is that *every* address-access on the Z80's address-bus, accompanied by /MREQ, accesses a memory-location in the DRAM (even, for instance, when the ROM is being read).
BANK is controlled by a bit on the "system port" register... That, as we understand, chooses whether to do memory-accesses from the ROM or the RAM. So, e.g. during boot, BANK directs it to the ROM, then after boot, its directed to the RAM where the OS is stored, etc. (There's some debate as to whether the "BIOS" in the ROM is accessible to applications once the bank has been switched to RAM... E.G. if there could be, say, routines in the BIOS for displaying characters on the screen, could that be called from a user-application, switching into the ROM for execution, then back into the RAM for the next portion of the user-application? I'm sure there are ways, but they may not be pretty... e.g. storing *pieces* of the same code in both ROM and RAM, at the same locations... I'm sure I can find out with further analysis of Ziggurat's ROM disassembly).
So, obviously, when BANK is set to ROM, /PROMCS gets activated with /MREQ, but /XENRAM does not. But, then, when the ROM is executing (during boot), the RAM still needs to be refreshed... so its still feeding *every* address-access to the row/col system... Which is fine for /RD, since /XENRAM is disabled and therefore the data in the DRAM is not written to the data-bus...
But what about Write...? /WR is not gated through the custom chip, it goes *straight* to the DRAM!
Write... Never Happens to the Read ONLY Memory.
Now this leads me to the question of how the ROM can access RAM, for storing variables, etc.
In what I've seen of Ziggurat29's disassembly, it seems the stack-pointer is set-up in a high-address, e.g. 0xff00... and it seems most other variables are stored up there, as well...
So, then, BANK only switches between ROM and RAM in the *lower* addresses, and always accesses RAM in the higher ones... simple enough.
And, again, by treating the RAM as though it's being accessed even when the ROM is, but gating the RAM's /RD signal (/XENRAM), it still gets refreshed.
This custom chip is starting to seem quite simple, really... a few gates.
(As Ziggurat29 pointed out a while-back, the 2x motherboard uses this custom chip, but the earlier motherboards are similar in design but use discrete logic instead... I've been meaning to look at those, but haven't yet. All these ramblings are from the perspective of treating it like a black-box... I guess it's kinda like doing math homework where the answers are in the back of the book... should I go look?)
Whoa Whoa Whoa!!!
that /WR signal is *directly* connected to the DRAM chips! And they don't have Chip-Selects! That's fine for ROM... but...
What the heck happens during an I/O write!?
... "/CAS is used as a chip select activating the column decoder and the input and output buffers."
So, maybe I'm mistaken in the above assumptions that /RAS and /CAS are *always* strobed... Maybe only /RAS is, and /CAS is only strobed alongside /MREQ... oy!
I do, in fact, have a logic-analyzer occupying *exactly* the same space as the circuit I'm curious about... And that logic-analyzer, in fact, samples quite a bit faster than the circuit I'm curious about... THAT would be the logical approach.
This looks quite handy, though I think it's for a KayPro 2, rather than 2x...
11/06/2017 at 12:24 •
1) An image-search for '"Omni 4" "Logic Analyzer"' results in many hits from this project-page... pretty cool. OTOH, it's quite strange, saying that many of the images are "4-5 days ago" that were actually several months ago. (is it 4-5 days ago that Google crawled on 'em?)
2) A resulting-image doesn't show anything related to the OMNI4... so I clicked through to the page to see what Google thought made it relevant... Apparently MAME now comes with the OMNI4 ROM (?!)
"October, 26th 2017" ... "Changelog" ...
"What's new in this version:" ... "New clones marked as NOT_WORKING:" ... "- Omni 4 Logic Analyzer [rfka01]"
A bit more research...
Added as a 'diff' patch 10-15-2017.downloads/mame/mame-0191/
Cool! Glad to see it won't get lost to bit-rot. Is this your doing @Ziggurat29?
...ah... the ROM's not included with MAME's source-code... so I guess it still has to be downloaded from somewhere.
11/03/2017 at 07:33 •
Update 11-6-17-2: Notes on I/O addressing thrown at the bottom.
Updated 11-6-17: Revision with some new understanding...
(Note that we've determined the motherboard is a pretty-much stock KayPro 2x, but it has a custom Boot-ROM and Character-ROM, both of which are available in the "Files" section of this project).
Herein, I'm gonna throw up some notes, as I read-through his work...
(Note that I currently have Zero experience with Z80 assembly-language, and am pretty slow with assembly-language in general, and am unfamiliar with the unit's registers/peripherals... So, this is a great learning-opportunity. Interestingly, this is the same approach I took in learning about the IBM PC/XT architecture, by looking at the BIOS Assembly-listings and schematics in order to determine how to initialize and make use of its peripherals.)
You might want to take a look at the KayPro Service Manual, which contains schematics of the KayPro 2x motherboard.
First interesting note...
The BootROM appears to launch right into external (to the Z80 chip) register-setup... Apparently not much configuration needs to be done within the Z80 CPU, itself.
There is a "system port" register at 0x14 consisting of quite-literally a byte's worth of TTL Flip-Flops whose outputs are fed to various peripherals, most-notably the Floppy-Controller, but also the Character-Generator ROM (and more?). Setting up the "system port" register is the second operation, the first being setting up the stack-pointer, and both are accomplished in only a small handful of instructions. Wild.
UPDATE: The system port (address 0x14), from the schematic:
D0 - /DRV_A (Floppy) D1 - /DRV_B /HD_CTRL_RST (Floppy) D2 - /SIDE_ONE (Floppy) D3 - /PSTROB (Parallel Printer Strobe) D4 - /MTR_ON (Floppy) (via inverter) D5 - /DDEN (Floppy) (Double-Density Enable) D6 - A12CH (Write), [PBUSY (Read)] (Selects the character-set) (See notes in previous log) D7 - BANK (RAM vs ROM?)
(Side-Note: Appears that the parallel-printer port is output-only, and reading the written values is not possible... wouldn't take much modification to make it bidir... strap a '244 atop that '373, and some glue...)
Immediately thereafter, is the version-string "2.01", which gets loaded into RAM. This version-string appears on several screens... E.G. When the unit is turned on, as I recall, it says something like "Omni 4 version 2.01" and also, upon loading CP/M, something like "Omni 4 CP/M version 2.01". (TODO: verify... I thought we had CP/M 2.2..?)
It's interesting to me that these two things are in the Boot-ROM, as I'd've thought CP/M was loaded from the disk (and therefore its version would be dependent on that which was on the disk... like, e.g. DOS 3.3 vs. DOS 6... Or Windows XP vs. Windows 10).
(To-Ponder... The RAM is already being filled with data, including the version-string and the stack, at this point... More, surely, to come... But doesn't this system use DRAM? Doesn't it need refreshing? How about column vs. row-addressing? Is that *all* handled via dedicated circuitry?! (UPDATE: Looking at the schematic, it appears U29, a custom chip numbered 81-194, takes care of this. This chip appears to handle only interfacing with the DRAM and generating a few clock-signals, from 4.9KHz to 4MHz. As (Actually, it has a couple other outputs I'm working out). Ziggurat29 has pointed-out, this custom chip is a new thing as of the '84 versions of KayPro systems like the 2x, the prior versions used discrete logic, which I've yet to look into. Interesting that, at the time, designing and manufacturing a custom 40-pin chip is cheaper than just replacing the DRAM with a 64K SRAM). (An aside: I began looking at the Z80 timing charts, earlier, and noted that there's a "refresh" portion of *every* instruction-fetch bus-transaction... haven't wrapped my head around that one yet... UPDATE: Apparently the /REFRESH output on the Z80 is N/C... hmmmm.... more at the bottom).)
Next comes the bit I, personally, would be most-interested in attacking as quickly-as-possible, and here it is, being attacked as quickly-as-possible... initializing the video-system.
It appears to load 16 values to 16 registers in the video-controller IC... These values are hard-coded in the ROM... And the procedure for writing these registers appears to be to load address 0x1C with a register-select value (0x00-0x0f), then to load address 0x1D with the new value for the selected register... repeat 16 times.
Ziggurat29 notes that apparently register 0x1f is selected (but never loaded with a value?). This, apparently, is not a register on the video-controller IC... Not sure what it does... (Maybe it's a method to assure that should address 0x1D be written, later, it won't accidentally overwrite whatever last-register was selected?)
And, from there a handful of other operations, and... initialization of the video subsystem doesn't seem to be particularly-difficult. And, maybe more importantly, getting to the point of actually displaying a character on the screen is on the order of maybe 100 lines of assembly (maybe 20-50 lines of C code). Not bad, considering that's from the moment of power-up...
E.G. for the PC/XT, in my previous project, to display a character on the CGA card... Well, weeding out what was necessary to do-so from the BIOS listing was quite an ordeal... As I recall, there was easily 200 lines of (executed) assembly just to get to the point of initializing the CGA card, including things like setting up the DMA controller to refresh the DRAM, setting up the floppy controller, interrupts, and quite a bit more that technically aren't necessary for interaction with the video-card. Further, the PC/XT BIOS can handle several different types of video cards (including none), so a significant amount of the code determines (repeatedly!) which card is installed, and more. In the end, maybe it would've taken roughly the same amount of configuration (~100 lines of assembly) to get the PC/XT's video-card running, as the KayPro's, (if you know which card is installed).
(UPDATE: It appears that the Z80's /BUSRQ and /BUSACK pins are unused... No DMA here! This'll certainly make a brain-transplant easier)
Maybe this analysis seems like a strange approach... Well, what if you were writing your own custom ROM just for the sake of learning the system... Wouldn't the first thing you'd want to do be to make something blink? Here, the KayPro (or at least the OMNI4) BIOS apparently does exactly that as pretty much its first priority.
(In my PC/XT project, my goal was to replace the original 8088 chip with one I'm more familiar... an AVR, yahknow, basically an Arduino. That way, among other things, I could use my normal coding-habits to work with the PC/XT's motherboard/peripherals, rather than learning a new language (x86 assembly)... Here, it looks like substituting the Z80 CPU on a KayPro with, say, an AVR, and making use of the KayPro hardware may be *significantly* easier than on a IBM PC/XT... so may be a great learning-platform. (I never did get to interrupts or DMA on the PC/XT).
The big hurdle, still, will be making that AVR compatible with the Z80's bus... Doable, certainly.
(Oh, and, in no way is this suggesting to run the old KayPro's software on an AVR... this is about coming up with your own software to work with the hardware-level stuff... why? I dunno. But, yes, I'm willing to bet an AVR, cleverly-coded, could emulate a Z80, and possibly even execute instructions at roughly the same speed, maybe faster).
I got a bit side-tracked... And I'm stopping, here, with video-initialization, for now.
Please look at the *comments-sections* of the previous logs on this project... Ziggurat29 is apparently brilliant, but has a habit of posting what could be entire log-entries in the comments-sections of my otherwise bland log-entries. That is to say, you can learn a *lot* by scouring in deep dark recesses of this project-page for his comments!
Some highlights from the previous log's comments include a memory-map, and explanation of the interrupt-system. Also, apparently the BIOS ROM shares the same memory-space as the RAM, so when an application is loaded into RAM, the BIOS is effectively removed from the system (?!). Ziggurat29 goes into some detail as to how that may function. Also, it seems he's done quite a bit in disassembling higher-level things such as the operating-system, which I'm obviously a ways from analyzing.
A couple other notables upon browsing the schematics...
There appears to be a header for a light-pen. And apparently building one isn't too difficult. So... oy... I had one once, long before I knew how to program... and had no idea where to connect it on my old PC, so I never was able to use it, and managed losing it. But apparently they're pretty easy to make... and now I know a bit about programming... So an easy distraction to ponder. Though, I could do that just as easily with the PC/XT... and haven't yet. It's kinda curious, here, since this system doesn't do graphics (without some hackery).
The I/O ports are addressed with A2-7, leaving A0 and A1... not exactly unconnected, but almost. E.G. the "system port" D-latch chip is selected by 0x14, that's A4 and A2 high (the rest low). But, since the selection-circuitry doesn't make use of A0 and A1, I'm pretty certain the system port could just as easily be accessed at 0x15, 0x16, and 0x17, as well... The result would be the same.
At first this didn't make sense to me... wasting all those I/O addresses... But now I see, I think some other devices, themselves, make use of A0 (and possibly A1). E.G. the video-circuitry... So e.g. the video-chip's chip-enable is selected by A7-A2 = 0x1C, but then it's also selected when the address A7-A0 is 0x1C, 0x1D, 0x1E, and 0x1F. Its internal registers are chosen with A0/[A1], thus, we have different address-selections on the video card for 0x1C (register-select) and 0x1D (register-value). (Not sure, yet, whether it also makes use of A1 for other registers). Makes sense, and now that I've traced most of that out in the schematic seems totally obvious (haven't I seen the likes of this on other systems... for like... decades now?).
I guess the difference, here, is that the motherboard contains decoders for *all* the I/O devices (onboard, anyhow). Whereas, say, for a PC/XT, each ISA card has its own address-decoder circuitry... That's a lot of duplicate circuitry for a serial port, a parallel port, a floppy controller, a video-card, an RTC, etc. (I suppose why those multi-function cards became so popular, and eventually became a single chip).
Whereas on here, most of those devices are onboard, at fixed addresses, and therefore one set of address-decoder-chips (only two 3-to-8 demultiplexers) can select all those I/O devices.
09/25/2017 at 11:26 •
the serially transferred files are duds.
Apparently pip decided to translate tabs to spaces.... even in binaries, even in binary mode.
On that note... cpmtools seems to work with the disk image when using the kpiv format.
Only one hiccup (besides discovering the tab to space conversion)... a large text file ends with a bunch of 0x1a's... (ascii substitute?) Dunno why, but doubtful they belong there.
09/22/2017 at 05:44 •
u9 appears to be the character ROM... there's a 2732 24 pin EPROM in the socket. Its contents is in the files section, and ziggurat29 decoded it into ascii art. It appears the Omni4 has a custom character set for drawing logic waveforms.
Ziggurat noted that the schematic shows pin 2, a12 is driven from somewhere... (where?). Well the 2732 doesn't have an a12, but the 2764 does... and the 2732 is pin-compatible-enough that it could be dropped in a 2764 socket, if said socket is designed with that intent... which this one is. And that explains the larger socket than the chip...
Ziggurat also noted some code in the bios that seems to support character-set switching (via a12, most likely)...
So my guess is that this was designed with the intent to support two character sets... a normal one for normal stuff... and switching to the custom one for the logic analyzer.
So some tests run tonight:
A12 starts low, upon reset, but goes (and stays) high as soon as the boot title screen pops up... even before the disk is read, so before the os is loaded, and long before the logic analyzer software is loaded...
This seems backwards to me... certainly itit'd be more logical to use the default character set for boot, then switch charsets when loading la.com...
An easy change... for a designer... and another thing leading me to think this guy's a prototype (or they ran out of energy for such a simple change... with the assumption few people would be using a $4000 logic analyzer to play games?). While the change would be simple, it would require modifying both the bios and la.com (and any other related software)... so I can see how a backburner idea like that might've been abandoned...
So... since a12 isn't used on the 2732, and since the 2732 only contains the custom charset, the machine thinks its accessing the custom charset (immediately upon boot and always thereafter) in the higher address space of a 2764... but it's really wrapping around and accessing the lower address space, which is fit in a 2732.
So I guess... if this were something I cared to fix, like if i wanted to play games on this thing, I could load the custom charset in the higher addresses of a 2764 and the regular one in the lower space, as designed... then I'd need a utility to switch to the normal charset every time I wanted to play a game... which would mean not being able to just boot off any floppy.
Or... I could swap it from the presumed-intended design... have the custom charset in the low space and the normal one in the high space... this'd mean having a utility run before the la software to switch to the low space. Could do that in some sorta script, right?.. completely goofy, but a solution that would allow normal disks to boot with the normal charset.
Now... what if there are games, etc. That expect their own custom charset..? Or, maybe weirder, what if some programs reset to the default charset when starting... Who knows.
It definitely looks, though, as if this charset swapping is a thing designed in kaypro 2x's... not limited to the omni 4... but am guessing the choice to set a12 high in the bios is specific to the omni4...
Anyhow, a curiosity.
Probing: A12CH appears to be connected to U58, PIN 16... heading back to the schematic... yep... there it is, sheet D just as it says... dunno how I missed it before.
Replaced the second 5.25in drive with another 3.5... MUCH easier, now, to try out other software... (looking into something that'll transfer the disk contents faster and reliably for viewing on a newer computer).
Not sure where I stand with this thing... I'm starting to get hackish ideas... that can't end well... and... could be done with a normal kaypro, anyhow...
(Seriously: installing a soundblaster has crossed my mind a couple times... maybe I'd better get this thing out of my sight ASAP... I can do stuff like that with #Improbable AVR -> 8088 substitution for PC/XT instead of frankensteining one of the last of an endangered species)
Also... found a disk image online containing ebasic.com... yep. BASIC. so now can twiddle some bits... tried to read the RTC... it thinks it's April 1989. Spose it's possible it wrapped there after y2k... the time's way off. Otoh, no idea whether it was set in this time zone (or at all)... and I'm betting thirty minutes in either direction could easily been lost/gained in thirty years... thing is, the 3v battery still reads 2.7v... so it's probably still trying to keep time. But it seems funny these things even have RTCs... 'cause I haven't found any software that reads it, and certainly none to set it!
09/18/2017 at 00:26 •
Oddities abounded... apparently the KayPro 2x doesn't have a standard serial port pinout.
Key factors include: Only using CTS, and Tx and Rx swapped. I found this pinout in the technical reference manual.
Here's a cable I hacked from a typical null-modem for communicating with a newer PC...
DB25 (M) DB9 (F) 2 RxD 3 TxD 3 TxD 2 RxD 7 GND 5 GND 20 CTS 4 DTR 1 DCD,6 DSR (unnecessary?)
Note that the end-result is very different than a null-modem... weird world.
(CTS <- DTR, NOT CTS <- RTS, was necessary, otherwise the transfer never starts)
Truns out pip doesn't convert *to* ihex, only *from*... well that doesn't help. OTOH, looks like the serial port does infact send 8 bits.
On the PC-side I used 'dd bs=1 if=/dev/ttyUSB0 of=<filename>' (after setting the baud-rate to 300bps (!!!))
On the KayPro side I used 'pip tty:=<file>[o]'
tty: is the serial printer port, and [o] indicates to send the file as binary, so it won't stop early when a byte matching 'end-of-file' is found.
After the transfer completes, the KayPro returns to 'A>'... at which point I type <CTRL>-C on the PC.
The process is *slow*... and pip doesn't say much while it's running... or not (e.g. when the handhaking is not correct, it just stalls... forever?)
So I opened another terminal window on the PC and ran 'ls -l <filename>' repeatedly to make sure that filesize was increasing.
Many files from the disk are now available in the files section, after literally hours of file-transfers ;)
There were some strangenesses during the transfers. I transferred K2X* twice, and verified they matched. LA.COM I transferred numerous times and verified they matched, but the remaining I did not verify. Oddly, unlike the others, their file-sizes didn't match the output of 'D.COM' (which is essentially 'dir' or 'ls'). One I tried twice, both times receiving 4K, when D.COM claimed it was 6K... so I dunno.
09/15/2017 at 16:02 •
A couple days ago Esot.eric dumped the two EPROMS on the board, U9 and U32. I spent a little time with those images, and Esot.eric suggested I share my findings thus far (there is much more to go, but that will take several days work).
U9 is the character generator ROM, and U34 is the 'boot' ROM. Why the quotes? Well, we're pretty sure it is more than just the boot ROM. For starters, a boot ROM would not need to be 8K -- 2K would be more than sufficient to init the system and load the second stage loader off disk (and indeed earlier Kaypros did have a 2K boot ROM), so the current thinking is that it contains other subroutines that are of use at runtime.
The Kaypro is a CP/M machine, and those familiar with CP/M will know that one of it's quirks is that it requires RAM at the bottom of memory. Yet 0000h is the reset vector for 8080 and Z80 (for which CP/M was created), so you've got to have ROM there at least during boot up, and that generally implies some sort of bank switching to get it out once you've gotten past boot. So far, so conventional. Also interesting is that the ROM does not reference any RAM locations below 8000h (even though this one is only 2000h long), so it seems that Kaypro had plans to possibly expand this ROM-based subroutine approach in future models, and set up their codebase accordingly.
I'll cover the disassembly findings in a subsequent post in more detail (i.e., when I have details to post!), but some interesting things have come out already with a cursory scan:
- there are some peculiar register addressings related to video
The video is mostly controlled by the then-popular MC6845 (or clones). This chip has 18 registers, and is interfaced through two physical addresses: the first is the address register selecting which of the 18 internal registers is being operated upon, and the second is the data register that is mapped to the selected register. So far so straightforward, but I noticed in the code many times accessing of a register 1Fh, which does not exist on the chip. Blargh! My mind is boggled.
- to add confusion to befuddlement, there is a physical port 1fh that is routinely accessed in the (ostensibly) video driver code. But this one I think I have more of a handle on:
The video memory on this unit is composed of two 6116 static RAMs, 2K each. Hmm, this device has an 80x25 display, which is 2000 characters, so why do we need a total of 4K? Hypothesis: attributes. 8 bits for character data, and some more bits for things like high-intensity, inverse video, etc. Some of Esot.eric's screen shots show that these capabilities are there, so we know we need the extra bits. Also, the 6845 is essentially a fancy address generator -- you still have to implement circuitry to shift out pixels and blend in sync pulses and whatnot. So, the video memory is typically being addressed and controlled by the 6845 on a continual basis, and not mapped into the CPU's direct address space. But something's gotta let us write data into video memory!
There is a gate array in this machine (actually two). Since it is a custom chip, it is a black box from the standpoint of analysis, and could be doing anything. So, my hypothesis in this case is that the port 1fh is decoded by the gate array, and is used to access the video memory to write characters into it. And probably the attribute bits as well. Much more work will be done in this area.
- As was common on many machine designs, the address decoding may take shortcuts by not decoding some bits and thus creating aliases in the address space. This was typically done simply to save on parts count ($) but was Hell on 3rd party expandability. This was done here as well, and A6 does not contribute to the decoding of port addresses, and so there are IO aliases of the first 64 ports into the 40h-7fh space. Fortunately for the rest of the world, they did decode A7, leaving the upper 128 ports for others, which brings me to my point: I have noticed in the ROM I/O accesses to ports 81h-87h, which are not standard Kaypro 2x ports. Hmm. Ain't that something? It's so obvious now, but it wasn't until I woke up this morning that I realized that the boot ROM is also custom to the Omni4 (over the Kaypro 2x), and that these ports must be part of the logic analyzer daughterboard. Also, because there is customization of the boot ROM, it further suggests that Omni either had a close business relationship with Kaypro to have access to the source code to modify, or they were hackers that reverse-engineered it. My guess is the former, but the latter was not at all uncommon in those days (for fun, search "Michael Geary Adobe Type Manager" to learn about an (in)famous case, and the wrath of the software pusblisher whose code was reverse-engineered). Anyway, my suspicion is that ports 80h-87h (at least) operate the Omni4 daughterboard, and it is very good indeed that we have the ROM dump, because disassembling the code on the floppy would be insufficient. Thanks Esot.eric!
Since it is going to take me several days to analyze and comment this ROM dump, for fun in the meantime I decided to code up a little program to transform the character generator dump into something meaningful to the human eye. Attached herewith in the files section is OMNI4U9.txt containing that result. I didn't think that much of it at first, but Esot.eric believes that some of the graphics characters are non-standard, and are used by the Omni4 software to depict timing waveforms. So, once again, thanks for the dumps, because that will make disassembling the logic analyzer program make much more sense knowing what the special characters look like!
Next, I must weave time between real-world responsibilities and code archaeology, so it may be a week or so before I have the ROM disassembly completed. Or sooner if my burning desires overcome my sense of responsibility -- this has happened before, alas....
- there are some peculiar register addressings related to video
09/14/2017 at 02:25 •
UPDATE: NOPE. See next log...
ziggurat and I have both been unable to fiigure out how to successfully mount the disk (image) on a linux machine using cpmtools. Seems strange... seems like surely enough folk out there use (d) kaypro 2x's that surely the settings should already be in there. But alas, two folk, no go.
The idea, then, is to use pip, the peripheral interchange program, to send the files from the booted disk in the booted machine via serial port to a linux (or whatever) machine. Sounds simple enough...
Unsure how exactly to format the command line, came across this: https://groups.google.com/forum/m/#!topic/comp.os.cpm/f9vzK1OvaII
Wherein numerous caveats I'd vagued upon are brought up... and several I hadn't considered.
First... pip does have the ability to send binary files, but how would the receiver recognize the end of the file, when only 8 bits are transferred at a time, and a binary file can contain *any* 8bit value in any location, including the "end of file" byte...?
So then pip must use a protocol for the transfer, like xmodem, right? Well I don't see that in the manual, it looks like it isn't that sophisticated. Then raw binary transfer... I guess I could have a timeout... or maybe the handshaking lines... dunno.
Then that page made note of something I'd glossed over... pip *does* have the ability to convert an input file to intel hex format. BAM.
Which is also a great idea because: I haven't found anywhere info on how to configure the serial port... yahknow, baudrate, parity, handshaking... which didn't seem like too big a deal until I happened upon anithher comment at that page... default it 7bit! Well shit... that'd put a serious damper on a binary transfer.
So yes... I think intel hex conversion will do quite nicely. Built into pip. And crc's to boot. BAM.