wierd_w

Then dont complain, just fix it!

Many walmarts carry shoebox recorders for cheap. Their ONN ones actually work as a reasonable replacement for the program recorder even.

Send me wav files, I'll be happy to review them for you.

Silly man, that's not solid state! THIS IS! That slot CLEARLY says it is for SOLID STATE software only!

Theoretically, an SDCard can be driven on a 2 wire serial interface. (SPI IO mode.) http://elm-chan.org/docs/mmc/mmc_e.html#spimode A very simple sidecar could probably do it.

It's like the 90s all over again... Covox voice thing? LAPC-1 card? Adlib compatible? AWE32? which should I get? Which should I program my game to support? I look at it from a "bang for buck" perspective. A SID Master would let me play a bunch of classic SID chip tunes; Arguably, there are MOD players that can already do that, and can live on the Pi. I could write a simple front end to just instruct the pi to play said SID tunes for me, using said MOD player. The only gotcha is with a game that wants to play SID music. I bought a TIPI because I needed a PEB alternative, and I got the one with the most bang for the buck. Now I want to explore how much bang I can get out of it-- the raw TCP data handler looks ripe for exploitation. I can use it to send any number of messages to the Pi, to get it to do all manner of things. (For instance, I could set up a the thing to render wav files for me, using some simple remote control signals and a modification of the listening daemon I would need to handle midi messages. Just listen on a different port number, and send my own custom bytecodes.) That is kinda what I want to explore-- Setting up a proof of concept framework for handling a bunch of additional services not covered by the stock ROM extensions the TIPI provides aside from the raw data handler. Things like "To send midi messages, send a message on raw TCP method to 127.0.0.1 port 3000 containing first a single byte value containing the target midi device ID, then a data string containing the midi command sequence to transmit." The listener shell script I would write would capture that input, and use it to send the command sequence to the appropriate linux commandline utility. Some devices, like Timidity++, always like to default to a specific midi device number, (in this case, 128). BUT-- if you plugged in a real MT32 on a USB to MIDI adapter, the same listener could route commands THERE instead. Something similar for a "Soft SID" could be don--- Send to port 3003, with your SID instruction word. I would route it to an appropriate SID simulator. I understand the simplicity and nostalgic joy factor of having a real bit of hardware actively rendering that audio for you, but I also understand that my wallet is not infintely deep. If I can get something I have already purchased to do basically the same thing (Render a specific kind of audio), and not spend more money, that's what I am gonna want to roll with.

I am more looking forward to routing binary midi messages over the raw tcp handler provided by the TIPI I ordered. (when it shows up.) The SID is cool and all, in that it has a unique sound and nostalgia angle, but I find raw midi handling a more enticing target, personally. It should be possible to then use the pi to route such raw midi signals to any connected midi device. (Like a real MT32, or a Yamaha keyboard.) It would be cool if we could merge the ideas, and get the Pi to be able to simulate the SID Master, but I am leery of having to get yet another toy to tack on...

I mostly fire mine up when I want a nostalgia kick for some older nintendo consoles. I admit to having mine hacked with bells and whistles out the wazoo, but it legit is for not having to dig out game discs, or having to hook up consoles in a closet.

Seeing as how it is android based, I would explore how deep that well goes. There are alternative libraries for the google app ecosystem that might be useful. Getting a still-living app store in there might breathe a zombie-like life into the console.

Ok. Video finally uploaded. Apologies for the terrible camera. The phone used to record is a terrible one issued by my employer. It loses focus repeatedly.

