wierd_w

I mean, I understand the sentiment, but be wary of greybeard elitism there CS1. I mean, you might be told that it's not an IBM series 300 mainframe with reel to reel magnetic mass storage, or a Hollerith card reader by the even greyer greybeards. (If I were 10 years older or so, I would have been cutting teeth on a C64, or an Apple II instead, much like yourself.) I am 40, and cut teeth on IBM PCs. The Overton Window changes over time. As silly as it sounds, some kids will mention early Android Tablets as the thing they consider a "Classic Computer" at some point in the future.

Indeed, that's why I suggested the post-amp. The component count on the post amp is very minimal, and the components needed are inexpensive. The Pi3+ and co have a filter circuit on the board, but that is what drives the speaker jack. going off the GPIO header, you would still need to provide the amp. Putting it on any and all Pis would just make it a universally applicable solution, IMO. It's arguably not needed if you send the logic level signals to the TI's sound chip for mixing, as the TI's sound hardware would provide the amp on its output. (and driving more than logic level outputs on that thin of a trace is probably not a good idea anyway. I doubt the speech synth outputs greater than logic levels itself.) For a PEB Box setup, I would strongly encourage putting a stereo audio jack out the back somehow.

If you slap the small post amp circuit on, you can put a stereo out port off 3 of the gpios. AUD-IN is monaural. The default is stereo. Without the post amp, the audio sounds like garbage, because it's logic level signals, not audio level signals. The circuit diagram for the post amp is readily available online. Since geneve is all internal to the PEB though, AUD-IN would be on the backplane, and is how 'peb speech adapter' works. Getting the signal safely from the bus would probably need bodge wires on the tipi card, and that is probably beyond the scope of a safe user mod. Doing a grep of the pi.config file to see if gpio audio is on, then a grep of alsa.conf for the mix mode should be doable. I had been considering using 'device' 65535 as a reserved device used for sending such control messages to the listener daemon, which would then allow numbered queries on the next two words before the termination word. This way you could query what ALSA midi devices are present, note-off on all devices, etc. Alsa midi api allows up to 65535 unique sequencer devices, each with up to 65535 'ports' (unique io stream channels) per device. for instance, the MUNT synth offers 2 ports, on a default 'device' id of 128. Eg, 128:0 and 128:1 These are normally used for 'gm emulation' and 'mt 32 native' instrument presets. The 'device' is 128 for both. Softsynths on linux default to 128, but will enumerate after that if the id is taken. Eg, if you load MUNT, then Fluidsynth, munt will be 128:0,1 and Fluidsynth will be 129:0. It's analogous to a 'midi chain'. Midi devices that are chained together on a daisy chain setup. Device is then analogous to the physical midi uart, and the port is the device ID on that chain. Since the protocol would accept alsa device and port as words, you could work with hardware devices, as long as the Alsa subsystem has enumerated them. It's very mature, and detects such devices automatically in most cases just fine. There are USB cables for vintage midi devices, like authentic roland sound canvas, korg keyboards, mt32 and pals. You could put them on a usb hub, and connect that to the pi. The alsa midi subsystem would detect them, assign them DEVICE:PORT ids, and you could then use them just fine. However, the program running on the TI is not clairvoyant, and would need to be able to query for a list of sequencer devices and presented port ids. Hence the need for the backchannel commands. This would allow the single UDP service to arbitrate and handle IO to every midi device. That would allow whatever software you write or use, to define or use instruments from different devices. Useful if you want complex audio, multiple drumsets, etc.

