wierd_w

These folks have ribbons for the shinwa nlq 180 in their brochure. https://www.fullmark.com/wp-content/uploads/2021/06/Fullmark_Ribbon_Catalogue_2013.pdf Granted, its an old one. They dont have sears sr1000 though. I will keep looking. The following textfile suggests the SR1000 and the Shinwa NLQ180's (and a bunch of others') ribbons are compatible with 3 commodore printers, suggesting a standardized cassette. http://www.zimmers.net/cbmpics/cbm/printers/ribbons.txt Shall I keep looking? Kept looking: cannot find a manual fro the SR1000. Lots of hits for a typewriter of the same maker and model number, but no printer info.

It may interest you to know that DosBox (and its more capable fork, DosBox-X) has SPECIFIC support for PCjr and Tandy1000 In addition to setting the machine type, there are command line arguments you can pass to it for such things as, autostarting a "booter" game, or executing a cartridge ROM file. (Since the PCJr had cartridge slots!) See for instance. this page. The BOOT command would be combined with the -C option, as specified on THIS page. EG: dosbox --machine=pcjr -c "boot /somepath/Somecart.jcr" or dosbox --machine=pcjr -c "/somepath/somebooterimage.img" Where you MAY have difficulties, is where the Tandy and PCjr emulation tries and fails to satisfy the demands of "Hardware abusing" games, that make specific assumptions about the behavior of the hardware that might not have been documented, such as with RCA video output timings. ---- I'd have to pirate these games to test them, and that is frowned on.

The PCJr version of the Sierra games, like the King's Quest series, support "EGA Like" Graphics and the PCJr's version of the Tandy 3-voice sound chip. We had a PCJr when I was a kid, and we played the crap out of KQ1 on it. Lots of "Bird chirps", "River sounds", and some chirpy musical sequences, such as on the title screen. Such sequences are distinct and different than the later soundblaster sound enabled remakes, or the music played on the IBM PC version geared for PCSpeaker. Sadly, we did not own any of the games on your list. It is important to understand that the video hardware in the PCJr is very different from EGA, despite having "A similar user experience". As such, games that expect real EGA will not work correctly on a PCJr. This was "On Purpose" by IBM.

"DOS gaming" has epochs within its own genre. You have: The Text-Based / Hercules Monochrome epoch The CGA based Epoch The EGA based Epoch The MCGA/VGA Epoch The SVGA Epoch In terms of CPUs that are contemporary with each: Text-based through CGA epoch is 8088 through 286, roughly. CGA epoch through EGA Epoch is late 286 through 386 EGA epoch through early VGA epoch is 386 to 486 VGA through SVGA is 486 through early Pentium Anything after that was into the "Windows Gaming" era.

Looks 'very similar' to Star Micronics SG-10, but not quite it. I'd say it's probably a Star, but cant pin down the model.

WinME was 'a shit version of win2k'. It used the same version of WDM, but strapped to a hybrid real/flat mode kernel from 9x, rather than pure flatmode, like 2k. It thus had issues with drivers right out of the gate. Software expecting to walk all over hardware and software like it could with 9x, found that the system 'took umbrage', and shit broke. A Lot. I too avoided it, and early-adopted win2k, and just used vdmsound for my dos games. (DosBox too immature on its emulation core.) I too was 'in the trenches' of retail during the 90s as a teenager, and did my best to understand the other OS offerings out there. There was a fair amount of buzz about BeOS and BeBoxes in the early 2000s, but it dried up fairly quickly. Neither OS/2 nor BeOS actually completely died though. The first became eComStation, (and now, ArcaOS), and the latter became Minuet and co. Geoworks dried up and blew away. Linux has risen to prominence in server and client roles. (Though I use it as a desktop just fine.)

Here's something fun! https://github.com/crazii/SBEMU Use with jemm386, jemmex, or qemm 7 or higher. It seems to work on my old potato toshiba laptop, but the volume's a bit low.

Perhaps try a bit of oldschool 80 wire ata133 cable, and just let it hang off the side of the idc header? Cutting one between the primary and secondary IDE connectors (and thus very short) might be what you need. Extra noise suppression with interspersed grounds

A large haul of new old stock in a barn is being liberated. Good opportunity. https://www.vice.com/en/article/ak3k34/2200-forgotten-vintage-computers-are-being-liberated-from-a-barn-in-massachusetts Ebay listing https://www.ebay.com/itm/394707943686?hash=item5be66d4106:g:XyUAAOSwBOBjZIUH Just be sure you know what you are buying. See also, the "Experiments with the Nabu" thread. Nabus are 8bit computers that were designed to work with a proprietary network interface over a cable network, that no longer exists. That said, there are ways to convince them otherwise.

There's some black magic to getting undither to work with monochrome images (which the channel separation will produce) http://www.madingley.org/james/resources/undither/ Since the power distribution file is a ppm bitmap, it will be palletized. A simple selection mask and color range selection with the paint tool should work to make this much less touchy.