Ok. Nice informative post on getting DF running on an ARM based android phone. (Exagear windows emulator does not support x86 based devices.) First up, the emulator is buyware. Secondly, it seems hard to find with the playstore app. Here is a hard link that should go right to it. https://play.google.com/store/apps/details?id=com.eltechs.ed Thirdly, i have heard eltechs has discontinued development of the emulator, and did so in Feb of 2019. You might or might not be able to purchase it. Caveat emptor and all that. Necessary formalities dispensed with, this really should be called WINE for android because that is what it totally is. 32bit WINE. On Android. With eltech's proprietary x86 emulator underneath. It supports network functions, fullscreen graphics, sound, bluetooth keyboards and mice, and can run quite a lot of windows software. (Including favorites like starcraft and pals. But also dwarf fortress.) First up, grab DF from Toady's site. Http://bay12games.com/dwarves Its free. You want the 32bit sdl windows pack. The default one for windows is 64bit and wont run. The legacy one cannot find a graphics device and wont run. The sdl version works fine. Unzip the zipped package into a folder in your phones downloads directory. Fire up the emulator and make a new container. Once made, press the hamburger menu and pick "manage containers" then "run explorer" under the container's three dot menu. The wine session will start, and open the file browser. It auto mounts the downloads folder as drive D:. Copy the df folder to the container's 😄 drive, then navigate inside it. Find the executable and long press. Choose copy. Navigate to the desktop folder in the left pane. Long press in the blank area of the right pane and choose paste shortcut. The emulator looks for shortcuts made there and adds the items to its launch menu. Now to muck with df's settings. Navigate back to df folder, then the data folder, then the init folder. We want to edit init.txt Doubletap it and wait. This version of wine includes notepad. Scroll down using touch and drag. Graphics:yes Windowed:no Fullscreenx:640 Fullscreeny:480 Printmode:2d Fps:yes Save and exit. Close the emulator session by pressing the x on the hoverbar. Now DF shows up in the list. Pick it and wait. Wait quite a bit.. It will eventually start. Make sure your bluetooth keyboard is paired, then make a pocket world and have fun. All references to esc key need to be handled by the back button. The screen can be stretched to fit the device by tapping the leftmost icon in the hover menu, and the hover menu can be hidden with a 3 finger tap. Again this thing can handle all kinds of stuff. GoG installers work well. I will make a video here shortly.

Depends on what you set the text size to. (also, pinch to zoom works with that emulator.) You really DO need a bluetooth keyboard paired with the device, due to how DF's interface works, and it took me a minute to figure out why the escape key was not being registered. (Eltechs hard-coded ESC to be entered with the android back key, for reasons that escape me.) Failing that, the Hackers Keyboard alt entry method from the playstore, so you have arrow keys, ctrl and alt keys, etc.. Otherwise, I had ~11FPS on a fresh standard sized embark with a pocket world. If you were more conservative, and did a tiny embark on a pocket world, (and had a device with more ram, without zram enabled), it would probably do fairly well. The linux version "Might" run inside qemu's non-native binary support mode... but it is going to want quite a few libraries. (Wants SDL and OpenAL for sure that I know of.) Those aren't going to be there on a base android system, you are gonna have to lug around a full chroot. It would be hilarious to see DF running in text mode inside the terminal emulator app. Maybe I should take a video?