True enough. I am more than happy to dabble in the water of trying to write a python handler/arbitrator for the ALSA midi subsystem. There's already a community created python library for doing that, so I would just have to scribble out some glue between that and a UDP socket handler. Also more than happy to do the mucking around on modifications to the stock TIPI raspbian image to turn on Audio over GPIO, set the ALSA config to monaural downmix, and set up fluidsynth/compile MUNT. The obscurity of messing with linux under the hood like that is daunting to a fair number of people, so documenting what needs done, so it can be pre-baked as a flashable option would reduce the user burden quite a lot. There are potential issues with needed user accounts so that the daemon has proper permissions to the sound device. This is a common issue with getting software synth daemons configured on desktop linux. Do you know if raspbian is SYSV-INIT, or is it disgustingly Systemd? I am a decent hand at writing a sysv-init style daemon script for init.d, but getting systemd to play nice is still something I struggle with. Actually connecting the Pi to the AUD-IN line is really just 2 wires off the JediMatt connector to 2 pins on the Pi's GPIO header. A ghetto wire wrap on the jedimatt side before pushing the TIPI on, is really all you need. It's JUST audio.

Iirc, AUD-IN is exposed on the JediMatt 44pin header, as is GND. It may have issues being used in conjunction with the speech synth, due to lack of chained mixing, but a small 44pin dummy extender that is orientation labelled, and has the 2 wires coming off as DuPont jumper pigtails would fit your bill. Personally, I would just wire wrap AUD-IN and GND from the already exposed JediMatt connector, but for say, 'speech synth enclosure' tipi, that might not be doable. You would have to solder onto the far edge of the card finger or onto the through hole of the downstream connector.

A single line edit to the pi's conf file will enable audio off 3 pins on its header strip. This audio device ideally needs a post amp filter, but can abuse the one in the TV/Monitor, if injected onto the Aud line on the TI's sidecar bus. It is fully supported by ALSA back end, and so MUNT, FluidSynth, Timidity++ and pals can cheerily use it. https://raspberrypi.stackexchange.com/questions/49600/how-to-output-audio-signals-through-gpio You would need to add a 'monaural downmix' directive to the alsa configuration to force it into a single channel, but that is also just a config setting. (Then you would have synthesis being piped out of the pi and into the TI's sound chip mixer natively). I think 2 little wires is not that big of an investment in hardware. you would need access to mt32 roms to use MUNT, and would need a fairly beefy (not a zero!) Pi to use FluidSynth. Both are software provided synths that are FOSS. No additional hardware required. @arcadeshopper Yes, however he is not communicating with the alsa midi chain, but with a bespoke hardware device. The ideal solution would leverage the alsa midi chain, and thus allow access to ANY arbitrary midi device you might have, be it a softsynth, or a hardware one.

I will say this again. It is painless to route midi over a UDP socket. One could expose the entire midi stack afforded by a tipi, and have several softsynths, and real synths off USB, quite painlessly. It's very low hanging fruit. (MUNT for MT32/LAPC1, and Timidity++ or FluidSynth for GM wavetable stuff. Linux MIDI stack could present any arbitrary hardware synth the same way, using the PORT:DEVICE addressing schema.) Again, you just need a UDP listening daemon that wraps something like aplay. A daemon shellscript could do the work. Have a bespoke protocol that sends 3 words at a time with a termination word. First two words specify device and port on the linux midi subsystem, and the third contains the actual midi message. Termination word keeps the handler in a sane condition. From the TI's side, you just throw the 4 words at the UDP handler baked into the tipi on the specified UDP listen port. Like magic, the tipi responds.

Well, if you ever find that you need them, there are places on the net with large archives. Like this guy's: http://www.mcamafia.de/mcapage0/adflist1.htm Or these people's: http://ps-2.kev009.com/eprmhtml/epradf/adfall.htm

Yay! That's a good sign. Yes, you will need the setup/diagnostics disk to reconfigure the system options before you can properly use it. If this is an MCA based system, you will need ADF disks for all the cards as well. There are archives of those floating around.

Last I looked at my speech, there is clearly a neat row of tinned over thru-holes where the feature is supposed to go. It's just not populated. an interesting solution could possibly be put there, and on the sideport data connector, that basically houses an addressable SRAM into which speech samples can be loaded, and then handled by the speech unit. Say with CRU writes. This would put it outside the normal RAM area, and allow a lot of use out of the speech without sacrificing system memory to use CALL SAY. There is ample realestate inside the speech enclosure for such a thing. As demonstrated with the TIPI for the speech enclosure, a microSD card could even sit there (in the door), for disk based samples. It's a missed opportunity in the modern upgrade realm, imo. The speech really could be abused in some clever ways as an additional sound source. LPC can do much more than voice.