Bigjpg does interesting things too. Here is what I am tentively going to suggest: Scan the high quality manual image at a resolution of about 2x the lithograph dot pattern, then bicubic reduce so that it is the same resolution. (Lithograph dots more or less exactly 1 pixel) Load the image into photoshop, then separate it into C M Y and K channels, and save each as a png. https://wikis.utexas.edu/display/utprint/CMYK+Separation Take each component channel, and run it through undither, to try and smooth out the gradients/remove the lithograph moire patterning. https://github.com/kornelski/undither Recomposite the smoothed/undithered channels. Save as png. Feed it to bigjpg, waifux2, or some other AI upscaler. Tell it to denoise, and upscale the bejesus out of it. You need someplace in the neighborhood of 600x600 dpi, with 24in wide, at a minimum. (14,400 x 21,600 px for 24"x36") With any luck, you can coax something printable out that way.

The problem I foresee is that manual covers have moire pattern lithograph artifacts that will be ugly AF when enlarged. You would need clean, archival image stock in a very high resolution to do large format printing. (Or a specialized AI that can detect the moire lithograph dither, derive suitable solids in CMYK, and de-noise a quality manual/box cover scan, then upscale the bejeebus out of it) I own a large format printer, and have made a few posters on it. Pixelation artifacts and moire lithograph dither are pernicious enemies of mine.

Sounds like you would like to just buy a finished board to me. If these work well inside TI units, Arcade Shopper might start stocking them. F18As are a hot commodity.

Not a problem! Happy to help!

The optiplex 360 uses a standard coin cell lithium battery. You can get them at walmart or similar stores reasonably cheaply. The error is about the CMOS battery, and no, you cant really disable the warning, because you would need that battery to retain such a configuration option in the first place. 🙂 Just pop the old one out and put in a new one. It should stop after that.

Should be easy enough to design a mold for pourable silicone. The specs for the cutout are easily obtained.

In theory, if you made a DSR for it and have some kind of RS232 (or use the strangecart in a novel way), one COULD slave a TPDD on. (If you turned the baud rate waaaaaay down, you could maybe use the cassette interface, by abusing motor-on as CTS ? (DTR would be harder, but 'no flow control' is/was a thing) It would need an amplifier though.) The API to communicate with the drive is very simplistic, so it would be easy enough to do, but very little else (aside from knitting machines) uses the disk format. (And you only get high level access, not low level block access.) It also wouldnt hold much. It's just an 'in theory' thing. TIPI and NanoPEB are just better options. In hindsight though, a DSR GROM cartridge with an analog amplifier/stepdown bridge on the cassette cable might have been a plausible aftermarket product to work with a vintage TPDD. (Put a DAC between the serial based TPDD and the analog FSK ti cassette interface. Use cassette motor-on 1 to tell the analog bridge that the TI is ready to get a short FSK based burst, and cassette motor-on 2 to tell it is going to transmit a burst. Inside the bridge is a buffer chip and a serial uart bound to a hardware FSK tone generator and interpreter. It provides a 'safe' sink for serial data at 300bps to be communicated by, and generates CTS/DTR based on buffer fullness. Manage the interface directly by the CRU.) Is cassette interface full duplex?

Here's a deep link to shopper's keyboard goodies for 99/4a. https://www.arcadeshopper.com/wp/store/#!/Keyboards-and-adapters/c/23836460 There are at least 3 revisions/makes for TI keyboards, and some are more long-lived than others. The folks in the dedicated forum will steer you right.

There are some keyboard replacement projects done by members, and an online store run by one (arcadeshopper) that specializes in such kits. https://www.arcadeshopper.com/wp/store/#!/Classic-Computers/c/136753819 Feel free to drop into the specialized forums for TI and Commodore, and say hello there.

If you are wanting to wrap an assembler program as a subprogram, this vintage text file might be informative. http://petesqbsite.com/sections/tutorials/tutorials/asm.txt BLOADing in the data should work I think, but the final bit of that text file covers passing variables, which would be quite useful for you I think.

The images I made should be within the echs allowed ranges. Anything bigger than 502mb is outside original chs spec for mfm drives.

But does it contain rom basic, AND at the correct address? You might try building the core yourself, with a straight dump from a 5150. https://www.pcjs.org/machines/pcx86/ibm/5150/rom/ https://www.pcjs.org/machines/pcx86/ibm/5160/rom/ (These are wrapped in some json bullshit, but do contain the roms in question. Some user fiddling would be required.)

Mister's pc-xt is 'optionally' using the dumped 5150 rom. It uses a foss clone rom by default. Not sure about pcem.

Again, basica is basically just a loader for IBM's rom cassette basic. The code it expects to hook 'just does not exist' inside clone PCs. The dubious idea above would take the ROM from a 5150, an unmodified basica from vintage DOS, debug from the installed DOS, and an assembler program that rips the cassette basic out of said rom, copies it and basica into ram, patches both in memory, then jumps execution. It would be 'bug complete', since it's legit ibm cassette rom basic, but would be legally dubious.

while ethically dubious, it would be possible to extract that section of ROM code from the IBM pc rom, inject/load it into a safe segment of DOS memory (with debug), then use a patched version of basica with the entry vector changed. The actual romcode might need patching as well though, if it wasnt written portably and hard references segments/offsets in its routine libraries. A truly clever loader would have an unmodified dump of the ibm rom, and an assembler routine that scans the UMA for a free UMB of sufficient size, notes the offset difference from the 'expected' one, then patches both a copy of basica.com and the romcode in memory before jumping execution. This would keep all on-disk files intact and unmodified, and still permit the use of 'real basica' on arbitrary dos machines.