iKarith

FWIW, the usual classification of Zelda-type games is Action RPG due to the mixing of the two genres. Hoping we end up with a map editor in the end so that this can be not just a LoZ recreation (which will be awesome and I'm definitely glad to be one of the first to try it), but also something a little more unique for the TI.

40 watts for a desktop computer? Um, my desktop has a CPU with a 77 watt TDP all on its own. Granted it's not "entry level", but it's also not a gaming powerhouse with multiple video cards and whatnot. Dell called it a Windows 7 workstation-class machine. That's one of the cool things about retro systems. The Apple IIgs had a 68 watt power supply, and while some people criticize the power supply for the IIgs was something like 68 watts. Now, people describe the power capacity of the IIgs as "weak", but that's actually the result of the skinny power traces running to the expansion slots on the motherboard and the fact that all drives and whatnot ran off the system CPU. The reason why current OSes and software run well on 4-5 year old computers decently is that the hardware makers have been focusing on recapturing the low power performance. Intel's NUCs are like under 50 watts total with a monitor, which is perhaps what the above spec sheet is suggesting: A solid-state NUC.

I got started doing the Apple II stuff specifically because, being legally blind growing up, the Apple II wasn't "obsolete" for most of my childhood. I was still using one in the 90s because it had speech (TMS 5200/5220 actually) in the form of an Echo card, and since nearly all software to do useful work on it was text-based, it was easily modified to use the primitive texttalker screen reader. Used it right up til 1995 when I got a 486 PC as a graduation present.

For Debian, I'd just need to avoid the Keyspan firmware issue. Keyspan has licensed the firmware to their USB-Serial dongles (really just braindead Intel microcontrollers with bare-bones microcode) as able to be distributed with Linux or i n a Linux distribution. Debian does not distribute that firmware at all, not even in non-free. Because Debian doesn't include firmware in the kernel package itself, and non-free is defined by Debian (but nobody else really) as not part of Debian even though it's part of the Debian FTP archive. Since Debian says it's separate, it's separate, and Debian has no license to distribute this abandonware firmware. Which means unless you do some research and install the files by hand, the very popular for Mac users serial dongles made by Keyspan are paperweights on Debian. Other distributions are less paranoid--the intent is clear and when you wind up arguing the definition of undefined words in a contract, the licensee is going to win. If I can get them to make the permission general enough to cover the use of the ROM code for education and hobby purposes, including emulation of the computers in question, that'd be ideal. It'd still be non-free, but we'd put the relevant files into a package named ti99-roms which would be depended upon by ti99sim in contrib. I did package the Keyspan ROMs for Raspple II. If Debian can say that non-free is not part of Debian and that means they can't distribute it, I can say that it is part of Raspple II so I can. Any license at all gets it into my packages, but if they're ever to find their way into Debian/Raspbian proper, something Debian is okay with for non-free is required. That they won't get sued is not enough for Debian--they insist on absolute paranoia such that no reasonable person could fathom it's even possible for them to be sued.

Which is not a lot of help on a Raspberry Pi with an ARM CPU...

I do emergency preparedness and other retrocomputers. I have taken over a project for the Apple II called Raspple II and am slowly rebuilding it from scratch. I have plans for expanding that project to encompass other retrocomputers I use.

There seems to be some pretty large gaps I think we could fill in. Contents of the page jump from generally encyclopedic knowledge of the basic console and the TI-99/8 and Geneve and jumps straight into things like using dd to twiddle SCSI devices from Linux. And that's kind of it for the whole topic of talking to the outside world. I think Roland's intro video covers a lot of the basics. A transcript of that could be expanded upon (with backlinks naturally) across a few pages. While I'm good at writing individual sections, I'm not the best person to organize the results. That sounds more like Omega's domain. Isn't there some saying about how it takes a village to raise an idiot or something like that?

I realize the TI has not got +5 to the port. In fact I said so three messages above. If you add an external powersupply, it'd work. If you don't, it won't. That's why I'm planning to rewire some NES controllers as SMS controllers--those will.

That is correct. Unless they have granted permission for a particular type of use, then permission must be freshly obtained for each new thing/person doing the distributing. Thanks for digging up the contact info. After I've had some sleep, I will begin composing a letter. These things work best in my experience when they're short, but they need to be specific enough that a simple affirmation in reply being sufficient.

The usual Atari adapter is all you need, if pin 7 has +5 on it. I'm actually considering wiring up some NES controllers to work on the TI, Atari (SMS mode) and possibly switchable to Atari 7800 mode.

That'd be a nice feature, but in the meantime, info can be extracted into wikis and the like.

Last year about half the machines had PEBs. This year, no. The PEB is obsolete. TIPI is coming...

Abandonware tends to be ignored, but that's not good enough for distributions like Debian. Non-free is one thing, but no license is something else entirely. But it appears we have a license of sorts, and TI has granted explicit permission for Classic99 (which sadly does not run on Linux, though if Tursi's ever game for an SDL2 port, I'd be up for looking at whatever else is necessary to make it more OS-agnostic.) Probably the right thing to do would be for the ROM to be downloaded by the Debian package from a website if it does not exist similar to how the Microsoft web font installer works.

Arrrr, thread hijacked! (Sort of.) I am actually looking for a QI motherboard somewhat halfheartedly with designs on showing how to QI the QI hopefully with a process so easy a blind man can do it. Just need to find a nice big solder point for the missing signal and show how to get a replacement ROM in there. This is a process that should become easy IMO, and as common (for QI consoles at least) as alpha lock diodes.

Karith was the name of a character in a story I wrote in the 8th grade. At some point I began using it online until I found it strangely taken on some site. As this was the age of e-everything and Apple had started doing iThings, I used iKarith to mock this trend. It stuck.

Don't have one, don't need one, and don't really want one. The thing is way too big, way too heavy, and way too expensive. Unless I were using a Geneve (in which case all the stuff I use a TI-99/4A for wouldn't work anyway), there's just not much I can't do with other, smaller, cheaper devices. The nanoPEB works well, though it's a bit quirky and more fragile than I'd like honestly. But as I said, it works well enough until we have TiPi to replace it.

