iKarith

Hey all, I'm wondering ... how uncommon are the TI-99/4A manuals in good condition? I ask because I saw some that appear to be in great condition in a currently 0 bids listing on eBay for cheap enough for me to be interested in buying. They're listed along with some carts that probably few people want which I suspect is why the lack of bids. Anyway, it pains me to see books destroyed, and I consider it almost criminal to destroy books that are hard to come by, but slicing off bindings and putting them in a sheet feeder is the best way to get a good, clean scan. And I've seen the scans we've got--they weren't done that way and are consequently not very easy to read as a result. And because they're left as basically large slightly askew pictures of pages, things like mobile PDF viewers crap out trying to zoom in enough to even begin trying to read the often not great text. Rather frustrating, it is. So that's what I propose to do--to slice, scan, and add searchable text. And it seems like that in and of itself might be a worthwhile endeavor. But if others are interested in helping, I think we might be able to take it further and actually remaster those manuals. It's something I've considered proposing in the Apple // community as well, but there's a lot more manuals there and I tend not to see them offered cheaply enough for me to fork over the cash myself ([email protected]@K ***RARE*** !!!STEVE JOBS!!!) so ... that's not real likely. But here at least is what I gather were some of the manuals that would've come with the computer, and they're in good shape, so ought to scan as well as such manuals could. The text blocks should OCR well for searchability and non-skewed black-and-white graphics tend to compress well without quality loss. If the layout can be recreated, text reflowed into logical paragraphs and sections, and figures recreated as vector images ... That'd fully remaster the original manuals, and they could be rendered into other formats like ePub as well. Am I the only guy in the world who really wants that enough to do anything about it though? And am I contemplating destroying something that is rare and in demand because I saw a rare great deal on eBay? Answers to questions like these will inform my decision as to what, if anything, to do about any of this.

I prefer self-contained solutions, and I understand a floppy emulator to require a PEB, a disk controller card, etc. My ideal thing remains some SD-based nanoPEB replacement.

Does this power supply have a "power good" type signal? Possibly not, but that'd be the obvious choice for adding a switch in the console. This is relevant to my interests.

