wierd_w
-
Content Count
1,621 -
Joined
-
Last visited
Posts posted by wierd_w
-
-
Alternatively, if you dont want to use OSS (which that write method implies), you can use an alsa utility instead.
https://www.systutorials.com/docs/linux/man/1-amidi/
As you see, it does raw bytecode messages, to a specified midi port. (Eg, "fluidsynth:0" etc.)
You would just variableize it appropriately with your shell listening daemon, so that you can send it bytecode over a tcp port instead.
In addition to fluidsynth, there is also timidity++, and munt.
Since you seem to like MT32 as an instrument, you might be especially interested in munt, however there are niggly license issues there. (Needs roland's rom files from the MT32 to do its thing.)
-
Silly man, the Pi has all kinds of things you can use to alleviate this.
Take for instance--
"mkdir /tmp/midicache && mount -t tmpfs /tmp/midicache"
"echo "(long screed of midi messages that comprise a song)" > /tmp/midicache/somesong.dat"
"echo "(player handler shell script that monitors for input over TCP/UDP to control midi playback here)" /tmp/midicache/handler.sh && chmod +x /tmp/midicache/midihandler.sh"
"daemonize /tmp/midicache/midihandler.sh"
Then you just send whatever bytecode messages over your listen port you want, to syntactically say "Play song 1 from 00:00 to 01:00 now, then loop from 01:00 to 02:50"
The pi just does it when you send that small command message.
It stores data in the pi's memory (tmpfs mount), in a non-persistent fashion, in order to "write once, play many times".
For the innards or "midihandler.sh", so that it can listen for messages over a TCP port, there are a great many implementations out there. Stack exchange has you covered in most of them.
Writing data to the appropriate midi device in the device tree from a specific file is trivial-- One could use dd, for instance, since it allows you to specify an amount of the source file to skip, AND a rate at which to write.
eg,
dd if=/mnt/midicache/somesong.dat of=/dev/somemidi0 skip=[some number of blocks to skip on the input before writing] count=[some number of blocks to write] bs=[number of bytes to read/write per block]
wrapped up in an appropriately variable-ized for loop, that takes data from the tcp listening port, and populates the appropriate areas.
Writing to the midi device this way is fully kosher.
https://ccrma.stanford.edu/~craig/articles/linuxmidi/output/section1.html
Fluidsynth and pals create a midi device that operates the same way as an external synthesizer, which means you can write messages to it this way. The midiport is the number at the end of the device file's filename.
That is how you send it an arbitrary midi command. If you want to send an arbitrary midi command instead of caching them all and then using simple instructions to control playback, then you just use "midihandler.sh" to wrap the exchanged message, and echo it to the appropriate device, like I initially suggested.
-
Oh, I know all about how rabid those people are...
My perspective is more this:
1) I did not own a Ti as a child, and so have no nostalgia giving me "expectations."
2) I am a pixel artist that does not want to wade through 500 different libraries just to display something. (So older systems are appealing.)
3) The lack of hardware sprite manipulation means having to do loopy-loops with graphic state of the display, and I would rather avoid having to deal with all the snarls of "Yet another graphics library" just to preserve backgrounds, and have good moving objects on screen, without things slowing down slower than the pitch drop experiment. This has soured my forays into game making, despite having a useful skill in that area. ( I have several game concepts I would love to realize, but found my desire to make them was not sufficiently motivating to deal with the byzantine bologna of the contemporary BASIC libraries for the system I cut teeth on to overcome these.)
4) The Ti has hardware based sprites. (YAY!)
5) It is also simple, with little library overhead. (YAY!)
6) It has an aftermarket VDP that is more capable, and a new model is being discussed (YAY! If they give me a mode I can make use of, I can make use of it!)
7) There are people that appreciate the platform, so work made for it will be seen by at least somebody other than me (YAY!)
So, the platform looks desirable to me, which is why I got one.
Then I found out "Oh, 1bpp from BASIC, because yeah.." along with "Character based drawing and pals" and "We expect you to burn up all your sprites if you want more than a single color." (which makes me sad. :()
Then I see RXB gives access to ECM3, and I go "YAY!"
Then I note that ECM3 expects you to cut up your color space in terrible ways.
I state that I can do a shitton with 16 colors, if you can manage it for me, and end up in a shitstorm.
-
the problem with that kind of thinking though, is that it embraces magical-ness, and implies "the way it was intended!!" on everything.
System engineers dont set out with such high ideals. they are given a problem, a budget, and then that budget gets cut, repeatedly. What ships at the end is the result of "This is the very best we can do under the limits imposed by accounting."
The VDP of the Ti certainly *IS* a triumph-- it can do a whole lot of things, and hardware sprite manipulation is not chump-change. (The lack of it has soured my foray into game programming from a young age-- Again, I started out life on an IBM XT era system, that only had bitmapped graphics modes, and often hard-set colors. Despite this, people more clever than I am were able to get CGA to do some very slick shit by abusing how CRT screens mangle the colors, due to the use of a shadow mask.)
I just do not hold with the expectation that it is in any way holy. I instead look at the F18A as a thought given form-- Specifically, "If those engineers were not hamstrung by expensive silicon, what would they have made in this form-factor and package size?"
In this respect, I suppose I am more in favor of the direction the Amiga community took, with how they devised wholly new graphics hardware, added PPC accellerator cards, etc-- to their systems. Adding those things does not make it stop being an amiga, or detract from its character, IMO.
-
Is there a non-macos version? (I see those decorators. That is either some awful gnome skin, or macosx.) I think I could make good use of such a tool...
I have the next two days off, I think I can make you a nice ghostbusters "press fire to start" screen, but first I need to go collect some data. Since a 15 color general palette is so limited, I want every color to matter, so I am gonna go super geek cred, and pull the "normal color vision peak curves" data I have seen before on the net, and use that to produce color pick biases, so that colors favor those best discerned by human eyes. (From the colors made available in the 4096 color color-space of the F18A, of course. The idea is to pick colors as legitimately as possible, not based on their mathematical values or properties. If I can get away with optical illusions for color reuse (See also, "Is this dress yellow or blue?"), this info will help me do it.
-
One of the reasons I think I should go ahead and proto-board build a breakout module for a pico-ATX. In addition to the +5v taken from the main motherboard edge connector, it also provides a separate set of rails intended for hard drives, which includes a GND and +5v rail, which could be connected to the same rails on the sidecar bus behind a diode. (Cut circuit trace leading to edge connector, put diode on as bridge over the cut, then put the injected power after that.) My soldering skills are practically non-existent though, so the end product would be very unattractive. I would need to incorporate a stand-alone +5v to -5v conversion IC though, because the pico-ATX itself does not supply the -5v rail. (Its makers consider it to be a legacy voltage that 'nobody uses anymore'. The intended application is for use with mini-itx boards, which use modern components, and have no need for a negative voltage rail.)
That would give me a Ti that can power quite a few devices on the sidecar bus, and could comfortably run a TiPI and the like, as well as let me use a commodity +12v DC wallwart (of suitable wattage. I would use a universal supply in the 10-15A range, with a 120W picoatx) instead of the original stock transformer doorstop.
-
1
-
-
Ghost busters you say? OK, I think I can do that..
-
Absolutely! How large of an image would you like, and do you have a preferred subject?
I have a handful of old art floating around, but nothing terribly special. I tend to favor images around 100x100 px. (I pixel art mostly as a hobby, rather than for any specific intent, but usually use between 12 and 15 colors. )
Edit:
Here's a bluejay I made some time back, that uses 20 colors (including transparent color). With some thought I could probably down-sample it to 15 with acceptable results. It would not work with a general purpose palette though, it would dominate the whole thing with blues.
I also have a silly little thing I made for an art community when the topic of drawing hands came up... (many people have problems drawing them, but I am not really one of them.) It uses 17 colors, most of which are probably the aliasing of the text.
I have this capricious habit of not holding onto things I draw, because the fun is in making not keeping them.
I dug some more-- this came up in the old dwarf fortress forgotten beast art contest. It uses what I consider to be "A whole lot of colors", at 49 colors. Most of them are deep shades, which could be substituted/culled. I used to draw quite a lot of those, because it was fun, and good practice. This guy was a giant, blood red mite that sucks blood. (the FBs are generated from a random selection of features, and are only described in text form, hence the contest to draw them.) Sadly, my current job does not afford me lots of time to doodle like my old one did.
Another I did for that contest, was a massively-overdone scene that uses 256 colors exactly.
I seriously doubt I would ever get the luxury of 256 on-screen colors like that with the TI (Seriously, that's SVGA shit.), but I really can do a whole lot with very little. Just not "8 colors" little.
-
Probably miscommunication, yeah.
I stated "high end color graphics", and have never once stated that the systems I mentioned supported hardware sprites. (I went out of my way to say that they did not in fact.) this requirement is one you have insisted on.
The argument that this needs to be in the same class of system as the original VDP, (aside from hardware sprites, and back compatibility) is artificial; the reasons for the VDP's restrictions at the time of its manufacture were practical ones-- Cost of silicon was absurd, and they were making a home computer. Today, this is not the case. The restrictions are the functional ones of running out of vram (which can be addressed in various ways), and the width of the data bus connection to the vdp (which is not.) The requested color range is within the 6 bits addressing limit, and there was already talk about adding more vram on the MK2. Given those conditions, why make such a stink over the request? Especially when the designer has expressed disfavor that "nobody is using the features." It is my position that if you give a mode that allows for a sensible palette, that people will use it. It is less "I always want more colors!", as it is "Hey uhm-- Unless you want bright, single color sprites-- you need to give a palette mode that people can actually work with without running into technical problems deep into development, where one set of sprites takes one pair of palettes, and another set has to reassign those palettes different ways-- So, can you give me a mode that can do that? The bare minimum for that is 16 colors in the palette. 32 will give you very nice results, and should be enough for anyone."
I have been trying to express that the current restrictions on using the VDP modes, even in the F18A, make it impossible to create a shaded general purpose palette. (which is what I really, earnestly need to avoid the kinds of problems stated.) I stated that I can do that if you give me 16 colors, but just barely. ECM3 mode with layered sprites is not equivalent. Matt's statement about vram makes sense if the full VDP memory space is available to the system, but that is not explicitly necessary for the VDP to do what it does. "ECM4" could use banked internal memory instead, and get around that issue. The real limit is the number address lines used, which is hard-set at 6bits due to that many being how many are on the chip socket.
As for why I need the full 16 colors, If I do not have access to all my colors, it will result in garish results as tiles that need certain colors will not be able to get them. (For each color, there is an exponential function of color combinations that are possible. With the palette restrictions as is, this is not achievable. This is why it is not equivalent, like you assert.) If the intention is to get away from "Blocky" graphics, (which anyone can do), these restrictions make doing such work impossible, or at least, very unpleasant and unrewarding. (which is why few if any people are willing to do the work*.) I would conjecture that a good reason why nobody has been using these modes, is due to these restrictions. These restrictions strike me as capriciously artificial (such as arguments about contemporaryness), so why the animosity to the suggestion to move beyond them, with a chip that is intended to move beyond them, (within the limits of feasibility)? As long as it still operates in a back-compatible setting, there should be no problem. Why is this even a point of contention in the first place?
*It is one thing to say "Look, we have NES era color and sprite capability!"-- Yes, this is true. However, the current crop of artists and other game makers have access to systems with 24bit RGB color with 8bit alpha blending, 3D vertex processing, and a raft of other things. Getting them excited over capriciously artificial restrictions makes about as much sense as asserting "We have addition! YAY!" when there are systems with built in vector math processors competing for talent. This is why I mentioned it as an allegory previously. To get a sprite artist excited, you need to give them what is these days considered the bare minimum to draw interest. 3BPP is not that thing. The technical bare minimum for that is 16 colors, with EXACTLY that many colors. (no, 2 less because of forced transparency does not work any more than losing some bits does for floating point math.)
From my perspective, I am asking "Hey, can I have the bare minimum needed to make awesome stuff for this platform?"
To which the answer has been a combination of "HISS!! HERETIC!", and "You can already do that-- (I wont listen to you why you can't)"
Essentially.
That kind of stonewalling is very unappealing and is very off-putting.
-
You just write midi messages to the midi device in the device tree like a file. You can send such messages with echo. Since you give telnet/console already, it should be doable right now.
-
Tursi, that is uncalled for.
I mentioned other contemporary basics and graphics hardware, because they were explicitly called out as not being 4bit color supporting. The one seeking the award here is not me, I just want a 16 color mode for sprites and tiles, which ecm3 is not.
Why is this so hard?
-
What I mean is that the ROM program itself contains a text string that will be displayed in the menu, and it is near the top of the structure. The TI reads this structure, and presents the string, when it gives the boot menu.
I do not know of any utilities to interrogate a rom set for this string.
-
A hex editor? There is a header baked into the roms that contains the menu entry label. This is what is presented in the list.
-
Not exactly;
The stock VDP does 1bpp unless you take hard control over it with assembler. (2 color attributes, with foreground and background color, selected from 16 colors.) CGA gives you much more, with pixel addressed painting, with the full 4 bits for color attributes, but lacks hardware sprites.
EGA gives a pixel addressable plane with 64 attributes, but no hardware sprites.
The flavors of BASIC for that class of system gave access to this with the (painfully slow) LINE command. Theoretically, tile based graphics are more useful due to definition re-use. However, they are crippled by the limited color depth, compared to what the VDP is actually able to handle.
The "Already does what you want" is not correct either; I do NOT get a unified 16 color palette, which can very much break things from a graphic arts perspective. THAT is what I am requesting-- A unified 16 color palette, not overlaid sprites, which are NOT equivalent, no matter how much you insist that they are. (The kind of argument you are making is akin to insisting that recursive addition is equivalent to multiplication, as justification for refusing to add a multiplication operator. Nevermind that when you then get to exponentiation, this becomes absurdly tedious.)
-
Oh, if you want a computer chasis for that, look into an IBM Aptiva E3N.
It is fully ATX ready, before ATX was a standard. You might need to source an LS120 to stick behind the floppy drive door though. The cutout in the back is exactly the right size and position for a form card/plate that comes with modern motherboards.
I had such a chasis floating around, but I used it to make an i5 system for a nurse friend of mine who needed a computer built on the cheap.
-
After getting the blue funk off, it might be useful to follow up with a chemical metal polish. If the contact is copper, something like brasso. For aluminum, hit the automotive store for something like 200mph all metal polish.
that will get rid of the tarnish layers that the old residue will have left on the metal. -
I was meaning that often times, these analog to digital converters impose a few milliseconds of delay while it does its processing between the source and its generated output. If yours is a good highspeed one, with no discernible delay, fantastic-- just be wary that not all such converters are so fast.
-
I have a silly question--
It is possible to get the pi to do software midi synth (fluidsynth and pals), and you can get stereo output off of one. IIRC, the audio leads are exposed on the TI's sidecar connector, so it should be possible to slave the connected pi as a music generation device, controlled by sending midi messages over the connection used to do telnet.
obligatory info on how to drive audio out off gpio pins
Has anyone done that?
-
How much frame delay is there from the SCART->HDMI converter?
-
Looks like 5v DC on the red connector labeled "power interface" in the image?
-
1
-
-
Genuine intel, or an AMD chip? AMD made some interesting chips in that era...
-
You will find that modern motherboards are no good for retrogaming under DOS, because the adapter rom region has strange things in it, (So poor ability to get UMBs), modern processors do strange things with v86 mode and real mode (Since they are optimized for 64bit flat mode), in addition to being just too fast for most old games without using something like MoSlow, and if you use something like UMBPCI to give yourself hardware UMBs, you will find strange behaviors concerning lack of DMA (because the systems are not made for realmode use.)
A REAL period board will be a much better experience. For real. (But if you want to do a 486, Get a DX-50. Yes-- They DID exist. I will NOT be pulled into this argument. They were real, I have owned one in the past. [So many times when I mention this chip, people assume I mean a DX2-50, No, I mean DX-50. As in, no internal clock multiplier, native bus of 50mhz-- then they argue with me. Similar story with 386 DX-33. I have seen that hardware in person, and used one. It existed.])
-
1 hour ago, Tursi said:Can't agree with that. 1979 didn't have a lot of color displays, period.
C64 ('82) and NES ('85) both had 3 color sprites. 16 color hardware sprites weren't normal until the 16-bit machines started out in '87.
You also need to remember the F18A has already been out for years. The changes Matt is considering for the Mark2 won't automatically all work on the previous chip. Even if he takes your requests many people will probably not be able to run the software, at least for a while!
Just make your programmer overlay the sprites for more colors. Then you can also use multiple palettes. There's no flicker to worry about on the F18A and we have lots of sprites, so there's no real reason not to.
CGA debuted in 1981.
https://en.wikipedia.org/wiki/Color_Graphics_Adapter
Supported color depth was 16 colors. Not hardware sprites, no-- it was a bitplane based setup, but still 16 colors, and contemporary with the period.
I see this fancy VDP, and think more EGA though, which debuted in 1984.
https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter
What I requested is more in line with EGA, which would still be contemporary for the period.
-
RPi power is an excellent suggestion.
The other could be hooked to a GPIO on the Pi, and used to do some clever function. Perhaps signal to the pi that you would like it to shut down gracefully, or to have it run sync on the storage. The Pi exposes the GPIOs with a convenient and easily checked file based access method, so a simple shell script running on the Pi would be sufficient. Said shell script would then handle the dirty work of issuing a sync, or graceful shutdown/reboot.
-
1
-
C64 ('82) and NES ('85) both had 3 color sprites. 16 color hardware sprites weren't normal until the 16-bit machines started out in '87.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
TIPI enabled software listing
in TI-99/4A Computers
Posted
JediMatt kinda IS the developer of the TiPI...
This is a pretty simple thing to get the Pi in a TiPI to do... You just need the appropriate pokes in the Pi's config.txt (he does maintain the tipi's firmware for the pi), and the right circuitry dangled off the right gpios on the pi.
Like I initially pointed out-- once the pi is wired up to the speaker leads on the sidecar bus, the existing TiPI command set is sufficient to send the messages to the pi.
All the pi needs is the right set of already existing linux utils, and a generic wrapper script.
I was just curious if anyone had already done this or not. Apparently not.