If there's a mini-router-base that fits this thing (one of the major reasons I'd actually buy a Dremel over a competent non-Dremel alternative like this one), I'm sold.

That's not quite correct--the NES and SNES have a shift register. The Genesis has a quad 1-of-2 data selector, a 74LS157. You supply 5v on pin 5 to this chip and keep pin 7 high if you want to read the four directions and the B and C buttons. Drop pin 7 and you can read Start and A. This is NOT actually Atari-compatible. Atari provides +5v on pin 7. Pin 5 is one of the paddle inputs, which the electronics nerds in the group can tell you is not harmful to the RC charge timer used to read the pot on the Atari. The reason these work on the 2600 is because putting 5v on pin 7 inadvertently powers the TTL chip. The pot turned all the way to one side would do the same thing. The console has NC joystick pins and any one of them could be wired for +5, but it would be a mod you'd have to consciously choose to make.

Thread necromancy! I'm NOT a TI-a-holic. I have only one console. I've done all the rest, but I have only one console. So I'm not a TI-a-holic. Nope, not me!

I'm willing to provide hosting space for such a thing if someone starts putting together resources. I doubt I'm alone in that. Same for end user docs for people getting started. I began such an effort once upon a time but concluded then that I didn't know enough yet.

Hey all, As I posted elsewhere (because I've been shamefully neglectful of the forum for far too long now), I'm working on proper ti99sim Debian packages this weekend. And while I've been working on this, I've wondered: We have seen a lot of stuff TI never released to the market come up here, including some internal documents and other things. What I wonder is, the console ROMs themselves are generally regarded as "you need to extract these from a console yourself." Which isn't entirely easy to do without peripherals a lot of folks don't have. Dumps of the ROMs are out there, and the more technically minded among us can extract them, but is there any possibility of getting TI to permit distribution of ROM images with TI-99 emulators? Generally I'd have thought LOL not likely, but Tursi getting the actual license to produce his Dragon's Lair port to the TI has got me wondering if anybody ever asked. I can't imagine they'd release the assembly source under any kind of open source license (that'd assume they had it to release anymore), but perhaps they could permit the binary as-is under "free-enough for distribution" terms or even issue a quitclaim statement as Infogrammes did for the assets of the DOS games Blood and Blood 2? The biggest problem might be knowing who might be connected to somebody still at TI who could ask the question. I have no idea who that might be, however.

The one thing I remember about those early games is that stat generation was "too random". I played more games in the vein of Eamon back in the day, but your stats were usually a linear random value from X to Y, rather than a normalized random value in the range X to Y, and if your stats sucked you just suicided and started over. Later games gave you a point pool or a point pool plus random fuzz, or sometimes a point pool plus normalized random fuzz. But a lot of those early games didn't either to save a few lines of code or because there just was no consideration for the weighted distribution of random results.

Hi all, I've been contemplating ImageWriter emulation. There's an IWem PostScript emulator for the ImageWriter, and supposedly it supports color, but I'm told it doesn't mix colors properly. Still, the idea I had in mind was to actually set this up with GhostScript on Linux (so, on a Raspberry Pi or something) and have it listen to a serial port. See where I'm going with that? The Apple // prints to a serial port and it thinks it's talking to a printer. It happens to actually be talking to a clever ImageWriter emulator, which of course may or may not be written in PostScript, but is probably producing PostScript or PDF output, because those are the standard ways you get stuff printed on Linux systems. These may or may not be dumped to an actual printer. Has anyone ever thought of doing something like this? Now that I've suggested it, has anyone got some idea about how to go about doing it? The main problem I see is that identifying the end of the job is not trivial.

The issue with modems is not so much a matter of having something you care to call, but having a phone line with which to do it. There's plenty of folks setting up socket-based ("telnet") BBSes that could just as easily be done over real phone lines more easily than ever before. Assuming of course you could actually get the modem signal to work over a modern voice line. 33.6k is plenty fast enough since we no longer depend on these things for what we now use other file-transfer services for.

Far be it from me to suggest that the Apple // isn't THE 8 bit platform (if you know my history, I needn't get into that), but I don't know if I would say that the Commodore 8 bit systems weren't open. It's true that the Apples were a bit MORE open, with Apple even documenting mods that required a soldering iron. They got a little less open than that long before the Mac, but it was an open architecture and you could just pop the cover to get into the thing. But then, you had to since the expansion was done via riser cards rather than external connectors. I think a major reason why there's more documentation for the Apple than the Commodore systems is probably due in part to how few models there were. Consider: The Apple ][ and ][+ are functionally the same machine with different ROM. And with the language card, either machine can be the other. That takes you from the introduction of the Apple ][ in 1977 up through 1983. One machine, albeit with multiple variant configurations. In 1983 comes the Apple ][e. Fundamentally the same machine, only now there's a standard for 80 column (duplicating the major 3rd party standard for the older system) and a standard upgrade to 128k. Still the same basic hardware, though. The Apple //c changed the hardware a little, but it was almost the same as a //e with a specific set of upgrades installed. And that carries you forward to the Apple IIgs, which again maintains that same underlying hardware as a compatibility path. How many computers did Commodore produce in that time frame? The PET, CBM-II, VIC-20, C-64, C-128, C16/Plus4 are the ones I know about. Multiple variants exist of all of these, and they're generally not just about how much RAM is installed. The CBM-II could be had with a VIC-II! I think there's some compatibility between the PET and CBM-II, but I'm no more interested in those machines than I am in the Apple ][+ and older on the Apple side, so they may be functionally similar enough hardware-wise to be counted together like the Apple ][ and ][+, I dunno. Hardware on each of these systems is different from the others, though. It's true IEC peripherals for older systems work fine with newer ones, and generally the reverse is true with certain caveats (like that the 1571 is functionally a 1541 on a C64.) And all of the Commodore machines can talk to IEEE-488, if indirectly. But the hardware architecture of the machines is very different. The VIC 20 cart port for example is totally different than the C64s, and that's for the best mechanically speaking. The older PET didn't even have that kind of bus expansion port. And the Plus4/C16 were ... what was Commodore thinking making a new machine that was both an upgrade and a downgrade, with no backward compatibility to speak of for software? If you stop and look at the players in the 8 bit market, they really all had ONE truly stand-out machine of the era, with perhaps one other that did pretty well too. For Commodore that was the C64 and perhaps VIC-20 in the runner up position. For Apple it was really the ][+, even if the //e appears to have won out as the most popular machine out there. That's largely because Apple flooded schools with the things, and because the //e was a backwards-compatible almost pure superset of the ][+. Which is why I have no interest in the ][+ today. The //e is still a dime a dozen, eBait notwithstanding, and I could count on one hand the programs that require the older hardware, if I cared enough to find out what they were. Outside the US it's much the same--Sinclair had the Spectrum and Atari's is functionally the Atari 800, for example.