wierd_w

I've only made it halfway through level 3. But I think I can get the better of the game just by getting guud. I've also gotten 75% on Sabre Wulf recently.

I would call it toast. Reasons: 1) that is dust on the platter. The air gap the head floats on now has abrasive dust under it. 2) despite being powered on it has only spun a few cm in rotation. The drive motor is probably seized. 3) adding lube will introduce oil aerosols on the platter which will promote head adhesion. Not worth it IMO. Just use the CF adapter.

I wouldn't recommend trying to play midi, run a BBS, print documents, and do some kind of serial file transfer at the same time-- no. However, if you arent being crazy, it should work fine.

Timidity sends audio to the default ALSA device. If you don't jack with it, the RPi audio comes out two PWM pins that are not exposed on the GPIO header, and are instead routed to an integrated version of the circuit I just posted, which is connected to the headphone jack. As far as the Pi is concerned, the config.txt entry just specifies which pins it wiggles to make audio. Timidity does not care which output device is configured as the default alsa sink. It just produces PCM sound, and shits it to alsa.

The Pi uses a simple highpass & Lowpass filter + amp circuit to improve quality, because it has to drive a speaker directly. However, the TI's audio rail is sent to a TV, which has an amplifier. See for instance, the circuit you need to add to a pi zero, because it lacks the headphone jack (and supporting circuit) https://sudomod.com/forum/viewtopic.php?t=480 If it can work to drive speakers, it can drive the TV's audio.

The pi's audio is really just a PWM GPIO. You can specify which pins are used in config.txt https://www.raspberrypi.org/forums/viewtopic.php?t=215339 for details.

IIRC, they are exposed on the jedi-matt connector. You just need 3 female-female jumper wires, attached to appropriate spots on the connectors of the PI hat connector, and the Jedi-matt connector. Bob's your uncle. You could always just plug speakers into the Pi's headphone jack instead of course. Your music would come out there, and the TI's chiptune would come out the TV. You could already do what you are suggesting with Timidity++. It supports soundfonts, and the Pi supports telnet. Your program just sends an .sf2 file to the Pi into its /tmp folder, then modifies the Timidity .conf file, and restarts timidity. That .sf2 file contains all your samples. Then you just call it with an instrument and note syntax. BONUS-- you get pitch variablity and other fun stuff.

Timdity is a system daemon. it runs headless. No monitor needed. (Speech needs sound rail passthrough wires) Like people aren't already passing +5v with a passthru already...

If there is an FCC ID written on it anywhere, you can get the manual. https://fccid.io/ The device maker has to supply images, and documentation for the device, in order to get an FCC ID registered. That information becomes public record.

I am totally getting them, I was just writing a small bible in the tipi dev thread.

In the example I made, the primitive would be closer to PI.MIDI.<device#>.<Port#> which then gets fed 2 values-- ([wrapperCommand],[message]) A calling program thus just needs to know what device to talk to (Timidity always grabs 128:0, 128:1, 128:2, and 128:3, so if you just want to assume timidity, just use 128:0 through 128:3 for your device and ports.) The way midi works with the ID:port designation, is each device can communicate on its port, but only one way. EG, a port might be only input or only output. Timidity has basically only inputs; it's not a keyboard, or other "meatspace" instrument, nor is it a sequencer. You can think of it as an abstraction for a physical connection-- a port. Some devices, like keyboards, will have ports that go in, (such as say, on a Roland synth-- So that you can plug a computer or external sequencer into it, and that sequencer can then write data to that port, and the keyboard will play the resulting sequence through its synthesis system) and some that go out (you press keys on the keyboard, and raw midi messages are generated, and sent to an external synth, such as an MT32, or to a recording sequencer.) The basic functionality I want to be sure ends up in there is this-- 1) Send one-off message to midi device at specified port (Invokes amidi without an input file, unwraps your single message and populates the amidi invocation with the message as an argument. amidi does its thing then terminates.) 2) Create long-duration session with a midi device at specified port (EG, create a named-pipe file in the /tmp folder, do all subsequent writes straight there with echo >> syntax, so that amidi just sends them to the device on a single invocation-- EG, amidi is trying to "play" the named pipe, and keeps running, trying to read the file. Plays messages as they arrive.) 3) Close long duration session with midi device at specified port (kill amidi, remove named pipe file) 4) Silence/reset midi device at port (write appropriate bytes as one-off messages to the specified devices and ports) 5) Query midi stack (Ignore device ID and port ID specified, return results of interpreted aplaymidi -o, which will list all currently available midi IDs and their port numbers, as a comma separated values string returned in the data variable for the function) 6) Collect data from device ID at port 7) Write data on established long-duration session to device at port (Unwrap message, and use echo >> to append to the end of the named pipe file. amidi then reads the "written" data, and does its thing) And any other special operations I might need. A whole byte is a lot to work with. So, if you just wanted to play music through timidity in your program, you would just assume the device is 128, the port is 0, and then tell it to create a long-duration session, with midi messages to initialize the synthesizer (silence all voices, etc) then call again with the command set to "write on long-duration session", and just blast your midi data over it. If you just use raw tcp handler, you have to also specify which remote host you are talking to, and what TCP port it is listening on. More complicated than it needs to be for somebody that just wants to play a little music. @Omega-- A) No. Timidity++ is a software only based midi synthesizer that runs on linux. It is a device that can realistically be always expected to exist. It supports loading soundfonts and other fun things. It's a very versatile synthesizer. HOWEVER!! If you should say-- Own something like an MT32, or a Roland keyboard, or some other hardware synthesizer-- You can use one of these cables to attach it to the USB port on the PI, the Pi will recognize it as a midi device, and give it an ID. Your software could then call THAT ID instead of 128, and you could make THAT device play your music for you. B) The idea is to connect the Pi's audio leads to the TI's sound channel header on the sidecar, so that the audio comes out in your TV. By structuring it the way I am initially proposing here, it would be possible to sequentially write to several connected devices with the same calling convention; You could have several instruments playing through timidity, be playing back some PCM samples you uploaded (using the one-off message mode) to an MT32 for sound effects, playing the harmony track on your Roland keyboard, etc--- just by specifying which device ID and port ID you are sending your data to. It's simple, but you can do a whole hell of a lot with it.