Which message? (Also, I'm still rather new to this forum, don't really 100% know how to use it yet, and find forums in general to be clunky, cumbersome, and not very friendly for someone like me to operate. So I'll try, but it may take an attempt to two.)

That little part would cost me $20 just to get it sent to me. *facepalm* What's really stupid about element14 (and the reason I am inclined to shop elsewhere when possible) is that this large multinational corporation or partnership or whatever the hell it is doesn't want to deal with end consumers in the United States. If you're not ordering 10,000 units of stuff on a regular basis, Newark doesn't want your business anymore. You have to go to MCM now. And MCM doesn't carry most parts you might be looking for. *sigh*

You are right! I checked again, and it was -12 it didn't need. -5 it does need. That's probably why I didn't immediately jump on the picoATX power supply in the first place. Well, that's not going to work then is it?

FWIW, if there were either a DSR written for USB storage or more likely to talk to a program running on a microcontroller that knew how to operate with USB-storage and presented something more compatible to the TI, that could be an option. I think USB storage is probably bigger than the TI really has space for given that 32k expansions are a big deal on the machine. But SD cards can be accessed over SPI and read like a big memory device. Much easier to accomplish that one, I think.

There's always the solution I want to employ: Replace the entire power board with a single signal-level switch and replace the linear power supply with a switcher that is more efficient, runs cooler, and doesn't have 35 year old capacitors that might explode any minute now. I'd considered doing this externally and just feeding the power switch signal back out, but it also comes to mind that a picoATX supply would more than serve the purpose and requires only a 12V brick. Since the TI doesn't need -5V, I kinda like this idea more and more actually.

I think the real trick at some point is going to involve understanding how the IDE interface was done and implementing that with SDHC and a microcontroller. Ideally I think it'd be desirable for the result to look like a CF7+, and I don't yet know enough about how necessary/desirable that is.

As the nanoPEB works without the CF-IDE adapter, I'd say that the 50mA is enough to power the nanoPEB itself, but not that and a CF adapter.

I can certainly head on out to Hillsboro. It'll be a little tight on the MAX because of the repairs, but that shouldn't be too much of a problem once I get as far as Beaverton TC, and I could ride the 58/56 out that far.

Screw beomg am idea guy, I just want working stuff, and I'm both fiscally challenged and have a decided shortage of space. So I want working stuff that's small and cheap. And I can't solder my way out of a paper bag. If I get to the point that I understand it enough that I won't just invent another broken, square wheel, I'm all about learning to work with tools and just submit stuff to the people who are (or play) electrical engineer to verify that I didn't **** it up, and some daring guinea pigs willing to solder up the results. For a guy who can't solder, you should hear my wishlist for my various retro computers. It's a whole pile of custom PCBs. At some point, I'm gonna have to get good with Eagle. I like the all in one approach, honestly. In fact, what I want to do with my TI is: 1. Replace the coffee warmer with a 100% external power supply, the power switch will become a tiny board containing just a "power OK" switch ala ATX. 2. Put the function of the nanoPEB (memory card, serial interface) in the console itself, serial port on the left. 3. Do the RAM upgrade on the 16 bit bus 4. Include the speech chip/ROM in console 5. Have the overclock/RAM delay switches installed as slide-switches just above "Solid State Software" in the vacated coffee warmer space. Slide switches installed with hidden mounting so they look like TI designed it that way. 6. Do the wiring like an art-quality video game console modchip install, superglue and colored wire, etc. 7. Clean up any oxidation. 8. Redo the RF shield so that it's part of the case and opens with it. 9. Replace the screw closure with rare earth magnets that'll keep it closed until you want to pull it open and show off. and finally: 10. Take it with a light LCD to Starbucks and run the thing off a battery, play some Parsec, see who notices. Bring an accoustic coupler and ask to borrow a phone to check my email. And be prepared to actually do it if someone comes up with a phone. That's slightly insane, but it would be COOL, and hot-rodding the hell out of it would be absolutely awesome given the state of the machine I'm working with. Nary a scratch on it, etc. Which means I need to do all that careful figuring out of how to mount everything on a broken down console I'm not afraid to thrash trying to get it right because I don't want so much as a pencil line on this console's shell until I figure out exactly how the result's gonna be done. (The ethernet AppleTalk card for the //e and IIgs, the wifi AppleTalk for the //c, and the internal //c Echo card are amongst my other evil plottings...)

Wow that tree looks like crap. Suggestions for how I could've formatted that better for fixed-width than just setting the font to Courier would be apperciated.

I should have be bunch of them around here, but don't see one now. I might want to pick up a couple of those adapter cables anyway just to have them handy. Maybe ElectricLab and I can at least test continuity flaky joints and redo any that look like the need it. The stacked 32 pin chips just look like a recipe for headache if the soldering is flaky anywhere. The joints look okay to my eyes, if a little ugly based on the nature of piggybacking chips. I keep wanting some kind of spacer under the CF adapter board to keep it from flapping around.That's got to be a source of some problems somewhere. Was serious in the other thread when I said I think there'd be interest in a cleaner design. More interesting problems I haven't really looked at yet: [email protected]:~$ ti99sim-sdl -q [ window with a black screen, must kill -9 ] [email protected]:/opt/ti99sim$ ti99sim-sdl [ WORKS! beeps sound like they're going through a house fan ] [email protected]:/opt/ti99sim$ tree . ├── bin │ ├── convert-ctg │ ├── decode │ ├── disk │ ├── dumpcpu │ ├── dumpgrom │ ├── dumpspch │ ├── list │ ├── mkspch │ ├── say │ ├── ti99sim-console │ └── ti99sim-sdl ├── cartridges ├── disks └── roms ├── spchrom.bin ├── spchrom.dat ├── TI-994A.ctg └── TI-994A.dat 4 directories, 15 files [email protected]:~/Source/ti99sim/ti99sim-0.13.0$ ti99sim-sdl -q [ works, no sound as expected ] [email protected]:~/Source/ti99sim/ti99sim-0.13.0$ ti99sim-sdl [ no sound, locks up on quit ] [email protected]:~/Source/ti99sim/ti99sim-0.13.0$ tree . ├── convert-ctg ├── decode ├── disk ├── doc │ ├── CHANGES.html │ ├── COPYING │ ├── CREDITS.html │ ├── main.css │ └── README.html ├── dumpcpu ├── dumpgrom ├── dumpspch ├── include │ ├── bitmap.hpp │ ├── bitstream.hpp │ ├── cartridge.hpp │ ├── cBaseObject.hpp │ ├── cf7+.hpp │ ├── common.hpp │ ├── compress.hpp │ ├── decode-lzw.hpp │ ├── device.hpp │ ├── disk-image.hpp │ ├── disk-media.hpp │ ├── disk-sector.hpp │ ├── disk-serializer-anadisk.hpp │ ├── disk-serializer-cf7+.hpp │ ├── disk-serializer-hfe.hpp │ ├── disk-serializer.hpp │ ├── disk-serializer-pc99.hpp │ ├── disk-serializer-v9t9.hpp │ ├── disk-track.hpp │ ├── disk-util.hpp │ ├── encode-lzw.hpp │ ├── fileio.hpp │ ├── file-system-arc.hpp │ ├── file-system-disk.hpp │ ├── file-system.hpp │ ├── file-system-pseudo.hpp │ ├── iBaseObject.hpp │ ├── icartridge.hpp │ ├── icomputer.hpp │ ├── idevice.hpp │ ├── idisk-sector.hpp │ ├── idisk-serializer.hpp │ ├── idisk-track.hpp │ ├── ipic.hpp │ ├── isector.hpp │ ├── istateobject.hpp │ ├── itms5220.hpp │ ├── itms9900.hpp │ ├── itms9901.hpp │ ├── itms9918a.hpp │ ├── itms9919.hpp │ ├── logger.hpp │ ├── opcodes.hpp │ ├── option.hpp │ ├── platform.hpp │ ├── screenio.hpp │ ├── stateobject.hpp │ ├── support.hpp │ ├── ti994a-console.hpp │ ├── ti994a.hpp │ ├── ti994a-sdl.hpp │ ├── ti-disk.hpp │ ├── tms5220.hpp │ ├── tms9900.hpp │ ├── tms9901.hpp │ ├── tms9918a-console.hpp │ ├── tms9918a.hpp │ ├── tms9918a-sdl.hpp │ ├── tms9919.hpp │ └── tms9919-sdl.hpp ├── list ├── Makefile ├── Makefile.linux ├── Makefile.macosx ├── Makefile.win32 ├── mkspch ├── Release ├── roms │ ├── cf7a+.bin │ ├── cf7+.dat │ ├── Gram Kracker.dat │ ├── Mini-Memory.dat │ ├── spchrom.dat │ ├── TI-994A.dat │ └── tiworkshop379.dat ├── rules.mak ├── say ├── scripts │ ├── dsk2cf7 │ └── dsk2dsk ├── src │ ├── console │ │ ├── gpl.cpp │ │ ├── Makefile │ │ ├── Release │ │ │ ├── gpl.dep │ │ │ ├── gpl.o │ │ │ ├── screenio.dep │ │ │ ├── screenio.o │ │ │ ├── ti994a-console.dep │ │ │ ├── ti994a-console.o │ │ │ ├── ti99sim-console │ │ │ ├── ti-main.dep │ │ │ ├── ti-main.o │ │ │ ├── tms9918a-console.dep │ │ │ └── tms9918a-console.o │ │ ├── screenio.cpp │ │ ├── ti994a-console.cpp │ │ ├── ti-main.cpp │ │ └── tms9918a-console.cpp │ ├── core │ │ ├── bitstream.cpp │ │ ├── cartridge.cpp │ │ ├── cBaseObject.cpp │ │ ├── cf7+.cpp │ │ ├── compress.cpp │ │ ├── decode-fm.cpp │ │ ├── decode-lzw.cpp │ │ ├── decode-mfm.cpp │ │ ├── device.cpp │ │ ├── disassemble.cpp │ │ ├── disk-image.cpp │ │ ├── disk-media.cpp │ │ ├── disk-sector.cpp │ │ ├── disk-serializer-anadisk.cpp │ │ ├── disk-serializer-cf7+.cpp │ │ ├── disk-serializer.cpp │ │ ├── disk-serializer-hfe.cpp │ │ ├── disk-serializer-pc99.cpp │ │ ├── disk-serializer-v9t9.cpp │ │ ├── disk-track.cpp │ │ ├── encode-lzw.cpp │ │ ├── fileio.cpp │ │ ├── file-system-arc.cpp │ │ ├── file-system.cpp │ │ ├── file-system-disk.cpp │ │ ├── file-system-pseudo.cpp │ │ ├── Makefile │ │ ├── opcodes.cpp │ │ ├── option.cpp │ │ ├── Release │ │ │ ├── bitstream.dep │ │ │ ├── bitstream.o │ │ │ ├── cartridge.dep │ │ │ ├── cartridge.o │ │ │ ├── cBaseObject.dep │ │ │ ├── cBaseObject.o │ │ │ ├── cf7+.dep │ │ │ ├── cf7+.o │ │ │ ├── compress.dep │ │ │ ├── compress.o │ │ │ ├── decode-fm.dep │ │ │ ├── decode-fm.o │ │ │ ├── decode-lzw.dep │ │ │ ├── decode-lzw.o │ │ │ ├── decode-lzw.dep │ │ │ ├── decode-lzw.o │ │ │ ├── decode-mfm.dep │ │ │ ├── decode-mfm.o │ │ │ ├── device.dep │ │ │ ├── device.o │ │ │ ├── disassemble.dep │ │ │ ├── disassemble.o │ │ │ ├── disk-image.dep │ │ │ ├── disk-image.o │ │ │ ├── disk-media.dep │ │ │ ├── disk-media.o │ │ │ ├── disk-sector.dep │ │ │ ├── disk-sector.o │ │ │ ├── disk-serializer-anadisk.dep │ │ │ ├── disk-serializer-anadisk.o │ │ │ ├── disk-serializer-cf7+.dep │ │ │ ├── disk-serializer-cf7+.o │ │ │ ├── disk-serializer.dep │ │ │ ├── disk-serializer-hfe.dep │ │ │ ├── disk-serializer-hfe.o │ │ │ ├── disk-serializer.o │ │ │ ├── disk-serializer-pc99.dep │ │ │ ├── disk-serializer-pc99.o │ │ │ ├── disk-serializer-v9t9.dep │ │ │ ├── disk-serializer-v9t9.o │ │ │ ├── disk-track.dep │ │ │ ├── disk-track.o │ │ │ ├── encode-lzw.dep │ │ │ ├── encode-lzw.o │ │ │ ├── fileio.dep │ │ │ ├── fileio.o │ │ │ ├── file-system-arc.dep │ │ │ ├── file-system-arc.o │ │ │ ├── file-system.dep │ │ │ ├── file-system-disk.dep │ │ │ ├── file-system-disk.o │ │ │ ├── file-system.o │ │ │ ├── file-system-pseudo.dep │ │ │ ├── file-system-pseudo.o │ │ │ ├── opcodes.dep │ │ │ ├── opcodes.o │ │ │ ├── option.dep │ │ │ ├── option.o │ │ │ ├── stateobject.dep │ │ │ ├── stateobject.o │ │ │ ├── support.dep │ │ │ ├── support.o │ │ │ ├── ti994a.dep │ │ │ ├── ti994a.o │ │ │ ├── ti-core.a │ │ │ ├── ti-disk.dep │ │ │ ├── ti-disk.o │ │ │ ├── tms5220.dep │ │ │ ├── tms5220.o │ │ │ ├── tms9900.dep │ │ │ ├── tms9900.o │ │ │ ├── tms9901.dep │ │ │ ├── tms9901.o │ │ │ ├── tms9918a.dep │ │ │ ├── tms9918a.o │ │ │ ├── tms9919.dep │ │ │ └── tms9919.o │ │ ├── stateobject.cpp │ │ ├── support.cpp │ │ ├── ti994a.cpp │ │ ├── ti-disk.cpp │ │ ├── tms5220.cpp │ │ ├── tms9900.cpp │ │ ├── tms9901.cpp │ │ ├── tms9918a.cpp │ │ └── tms9919.cpp │ ├── Makefile │ ├── sdl │ │ ├── bitmap.cpp │ │ ├── main.cpp │ │ ├── Makefile │ │ ├── Release │ │ │ ├── bitmap.dep │ │ │ ├── bitmap.o │ │ │ ├── main.dep │ │ │ ├── main.o │ │ │ ├── ti994a-sdl.dep │ │ │ ├── ti994a-sdl.o │ │ │ ├── ti99sim-sdl │ │ │ ├── tms9918a-sdl.dep │ │ │ ├── tms9918a-sdl.o │ │ │ ├── tms9919-sdl.dep │ │ │ └── tms9919-sdl.o │ │ ├── ti994a-sdl.cpp │ │ ├── tms9918a-sdl.cpp │ │ └── tms9919-sdl.cpp │ └── util │ ├── convert.cpp │ ├── decode.cpp │ ├── disk.cpp │ ├── dumpcpu.cpp │ ├── dumpgrom.cpp │ ├── dumpspch.cpp │ ├── list.cpp │ ├── Makefile │ ├── mkspch.cpp │ ├── Release │ │ ├── convert-ctg │ │ ├── convert.dep │ │ ├── convert.o │ │ ├── decode │ │ ├── decode.dep │ │ ├── decode.o │ │ ├── disk │ │ ├── disk.dep │ │ ├── disk.o │ │ ├── dumpcpu │ │ ├── dumpcpu.dep │ │ ├── dumpcpu.o │ │ ├── dumpgrom │ │ ├── dumpgrom.dep │ │ ├── dumpgrom.o │ │ ├── dumpspch │ │ ├── dumpspch.dep │ │ ├── dumpspch.o │ │ ├── list │ │ ├── list.dep │ │ ├── list.o │ │ ├── mkspch │ │ ├── mkspch.dep │ │ ├── mkspch.o │ │ ├── say │ │ ├── say.dep │ │ └── say.o │ └── say.cpp ├── ti99sim-console └── ti99sim-sdl 14 directories, 275 files Now I'm confused. Something is being directory-dependent, but what? Hmm.

Thanks Al. It's not that I don't mind discussing and debating these things--I'm always up for a good argument, and I'd like to think I'm usually level-headed enough to acknowledge the failings of "my side" (which exist and are quite numerous especially lately.) But I think I don't really want to mix that with retrocomputing too much. Retrocomputing is what I do when and because I need to recover from the outrages and idiocies of the world around me. Code is not left or right. Code is not liberal or conservative. Vintage MPUs are easy and their agenda is only to do cool things, if you help them. A person might be surprised that a lot of things are still legal, and I might tend to agree with that surprise a lot of the case, but what is, is, and what isn't, isn't. What you do about any of that is your business. But that's not here. Unless y'all are working on some super-sekrit governmentproof uncrackable encryption that runs on 8 and 16 bit CPUs. with SD and CF card storage. In which case, dude, I wanna check that out!

Teacher hat on, the best learning tends to happen when the kid doesn't know it's supposed to be "work". Sweeeeeet.

I would just like to say for the record that mixing of computers as old as I am and things containing explosives is relevant to my interests. The cassette motor control should be well suited to the task of triggering the ignition. I don't know enough TI BASIC to know how you'd do it from there or if it could be done from there. That said, if the secret sauce for controlling the optoisolator can be provided, I'd strongly encourage writing the software yourself. I've managed to get a little graphics and sound out of the TI's basic BASIC, manual in front of me, and it's exceedingly satisfying to make it do something myself, even if I was just diddling around. Doing that and then making it launch a rocket? How frickin' sweet would that be?! Use the motor control to drive a transistor to handle the larger current needed by the rocket igniter. Might take putting a couple of things together to do it, but I'm sure there's folks that can tell you if you're doing it right with a quick schematic and a little info about the voltage and current that's going to be across the contacts. And remember, launch video or we won't believe it happened.

I'm not gonna rag on someone I don't know, and I've seen some truly ugly mods done. And his soldering is doubtless better than mine would be! I'd like to do some mods to my own console, or perhaps to a beige one as a test that can be messed up in the process of getting it right before I do it on my pristine-looking black/silver console. I really want to do them right though, because I'd like to show off the result as something I can be proud to own. But a lot of folks just want to make it work. And sometimes good enough is good enough. (Except when it isn't, as you note.) I do wonder though, looking over the nanoPEB a little closer. I've seen an IDE interface circuit for the TI. I've seen RS-232 interfaces. And I've seen RAM upgrades as well. I kinda get the idea that the nanoPEB is just those things combined into as small a package as the developer could put them, with the CF7+ being the same but with a parallel port instead of serial. Perhaps I'm the wrong person to be talking about this being both new and being exceedingly poor with a soldering iron unless or until I can start developing adaptive techniques for people who are blind as a bat with a temperature-controlled iron. Still, it seems like even I could put those schematics into some software and start looking at how to optimize things a bit and beginning to design an open-hardware alternative. I couldn't finish the job alone, and I don't yet understand the architecture enough to know whether I was doing much right or wrong, but it could be worth doing I think. I dunno how much interest there is, or rather how much interest there is by people who could actually help do it right anyway. But it seems like it might be really cool. Get it where we want it and we could probably have a small quantity capable fab produce a group buy batch of them with their nice pick-and-place machines so all the small soldering is done by machines that are less likely to do it badly. Probably folks would still need to solder a couple things like edge connectors themselves. Am I crazy? (Wait, don't answer that...)

I note that I have seen in-console 8 bit RAM expansions. Presumably the amount of soldering is less? I've also heard that both have been done on carrier boards and I saw instructions for piggybacking or deadbugging (or one of each?) the chips to do the 16 bit RAM upgrade. Do the RAM upgrades physically occupy the same address space, and how does that work? See, that's part of the problem, I know just enough to be confused by these things.

Those nice folks at FestWest would've likely told me that and shown me all about how to do it and all, except I asked ElectricLab to borrow the thing "at some point" for writing a n00b howto with it after we got back to Portland and were like four blocks from home. And he and I haven't gotten together since so he could show me anything about using it yet. ElectricLab picked this one up because (IIRC) he killed the serial port on his, and it'd be useful to have another around. It was mentioned that this one has some issues that could be addressed, I do recall that. I just figured I'd have a go at it and see. Turns out that while I know I have a power supply that'll fit it, I don't know where I have a power supply that fits it. Looks to be 5.5/2.5mm, and I know I have a few of those, but one doesn't come to hand at the moment. So I'll have to play with this later. In the meantime I should be able to extract the CF card from it and try ralphb's tools to see if I can poke at the contents. If I can get TI-99/Sim going, that'll be something to play with virtually for now, and when ElectricLab and I get together we can get real hardware to cooperate. I think xvm99 is a big part of the solution for anyone who has a working nanoPEB or CF7+ from my OP.

On a Raspberry Pi actually. But my other computer made this decade is a Mac.

From what I can tell, it's just a case of the guy who made the CF7+ and nanoPEB not wanting to do them anymore. The boards are a little static sensitive and I've heard speculation that issues related to static-caused problems may have something to do with that. I guess a couple of people have asked if he doesn't want to do them anymore if he'll release the documents needed to make/program new ones, but he didn't respond. I think there's enough interest that more could be made, if the necessary bits needed were released or reverse-engineered. I'm not the guy to do it as I don't understand the architecture well enough to even understand RAM expansions on the 8 vs. 16 bit bus and why anyone would want the former if the latter is possible. That all said, I'm new around here, so someone may reply with a major correction to sone or all of the above. It's just what I understand, to the best of me understanding it.

I've hit my first snag, I think: I connected the nanoPEB and turned on the console… sounds like a touch-tone is being pressed and there's no picture at all. If I disconnect the CF daughterboard it comes up fine. But with the daughterboard present, no such luck. I notice a DC barrel connection on the back of the nanoPEB, and the daughterboard looks like a standard IDE to CF reader part. I'm wondering if external power is required. I probably have a power supply that'd work, having plenty of standard 5v and 12v bricks laying around here, but I don't know if that's the problem or not. I've looked for documentation and find references back to the "no longer available" page for the CF7+/nanoPEB. Help/manual please? I also tried to get TI-99/Sim running last night on the RPi. Comes up with no sound, and it doesn't seem to want to exit, requiring a kill -9 to get it to close. If I can get TI-99/Sim working, it appears to include some tools for accessing and converting files from the CF7+ image format. I'm totally out of ideas with that—tried compiling my own, but that didn't help much. I could use a hand with that too, but real hardware at least I have some idea what the problem might be. The emulator? Ya got me, without poring over the code I couldn't guess. And it's SDL1.2, too, so other than the fact that most of the code for RPi using SDL uses 1.2, I couldn't guess at what the problem is. Once upon a time, I actually maintained those SDL packages for Debian. Sound was much easier back in those daze. Any ideas or pointers about anything would be REALKY appreciated, I'm stuck.

This was really cool at FestWest. What other retro computer can say, "yes, we transfer data using LASERS! Muahahaha!"

Hi everyone, I'm pretty new to the TI since I picked up a (just about pristine!) silver console at Goodwill a few weeks ago. I'm legally blind, so I'm actually pretty glad that probably most/all of the manuals I'll want to read are probably scanned as PDF. Some of you met me last weekend at FestWest, I'm the albino/tomato who came with ElectricLab. Definitely closer to tomato by the time I got home, but was totally worth it. I had a blast, and any of you who are in the area and haven't been, you should totally go next time! I'm not totally new to retrocomputing--I do Apple stuff and actually work on Raspple II with IvanX, which is where we take a Raspberry Pi and turn it into a cheap peripheral for 1MHz computers. BECAUSE WE CAN. It's a pretty efficient way to get software onto our beloved machines. Dunno if the same kinds of things are possible for the TI yet. I did borrow the nanoPEB ElectricLab bought at FestWest and will probably buy it from him when I'm less economically challenged, but what I've been able to glean so far suggests that all of the tools I'll want for loading the CF full of stuff are DOS/Windows. I can probably use dosbox for the former, but as the Pi uses an ARM chip, WINE isn't likely to help with the latter. Other options I don't know much about yet. Anyway, I'd like to sort this out, and if I can I'd like to begin writing/revising a n00b howto for the TI. If it winds up being doable on the Pi, maybe we can even cook up something like Raspple II for it eventually, though I've got lots of todo items right now, so a howto may have to serve for the time being. Whadda y'all think?