iKarith
-
Content Count
353 -
Joined
-
Last visited
Posts posted by iKarith
-
-
The SD floppy sounds like the perfect replacement for Floppy drives. And dirt cheap also.
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.
-
1
-
-
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.
-
Yeah, I seem to recall that message thread, I thought that was what you were referring to in your post a couple back. Could you please post the link to that message? I need to be sure to write that down again. I have plans you see....
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.)
-
You might be able to get away with a +5V/+12V external supply, and fit a small +5V --> -5V converter module in the console. Something like [http://uk.farnell.com/multicomp/mca05d05d/dc-dc-converter-1w-dual-o-p/dp/2079668].
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 may want to check again on that!
(Somewhere on here there's a thread with a link to a PS module that does have all the required output voltages)
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?
-
1
-
-
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.
-
1
-
-
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.
-
The TI console spec says that current draw from the side port is limited to 50mA. Enough for the speech synth, but possibly not for the nanoPEB?
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.
-
We'll get together soon Joseph - I just wish you lived a bit closer! What do you think about heading out West? I live a couple miles north of the end of the MAX line. We could spend a Saturday afternoon hacking away at all of these things, and making cables/mods and all that jazz. I have a well-equipped bench with a soldering station. I have access to SMT tools as well.
I think I have a spare 5v supply for that nanoPEB if you don't have one. Why the designer didn't tap the 5 volts available RIGHT THERE ON THE SIDE PORT is a bit of a mystery. Perhaps it was to keep people from depriving it of power during writes. ¯\_(ツ)_/¯
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.
-
Careful, you're starting to tread into Omega's trademarked "I'm just an ideas guy" territory
Schematics for nearly everything you'd want in a open-hardware nanoPEB are available. Much of the non-TI designs would need to be reworked, due to a perverse desire in the TI community to use battery-backed RAM for hardware drivers (DSRs). That would mean Thierry's IDE card (with *two* competing and equally broken DSRs), The Project That Must Not Be Named, and so forth, would need to be reworked before build.
All it needs is a bored and qualified engineer to look at the TI schematics for the RS232 sidecard, reverse-engineer the Axiom (because the TI design is crap), and ask someone nicely for the TI DSDD schematics/firmware ... then turn it into VHDL, get really familiar with Eagle, and do a few hand-soldered prototypes before handing the PCB artwork off to any reasonably-priced fab.
Like I said, easy
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.
It would really be nice to see maybe an open source project for maybe 'PEB-Next Project' or 'I-PEB'. I thought of the idea a while back (just an idea - i'm not a hardware designer). But seeing all the open source projects floating around and after getting JediMatt's Open source USB Keyboard interface hooked up to the TI with almost no effort it go me thinking.
How about a new modular PEB that would have a much smaller form factor.
So small open source modules (RS232, Disk Controller, RTC, memory, etc..)that could be plugged into the new designed PEB that are much smaller than the current cards, but with complete compatibility for all programs. Is it possible.. maybe.. just a thought. All this could be achieved i thought and at the same time decreasing the amount of desk space the PEB takes up.
It's all about time and dedication though. If the guys that are designing new hardware today had everything they have learned about it but were teenagers again then of course we would probably have one in about 2 weeks! But family and life takes priority as it does for all of us..
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...)
-
1
-
-
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.
-
This is the one he got from me, and it did not come with a power cord. I assumed he had one from his "bad one"
You can jerry rig 5v off the TI power supply to a cable or just get one of these and use a usb plugI 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.
Make friends with someone enrolled at your local community college that's taking basic electronics courses, and ask them to freshen up *all* of the solder joints on the device (especially under the EEPROM). That will save you a lot of grief in the long run.
I've got the PDF manual for the CF7/nanoPEB around here somewhere (the guy making them took down the main page, but not the subpages, so it's still available online). If you can't find it, and no one else steps up to the plate, let me know and I'll send it along.
(everything in xdt99 is fantastic. Screw the Windows tools; portable python is where it's at. I've argued that point several times on these forums in various contexts, especially the Hardware Project That Must Not Be Named, but you're the first proof-of-use case that I've seen. Thanks for that.)
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.
I don't think I've heard of ti99sim locking up before. My first guess would be an audio issue (a lot of issues seem to be related SDL/ALSA support on various platforms). To see if this is the problem, try running with the -q switch. This will prevent any sdl audio code from running. Normally, hitting the escape key will exit the emulator immediately.
FYI, there is a bug in the cf7+ emulation that will cause the emulator to sit at a blank screen on startup if you have the cf7+ cartridge installed without a proper disk image for it. This will be fixed in the next release (I only just discovered this during testing since I normally have a test image in place). If this does happen, you should still be able to exit by hitting escape, so this doesn't sound like the issue you're seeing.
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. -
[..] I'll be the first to admit that this country has a large number of problems. But AtariAge is not the place to discuss them, as it didn't take me long to learn that discussions about politics and religion almost always degenerate into shouting, insults, and name calling. [..]
Let's please keep discussion to the original topic.
Thanks,
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!
-
@iKarth, I imagine it'll be kinda fun for the kid, assuming anything comes of it. Knowing his father though, I'm sure he's just looking at the educational aspects.
Regardless, the project looks fun. Now me, I always find 'alternative uses' for stuff, so I just might "re-task" his idea a little and write an XB program using my TI's CorComp clock to control something like a light... assuming of course it can be controlled from XB. I would think it would need an assembly language portion, though and I can't help the kid with that, so in the end he may be S.O.L.
Teacher hat on, the best learning tends to happen when the kid doesn't know it's supposed to be "work".
10 !CALL LINK("ON") to turn on the cassette recorder
20 !CALL LINK("OFF") to turn it off
30 !by Ed Hall
100 CALL INIT
110 CALL LOAD(16368,79,70,70,32,32,32,36,252)
120 CALL LOAD(16376,79,78,32,32,32,32,36,244)
130 CALL LOAD(8194,37,4,63,240)
140 CALL LOAD(9460,2,12,0,45,29,0,4,91,2,12,0,45,30,0,4,91,203,78)
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.
-
1
-
-
Close, but not quite.
Three major problems:
* non-existent quality control (bad solder joints, missing solder joints, etc)
* Ancient CF-card driver that didn't work with any card made after the early 2000s
* (on the nanoPEB) A serial port that didn't work with common comms packages like Telco.
I'll leave for others to speculate as to why he didn't fix his production problems and the DSR, but those were the technical issues. I had one, I sold it because I had no faith in it whatsoever.
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...)
-
1
-
-
Quite simple: 8bit = expansion card, just plug in; 16bit = soldering job inside the console
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.
-
External power is required, won't work without it. Use a +5VDC wall wart to power the board. I'm surprised that the knowledgeable users at the PNW meetup didn't tell you that.
*BUT*
If you have the device that Omega was selling, be aware that it's only barely functional. It has (at the very least) bad solder joints. See http://atariage.com/forums/topic/251299-rat-farts/page-2?do=findComment&comment=3488720and http://atariage.com/forums/topic/251299-rat-farts/page-2?do=findComment&comment=3488888 for details, but the executive summary is that this unit (if, indeed, it was the one we were talking about) was known bad prior to PNW and should have been flagged as such.
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.
-
Can't help you with the nanoPEB, as I have a CF7+, but you could try xvm99 to manage nanoPEB/CF7+ volumes and xdm99 to manage disks (on a Mac, I presume
).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!"
-
3
-
-
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?
-
2
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
TI-99/4A manuals and documentation project
in TI-99/4A Computers
Posted
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.