iKarith

The TMS 5220 is capable of making fair approximations of the phonemes in question. The question is whether it has sufficient means to produce the sound. Remember that the Speak & Spell would say a word like echo as "EH-Oh", despite the chip being quite able to make the sound desired. The chip isn't incapable of making the sound but the chip doesn't program itself. It needs a ROM and some direction. And the lowly Speak & Spell doesn't have the means to provide the speech data needed to make a better "EKoh". The best you're going to get is basically 8 bit audio quality, but how good that audio quality is will depend on how low of a level you're willing to program the chip, and how much memory you're willing to devote to making it sound the way you want it to sound.

Oh, it could definitely do the rendering. You just don't want it to do the full rendering. I would much rather have the documents ultimately in ePub format, which might be worse in terms of the fact that is supposed to be zipped.

Could render the text for sure.

Did he smash an Intellivision!?

I'm also new to using this forum, but not to retrocomputing the Apple // and certainly not to using Apples. Welcome!

Cool, always looking for more people who are basically local. Kinda contemplating trying to find Portland people and get together in say the community room in my fiancee's building for a quick get-together and trial balloon for a mini-KFest for the region in the fall. Folks have expressed interest in a West-coast thing from as far away as Seattle and San Diego, but if we can't get Portlandia folks to show up, it'll be a bit tougher to get a larger group. The issue is that I know half of the Portland folks who might come to such things are pretty busy and have a hard time committing to regular events, so I don't think I could talk them into a Portland A2UG. We do have the retrocomputing group in Canby (I can't get there this month as I don't drive and haven't even tried to find people who are going yet) and we have the Commodore 64 folks the day before out in Beaverton. Is there really room for an A2UG? I'd go, but I have no life and can really only go out at night anyway. Maybe in the future. For now, trying to get people local together once, and then organizing something a little more ... more in the fall.

Okay, with that solved, back on topic! What I find is that you really want some solid thing to grab hold of when disconnecting the nanoPEB from your expansion port. If you were to create a vaguely 3 inch square tray and cut holes for power and serial in the back and the card edge connector in the bottom and just have that much extra attached to the nanoPEB to give you something to hold on to when disconnecting the thing, that'd be something significantly useful all on its own. If you made that "tray" a little bigger than it needed to be at the top and bottom, you could create a U-shaped shelf under the CF board that would serve as a bed for the CF board to lay on. There's a couple SMT parts in the way of such a bed being quite flat, but it's easy enough to leave some space for them. This keeps the CF board from flapping inward toward the main nanoPEB board. The top cover will provide some mechanical retention to keep the CF board from flapping away from the nanoPEB's main board, from being pulled out of the IDE connector, and give you something to resist your effort to extract the CF card. Normally I'd prototype something like this using foam core, but the nanoPEB is reported to be somewhat static sensitive (among other nuisances), so, yeah that's a problem. I then got on to the idea of using coroplast. And actually, that makes sense as more than a prototype material! If the pieces are cut with some thought to aesthetics, the channels won't be too annoying. A box to hold a 3 inch square board whose edges are solidly glued will be tougher than most 3D prints and a helluva lot cheaper to make too. And finally, I assume most of you guys can manage a sheet of coroplast, a razor knife and good straight edge, a hand drill, a hot snot dispenser, a tube of silicone, and a plasticard scraper. Besides that, THIS! IS! HOMEBREW! Somehow I figure 3M Command picture hanger technically-not-velcro can actually hold the thing together. That stuff's tougher than you expect. Thoughts?

I can now catalog the disk by doing "OLD DSK1.CATALOG" and then RUN. Weirdly, OLD and even DSK1 seem to work lowercase, which is why I didn't think it mattered. The CATALOG program fails on DSK3 with a bad subscript somewhere. I wonder if that means there's something not right with the volume? Either way, it seems there's not a lot I can do with it until I have a better BASIC. The lack of a backspace on that keyboard is really annoying, and the fact that there is no function that serves the purpose in TI BASIC ... Ugh. Ctrl-H doesn't even work. I have discovered that left does, if followed by DEL. Is this corrected in other BASICs?

Mine rarely has anything interesting. It just had this one little TI, one time.

That's my problem as well. I'm working on a solution, but I think ultimately what I want are some small/cheap restaurant shelves big enough to hold the machines I'm not actively using now, and then space for one machine that is always connected. That machine would be my IIgs, which these days gets mostly used for testing joysticks and discovering that yes they are indeed in need of replacement buttons. *grumble*

Yeah but the point is that the modified image on asimov now has value all by itself even if you have a clean copy handy (or make one as you suggest.)

I'd argue that if you really want a SID in your TI, you have a great argument for one of the newer SID recreations. In a TI it doesn't have to be "exact" sound to either the 6581 or the 858x chips because we don't have the games that use them, though the newest chips are actually pretty close approximations of the 858x I'm told. (I haven't heard one yet.) The big thing with the Commodore chips is that the SIDs are wanted also by musicians despite the fact that the recreations serve them quite well and are arguably better for their purposes anyway. The VIC II chip, like the SID, is simply not available anymore and is a chip frequently damaged by thermal runaway in the craptastic US Commodore power supply. Not only that, only a couple of mods are needed to turn a European C64 into a US model, the first step of which is to obtain a US VIC II chip. As a result, both of these chips are needed for far more than the original machines. Add to that the problem of all but the earliest US power supplies being ticking time bombs that feed 7.5V into 5V chips (DRAMs don't like that at all, and other chips aren't much happier about it), you can pretty much expect there to be a need for replacements that far outstrips supply of these no longer manufactured parts.

I think I've got the idea, so far as my interest in such things goes for the time being.

@ElectricLab, even worse, the 9th is the PDXCUG meeting, and the 10th is the retrocomputing group in Canby. Looks like you're missing all the fun this month. I'll report anything interesting that comes up at the Commodore group since I can get to that one. Canby's a bit far to walk for me, though, and I haven't even tried to look for a ride down there so probably won't have a chance before the July meeting.

I understand GROM/GRAM chips work like the Apple // slinky cards where a read from them advances to the next address automatically? I also understand the FR99 does not support these kinds of images at the moment, so RXB and XB2.7 need their own carts. Am I beginning to understand this stuff?

Arrrrr! Thread hijacked, cap'n! The thing they should have done would be to archive the data in a format that could be read with minimal hardware so that anyone with a computer that can take a bit stream is capable of building with simple tools the means to read the data. Magnetic media seemed to be all right in 1986, but if magnetic media ever went out of fashion... USB seems good today, but again, if USB ever goes out of fashion... ROMs degrade in time, so that's not ideal either. Today, I'd argue the best format ... is an archive-grade printing process on to plastic media using a QR-type technology printed just large enough that it can be read by discrete electronics components if someone were to build the shift registers to do it line by line, or using a single sensor on threaded rods being stepped through page by page. Anyone NOT trying to do it for an exercise or trying to recover from doomsday will use a camera sensor and process the image optically. A human with a magnifying glass could likewise, with time and effort, if the technology to develop the electronics needed to be recreated from scratch. My "day job" of sorts is preparedness. I think about these things. In fact, it's another reason to appreciate the retro computers: If you can find a way to get data in and out of them in the modern era, they are something that could be understood down to the transistor level and recreated if necessary. They can also be created in small, ultra-low-power cores now that can run on miliwatts of power and be heavily shielded from things like EMP. In fact the idea of an 8 bit machine with a high quality LCD display in a hardened GRID-like enclosure with some thoughts to being able to interface with the world as if it were one of only a handfull of computers a person would ever likely see again... I'd like to own that. Of course, people have piles of legacy data out there they never thought about the possibility that they wouldn't be able to access forever. And now we've reached a point where it takes puddle jumping to bring some of it into the modern era, and people don't have the time/money to do it themselves. So they're paying other people who specialize to do it for them. Great business plan if you got into the game on the ground floor a few years ago because the people who did are now trusted names in that sort of business now that the world is catching on to the idea of needing the service. And that's why any proper doomsday-proof data storage technique ultimately has to be readable by humans, printed using ink that cannot bleed, smudge or fade on paper that cannot be easily waterlogged, torn, or mildewed along with a printed tech note defining the archive format in a carefully printed, bold, OCR-friendly slab serif font. Iconsolata at a weight half between Regular and Bold is a good example of what I have in mind. As I saw starting to say before, it should be possible then to build an apparatus that holds the book open and runs over the optical data using a couple of motors, limit switches, and a pair of threaded rods. Some very simple logic (or equivalent logic in the cheapest of microcontrollers set should be able to begin reading data. The reader homes, then scans to find the page block origin. Stepper motors would allow you to just read the timing info once and figure out how many steps to the bit. A DC motor requires more logic to generate a timing signal. The block is then something like a QR code with the read head reading through a small hole so that it can have more precision than you'd normally get with a scanning head like this you'd build out of parts they actually still sell at Radio Shack along with a bit of low precision stuff from Home Depot. It could be read by the eye using a reading aid that follows the timing marks on the page, which should be a standard size.

As I tell balrog every few months or so much to his annoyance, MAME is still and probably always shall be a MESS. It's unavoidable in a project that size. That said, MAME's current build system is a very limited fork of an old version of another build system that enjoys more widespread support (and now has the same major features of the fork anyway...) I've been quietly rooting for them to convince BGFX's author that it's time to un-fork that and do so themselves. My last bit of lobbying was to rename all the C++ .c files to .cpp, which you'll notice did happen in time.

I'm still contemplating where to put the VGA and audio connectors exactly. I like the idea of installing both. This isn't a near-term hack for me because I'm still far too much a n00b and need to get to a point that I can adequately use what I've got first.

That didn't appear to be the issue. I assume there's a problem using TI BASIC with the catalog program since the error is exactly the same, in line 50. Or old dsk1.catalog is not how you load it. It didn't like run dsk1.catalog at all.

I do ... is that going to be an issue? Or was there a workaround?

Using that device, you'd probably use a short IDE cable rather than the set of adapters that are plugged in now. I probably should note that there is the possibility the SD adapter won't work actually, since the nanoPEB/CF7+ manuals make it very clear that compatibility is ... limited. I was just off trying to see if I could do something useful with the thing prior to some form of XB being available with it. Not really--can't even seem to use the catalog program. That might be that I actually just don't know what I'm doing, but I get some kind of I/O error in 50. I suspect it's trying to do something TI BASIC doesn't support. I need to ping Greg about an ETA.

Yeah, THIS should do what you want. Finagling the IDE connection the right way around is a thing you'd have to cope with, and the SD card would have to be in the raw format just like the CF currently needs to be. But it ought to work. The thing that's there now is a pretty standard Syba CF to IDE adapter.

The use of the ribbon cable was what I was considering. The board hasn't got any mounting holes however as it is meant to mount into a motherboard's IDE connector directly. You'd want a male to male 40 pin IDC ribbon cable and you'd have to then mount the board with retention clips. Doable, but annoying. A stacking 40 pin header (wire wrap socket essentially) would probably push it back enough to have the card coming out the back next to the D-sub, but that'd make the whole thing mechanically pretty precarious. You could also replace the CF board with SD. I'd seriously consider doing so if the filesystem were FAT32. I happen to know that at least newer Sandisk SD cards will, if you leave some space unpartitioned, use that as extra unused blocks for wear leveling and bad block remapping. Using the memory device raw as we are, it can't do that.

Okay, so I took lots of pictures, let's see if I can attach one. Okay, so there's the nanoPEB itself. (This is clumsy.) The first problem is that the CF adapter doesn't have the CF card stick out the back. Well, that's one of a couple problems actually. The other is that the CF IDE board is just flapping around there. That won't hurt anything, but it makes me nervous. You can see in this picture that it can and will touch the top of the piggybacked chips. When it's not doing that, there's about 1/8" between the top of the chip and the bottom of the CF IDE board. Note there's a couple SMT chips that hang down lower that that, but there are no components between the chip on the nanoPEB and the PCB of the CF IDE board. This last pic shows the other problem: the CF IDE board sticks down below the nanoPEB a hair. Just about 1/64" as it turns out. That may be within tolerance of a 3" square enclosure. Of course I'd recommend larger than that because the main PCB itself is 3" square and the DE-9 completely protrudes beyond that, as does the power jack. The real issue here is: Should the CF IDE board be fit into the enclosure the main PCB fits into? If so, it's got to be thick enough for both boards and is going to have to be open in some way. If not, there's room for a layer of plastic between the two boards that can provide a solid shell around the main board and be drilled/cut for the switch, edge and IDE connectors, and the power and De/DB plugs at the back. That leaves the CF IDE board exposed, but a cover can be attached over that. Or as I have seen a couple of folks do, the enclosure for the whole thing needs to be much shorter on one end with a notch so you can get the CF card out. (That or something to extend the IDE connector to push the second board back—doable, but it makes mechanical stability a much bigger deal. Thoughts? Y'know, aside from that Tapatalk is annoying and overly complicates things. Sent from my iPad using Tapatalk

Okay all, I was just about all set to post a nice thread about building a case for the nanoPEB with pictures and measurements and all, but apparently from tapatalk on my iPad where all the pictures I took were, you CAN'T. Having an account with the forum wasn't enough, I had to create a tapatalk account. And I did that, and now I don't have permission to post a new topic. I have permission to reply though, so here's the stupid [CENSORED] [CENSORED CENSORED CENSORED] [CENSORED]ing [CENSORED CENSORED] post in a web browser so I have something to reply to. Have I mentioned I hate tapatalk? And I hate forums on mobile devices? And that I don't use forums often because I tend to use mobile devices a lot, and I can't SEE what I'm doing without the stupid app which doesn't work right and sure doesn't act like a forum? Grrr...