Personally, I have considered something that sits UNDER the 99 (like a pedestal), with a pass-through on the sidecar port. That would give you plenty of board real-estate. (One of the objections to a sidecar SAMS, was that the board would be prohibitively large. FarmerPotato took it as a personal challenge, and did a quick and dirty PCB CAD mockup showing it could be done in a suitably small package if more modern SMD components were used. However, the objection was that such a device would not be hobbyist DIY friendly.) For the "pedestal" idea, I was thinking a combination of an 80col adapter, a SAMS, a speech, an RS232 and centronics port, and possibly an FDC, with a sidecar passthrough. (Picture: about 3/4 to 1" thick, it sits beneath the TI, with a plastic "Wall" that is about the same thickness on the right-hand side. This has the "TI Shoe" shape, and mates up with the side of the TI, and is where the sidecar port is. Said sidecar port is a "T" branch, with the leg of the T fed into the pedestal, and the rightmost side terminating in another sidecar connector. On the back, it has a graphics out for 80col, an RS232, and a centronics port. In the space occupied by the pedestal's thickness on the sidecar side, there is an FDC connector behind a "kick-out" door.)

I recently tested Dwarf Fortress out inside Eltech's now defunct Windows Emulator for Android. (it has been a point of contention in the DF fanbase on if android devices are even powerful enough CPU-wise to play the game.) The 32bit window version runs inside, but not terribly fast. (To be expected, its lugging a full x86 emulation with it.) It was however, sufficiently fast to somewhat play a normal size embark on a pocket world. A significant factor in the playabilty is probably the device I tested on; An older Samsung Galaxy S5, which only has 2GB of RAM. (DF wants the full 4GB possible, and the Galaxy tries to provide via zram backed swap. This quickly bogs the CPU down in the compression/decompression operations, since DF is VERY memory intensive.) Given the resources available in more modern phones, I suspect that a native app would be more than just hypothetically possible, if it were not for the "not portable" nature of the closed source codebase.

Somebody thinks too highly of themselves, charging a price like that.

That would explain the 0 byte size. (Broken symlink) Odd how the symlink would get broken though.

I am thinking I need to start making some dimensional drawings for some of these projects (printed cases, system chassis, et al.) It would make some of these tasks much easier in the future. These cases don't look that complicated; I could have whipped out a case model set in under 20 min with a dimensional drawing in hand. I have calipers, I should start taking measurements of various bits and bobs, and making dimensional drawings. Do you think the rest of the community would appreciate the effort?

Hey Matt, Have you given any thought to building TIPI disk images that have partitions aligned on 4, 8, and 16MB boundaries, and with EXT4 parameters with matching stripes? (SDcards bigger than 16GB have erase block sizes at powers of 2, between 4MB and 16MB, depending on how big the card is. A 16GB card probably has a 4MB erase block, A 32GB one probably has an 8MB one, and a 64GB one probably has a 16MB one, but this is not always the case. To be sure, you have to interrogate the card.) It complicates matters for end users somewhat by given them choices, but appropriate images for their SDCard media would greatly improve not only read and write performance, but also card life. To do writes smaller than the erase unit size, the microcontroller inside the SDCard accepts the data to be written into a small RAM buffer, reads the contents of the erase unit, applies the change in that memory, then blanks and overwrites the whole erase unit to incorporate the change. As you can imagine, this is harmful to SDCard media if the allocation units being written are small. It's better to queue up writes in the computer and write whole erase units at a go. That's what happens when you set up the stripe and stride-width parameters correctly. The SDCard foundation wants people to use ExFAT because it can set the cluster size to obscene values like these. EXT4 with stripes enabled is superior, because it does not introduce slack space (logical cluster is still 4k in size.) The kernel just writes more intelligently. (queues up writes until the stripe buffer is full, then writes the whole stripe.) (For nitty gritty details, see this blog post- not mine, just useful.) https://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/ SDcard is basically just a wimpy SSD. It was always my intention to custom-make my own TIPI image from your supplied one with these parameters and partition alignments in place, but I was just curious if you had ever considered this.

I just checked-- the FTP version of the site has the document still. ftp://whtech.com/datasheets and manuals/Hardware/Texas Instruments/PHP1500 Speech Synthesizer/TMC 0285 Speech Synthesis Processor.pdf

(Watches the stream, sees FarmerPotato's presentation) Looks like I need to get on the stick on making assets!

Meh! over a buck a pop For 11x17!? I would just grab a 22" roll of paper, and print two at the same time. My printer handles up to 36" wide roll. (Or I could order a box of shiny 11x17, and use the sheet feeder, but that would take forever.) Office Depot's online store currently has 24" coated paper roll on sale for around 50$. https://www.officedepot.com/a/products/816844/HP-Coated-Paper-Roll-24-x/;jsessionid=0000ExpxUEAwWkjeYxV1SwN4Q31:17h4h7ado I would need to know how many you need to know if I can undercut that 1$ figure. (If I ran out the whole roll, printing 2 at a time and using a paper slicer to cut them apart... I would get 210 prints, assuming no misprints. That comes out to about 25 cents per map, paper cost wise. Ink is actually pretty inexpensive for this printer, shockingly. Its about 50$ per tank, and each tank holds about a liter of ink. I have brand new tanks installed.) I have some cheap bond paper loaded right now. I am gonna run your small image through waifux2-caffe and scale it up to meet the printer's native resolution and do a test print. See how it looks.

Something like how original X was implemented might be doable. Basically, graphics elements are sent once only (or as needed) to the displaying device, then the system just makes high level calls to do screen draws. Don't know how well that would play with the already existing color display device...

I have a large format printer just chillin in one of my work rooms, do you want any large maps printed? I can order some shiny paper.

Ok, i have my aquisition home now. I have hooked it to my Ti 99 for test image. You can see the canted image. Otherwise looks good. Cosmetic issues but free is just fine. I suspect that a little adjustment to the deflector plates will clear that up just fine.

Ok its a 1702. He says i can just have it. I will pair it with my Ti 99/4a.