The latter; Its a TCP message sent to the localhost on a port. On the Pi, is a listening script that intercepts that message, interprets/unwraps it, then either interrogates the midi stack for its members/connections, hangs up the midi devices if they are stuck, or sends raw midi commands, as indicated. The idea is standardization. The amidi commandlet supports being fed a file, which means it can use a named pipe. A single instance running can handle an extended session with a device that way. It would be cleaner to, say, call ("TIPI.Midi.128.0") and feed it raw midi data, than it would be to call raw tcp.

I would think it would need a resistor to reduce the rate of discharge to the appropriate milliapmerage.. Meh. I would replace with an appropriate voltage alternative, like a lipo cell or something, if a CR2032 would not suffice.

I was meaning he could additionally add one of these to his system (if he can find one anyway.) https://www.worthpoint.com/worthopedia/boca-research-bocaram-plus-286-386-1840641314 Adds an additional (up to) 8MB of 32pin SIMM memory over the 16bit ISA bus. Slow as dirt, but a 386 is not exactly blazing fast to begin with. I remember owning an AST 16bit ISA card that had 72pin simms, and could go to 32mb, but I cannot find information on it. Sadly I no longer own the card. It's moot anyway; he seems to want to run DOS 6.22, and do dos games exclusively with the system. For that, 16mb should be more than enough for basically anything vintage. His motherboard will easily accommodate that without using obscure hardware.

this particular unit only does 32pin SIMM, up to 32mb. (which should barely run win95, if he really wants to try it...). There's things like BocaBoards, which can get him an additional 8MB (tops).

I think 6v is probably too high. I remember the AA battery replacement packs as being 3 AA batteries, not 4, which would be 4.5v at peak, and ~4v after some discharge. If the unit is designed to recharge the cells, using the AA holder with some NIMH cells should do the job just fine. The batteries wont particularly like being charged by a nicad charger, but it should be OK at the low C rating being delivered.

Is that the right board? Did you find JP2 at the indicated position?

This looks like it might be the one... https://stason.org/TULARC/pc/motherboards/B/BIOSTAR-MICROTECH-INTERNATIONAL-CORPORATION-386-MB-35.html Note location of component JP2. That is the external battery connector. You can attach either the 3 AA battery holder, OR-- you can make a CR2032 holder on a pigtail, and plug that in. You will need a 4 pin 2.52mm pitch female header connector. The two outermost pins are the ones you want. Pay attention to polarity markings on the motherboard silkscreen.

Hey Matt, if I make a wrapper script for amidi that listens on a private extended range port, would you make a proper handler for it? The way midi devices are handled on linux is like this: Each device has a numerical ID between 0 and 255. Each device has midi ports numbered between 0 and 255. So-- If I make a simple listener daemon script, and make some presumptions, we can wrap amidi, then send (and maybe receive, with some work?) midi messages to arbitrary linux midi devices, like so: Each midi message has 3 bytes appended to the front, which the wrapper interprets then strips off. 1st byte is for control messages to the wrapper, 2nd byte is the Midi device ID, the 3rd is the Midi Port ID. After that, it is 2 bytes for midi message. This would be a dumb TCP message with no error correction sent to the localhost on the designated private use listening port. Each message sent to the wrapper would thus be at least 5 bytes. The first byte is used to send messages to the wrapper, such as to get then report available midi devices and populated ports (output of aplay -o for instance), or to reset all midi devices, etc. 1 byte gives us 256 possible instructions, which is plenty. If I write this, would you include a proper service routine? This would let the Tipi handle arbitrarily attached midi devices, and present them to the TI. It would need the audio from the Pi routed to the audio pins on the card edge, but this looks totally doable, and appears to be low hanging fruit. If we add Timidity++ to the image, we even can have a guaranteed midi device at midi IDs 128:0, 128:1, 128:2 and 128:3. (those are the default device and ports populated by the timidity++ daemon, but we could designate whatever IDs we want with a custom conf.)

concerning RAM: I have identified your motherboard as a Biostar 386, but there are several variants. I found some short&sweet bits of documentation for jumpers and SIMM configs and the like, but I don't know the specific model you have. Its maximum is probably 16mb. Anything more would probably need an ISA memory card. (They made some that took 32pin SIMMs.) 16mb is good enough just about any DOS era game though.

Flying Shark can be played on the keyboard.. kinda...

Excellent. Now you get to get your game on.

"retro handset adapter" https://www.amazon.com/s?k=retro+handset+adapter&ref=nb_sb_noss

I prefer option 3; Software debugging enabled cheat support via cartridge. EG, something that can set breakpoints for various values being changed by the game, then set them back to a value the user specifies, before resuming execution. IIRC, I saw an interesting bit of work in the dev forum that could be abused in this manner.

Still going; Now that I have a PEB to measure, I can do it myself Admittedly though, I just get real sad every time I see that things all bent like that. I really need to get/make some kit to straighten it. I think I will use Aluminum instead of steel for any replications; Easier to bend by hand. That steel is unyielding with anything but a hydraulic press.