*EDIT* I see that this thing has a 7400 series integrated circuit package. These were widely used for things like NAND, NOR, XOR, OR, and co, package ICs in the 70s and 80s. From what I am reading, they are 5v chips. (The 7400PC is equivalent to NTE7400, which is a TTL Quad 2-Input NAND Gate IC. Its spec sheet says it is 5v nominal voltage (tolerant to 5.5v)) This suggests that the batteries are 2.5v nominal. This suggests those are some variant of a lead acid cell, or similar chemistry. Consider replacing them with a 6v lithium battery, with a buck voltage converter.

I would be more interested in say, using PragmatIC's "Plastic IC" foundry service, to straight up just have plastic based smart credit cards made. Should be quite amenable to eINK ePaper displays. https://www.pragmaticsemi.com/ They recently had a breakthrough with getting ARM M0 reference designs fully working at >1cent/unit with bulk manufacture. Since they do bespoke work too, according to their site, a "Self-designed" 8 bit CPU on plastic substrate should be achievable. Say, something that has a 'coin holder' to accept a penny into, that you then just get wet-- to supply wet-cell power with.

I still dont see good data on it... but under his thumb, that appears to be an exposed data bus? Maybe with a select logic pin, to serialize address bus? (eg, pin 9 raised means 'address bus', and pin 9 low, means 'data bus', so serialized address, then data, for a full IO op?) OK, looks like this is actually 5 bit? https://hackaday.io/project/187468-ello-lc1 https://cdn.hackaday.io/files/1874688020630912/ELLO_LC1_Schematic.pdf Or at least, only 5 bits are exposed in the expansion bus area... The others are mclr, ctrl, VCC, and pals. Means driving a sound chip will be dodgy.

Reminds me of a Casio mini computer/smart calculator... More impressive if the display was full monochrome dot matrix with a decent refresh rate, and a small peizo speaker... Does it have any GPIOs to slap such a thing on?

I would strongly advise the 'midi instrument' approach, rather than having the arduino accept files sent to it. That is to say, MIDI is an industry standard for interfacing with arbitrary computerized instruments, and has its own communication protocol, with serialized messages for 'note on', 'note off', 'instrument number', 'bank number' 'volume/intensity', etc. Everything you really need to define when considering music. There are many already made software suites for working with these devices, including just general media players. The arduino would contain a software stack that accepts midi messages, then writes appropriate control words to the synth chips based on those messages. This would keep the software running on the arduino simple, and to the point, while still allowing reasonable control over the individual chips. (By defining them as discrete channel IDs, you can manage them arbitrarily from your midi software) Say you have 4 3-channel chips. That is 12 tone channels, and 4 noise channels. The noise channels could reasonably be configured as percussion instruments. On the arduino side of things, you would have 8 data/address bits assigned to your databus, then 2 bits with some logic gates on them to handle chip select. (2 bits is exactly right to control 4 values) the remaining 6 bits could be used to do chip specific signals, if needed-- otherwise ignored. the synth chips would be treated more or less like they were ram. This is called 'memory mapped io'. When you want to write to a chip register, you write to the chip like it was ram, using a specified address value. The address lines are used to drive chip select, etc. When the microcontroller raises the address lines before the write, those lines trigger logic which selects which synth to work with, and then when the byte is written, the selected chip does its thing. Specific suggestions on how to wire it, needs to be informed by the synth chip data sheets.

Order new belts. In theory, these should do. https://console5.com/store/fabric-reinforced-belt-for-atari-1050-tandon-tm100-4p-floppy-drive.html Other issues: possible bad bearings in transport step motor. Possible dry slide rails in transport assy. Head positioning screw incorrectly set

Probably head alignment, or rotation speed issue, yes. 360k drives have a rubber belt on the bottom in many models. If the tensioning of that belt is incorrect, the disk rotation speed/torque is not going to be in tolerance, and it will result in read failures.

Yes... protip; dont try to make a post while tired, at work, and chasing down call lights. The synth chip in the ST is the Yamaha YM2149F.

The project I linked is for a midi device. Midi is a rather old as rocks specification, but still in use today. It's an industry standard. It would allow 'live' playback of note data from the device, such as pairing it with a sequencer or a keyboard. Press a note on the keyboard, the constructed device renders the note, with responsiveness to key pressure, length, etc. https://en.m.wikipedia.org/wiki/MIDI The device has a microcontroller at its core, that uses a control program on its flashrom, to listen for midi messages over its usb port. (Like any other modern midi instrument.) It then interprets the message, then controls the synthesis chip to render the indicated note, intensity, duration, and falloff for that note message. With multiple chips, it could do polyphony.

As for your project-- A suitably beefy microcontroller with its USB interface could be a suitable host to construct a multi-chip midi instrument out of. See for instance, this Arduino based one. Since you only need 8 data/address bits to work with these chips (Aside from the SPC700 of course....), you could drive them all quite nicely from a 32bit microcontroller, with bits to spare. If you throw on some hardware mixing capabilities, some latches, etc-- you could drive multiple chips at once, and be able to have a genuine polyphony capable chiptune instrument, that you can drive from commodity midi composition software.

If you want to expand to "Chiptunes" in general, then you can also consider the SPC700 inside the SNES. It is essentially a streamlined mini-sampler and playback system, capable of simultaneous playback of several PCM wave samples with pitch and modulation controllers. It is capable of some VERY impressive feats. Since the sampled waveforms could be arbitrary, as long as they live inside its 64k memory space, it can do any kind of chiptune waveform, assuming you give it a suitably modifiable/loopable sample for each wave type. SPC700 playlist Seiken Densetsu 3 has a very rocking soundtrack for this sound chip. (Another very nice tune from that title for this chip) One of the most impressive uses of this chip that I know of, is the "Actually Voiced Lyrics, WITH accompaniment" found in Tales of Phantasia, for this chip.

Some fun listening: POKEY chiptune visualization playlist 11hrs SID music (Ricoh RP2A03--AKA, NES chiptune playlist) (Megaman 2, Dr Wiley stage 2, is INFAMOUS) Some various examples of Tandy 3-Voice chiptunes 1) 2) 3) OPL2 music collection from various DOS games

It's basically just a generic ADC. It converts a digital input to an analog output using pulsed coding. Nothing fancy at all, no tone synthesis, or anything. MIDI on the mac was garbage as a result. All of it really had to be done by the external modules connected.

Different sound chips from that era have different capabilities, and distinctive sounds. The venerable SID chip from the commodore computing line, along with the POKEY chip from the Atari ST computers, are poster children. From the PC side of things, you have the Tandy 3-voice synthesis chip (which shares some similarities to the TI sound chip), the Yamaha OPL2 and OPL3 synthesis chips, etc. Then you have the sound synth chips used on various game consoles. The NES used the Ricoh RP2A03. The Sega master system used a variant of the OPL chips used by PC sound cards-- Yamaha YM2413. The Nintendo GameBoy console had sound synthesis produced by hardware inside its CPU. The Sega Genesis and SNES consoles were both 16 bit consoles, and while they have impressive chiptune hardware as well, are not really appropriate to mention for 8bit. You can look up videos with audio produced using all of these 8bit sound synthesis modules on youtube, and listen to the differences and unique qualities of them yourself. SID is especially impressive for its capabilities, considering it was inside a budget home computer line. (Though that is a WHOLE OTHER discussion) It would in theory be possible to make a multi-chip synthesis module with one, or all of these chips on them, and route them through a MIDI controller. There may already even be such projects available.

I am on the fence if I want to order or not. I can print my own goodies; I have that big assed chiron I can do it on and a bulk roll of white PLA. I already have a PEB though-- I just dont trust it to be fully working, and have never powered it on...