Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by wierd_w

  1. So, how shiny do you want these? I have some 2000 grit paper that is able to put "Glossy shine" finish on this plastic. (got a few spots that has happened in accidentally while trying to get all the rough sanding marks out, but I was going to go over with a melamine sponge to get satin finish afterward.) It will just take longer. I aim to please, so let me know. I need to scrape together some packing materials to send these.
  2. The cassette index program is very useful for people without any other kind of permanent storage, and who have cassette decks without a minute counter. (see the Cassette Power thread)
  3. When I get home from work, I will see if I can get a debug trace with normal Classic99 and this fancy new 64bit build. However, "32bit software inside 64bit prefix acts in unexpected ways" is still kind of "That is entirely expected", as far as WINE support is concerned at this point. WOW64 is not that great in WINE. Avoiding it entirely, and using a 32bit prefix, which is much more mature, and has many more code-fixes for 32bit applications, is just cleaner, neater, faster, and easier.
  4. I am looking at that very site.. several Atari 2600 systems so far. A few 386 and IBM 5150s. A small spattering of old Macs..
  5. Not ENTIRELY true... Again, (since I have brought this idea up before), all you need to do is pass either a set of wave patch files, or an .SF2 file to the PI, then have a small python or other handler, that accepts network connections on some reserved TCP ports, and then accepts simple midi messages from them, and sends them to an appropriate midi device. Since the midi devices the PI has are all software wavetable synthesizers, if the PI already has the samples (because your program shits them down the PI's throat during the loading stage, then instructs the PI what instrument patch set to use-- specifically, the instruments you just provided it), then all you have to do is blurp out a bytecode message to play it, designating the sample, the pitch, the duration, etc-- in the form of a midi message. The PI does the needful and makes the sound, You just vomit up a midi bytecode message to instruct playback. That is not showstopping by any means. It WOULD however, require somebody to run some wires from the GPIO header strip of their PI, to the AUDIOIN line of the sidecar slot/JediMatt connector.
  6. My recent foray into running classic99 on WINE demonstrated quite clearly to me that it works just fine, as long as the wine prefix is 32bit. It crashes right away in a 64bit prefix. Since most systems these days are 64bit, the default WINE has is to make a 64bit prefix. Delve into the WINE documentation (or just google search), and use the necessary console-fu to generate and use a 32bit prefix for use with classic99.
  7. 32kTop_WITHDoor.stp32kBottom.stpTop_32k_door.stlBottom_32k_door.stl OK. Here is the "Current working" revision of the "with door" enclosure. The built in support material is kinda expensive, so you might want to revise. This is ordinary PLA, with a layer height of .1mm Because the supports are baked-in, turn support generation off in your slicer. I baked the supports in, because my slicer wants to incorporate supports inside the holes for the M3 stand-offs. The actual materials used, are "Desert Tan" PLA from GLRobotics, and "Wood" PLA from Lee-Fung The Desert Tan is a good, hard, and rigid PLA. Sands beautifully. The "Wood" PLA is NOT "Wood fiber", it is just "Wood colored". It is actually a somewhat "Gummy" PLA, that sands kinda poorly. However, I have not found a suitable colored replacement.
  8. Okiedoo.. Give me a bit, and I will package up some STP and STL files. I think they still need some prodding here and there, but if you want to play with them...
  9. For something that might be doable natively though-- Networked "The Omega Virus", (shameless copy of the Milt&Bradley board game), with 4 players and TI speech. The amount of data needed to be synced would be low, and the board game itself was pretty simple in its graphical elements.
  10. There really isn't another way to do this though; The TI just isn't up to having that many users hammering it with state data. Hell, it would have a hard enough time dealing with all the digested state data the client on the PI will be throwing down at at it.
  11. I designed them both. (the enclosures in the picture. I am in physical possession of the very same enclosures at this very moment. They are intended to be sent to Omega TI once I am finished with the post-print cleanup) They only look sexy like that after aggressive post-printing rework. See the "Speech synth for Beige TI" thread. It's been an ongoing trainwreck, where I decided to throw my chip into the ring. When I am completely satisfied with the models, I will release them as .STP and .STL files. (The former being useful for people who want to use CAD software to make changes.) I am a big fan of the Open Hardware model. There are people out there with much better printers than my cheap chinese knockoff i3 clone. If they want to print and sell those enclosures, I am down with that.
  12. re mud It seems pretty straight forward how to do this; Since the TI's network stack works through the TIPI anyway, have the TIPI function as either "MUD server" or "MUD Client", where in client mode, it caches resources and dungeon state data even when the TI is not actually requesting it. The TI then interacts over the very low latency connection with the Pi, via the TIPI exclusively, and is the interface used to actually play the MUD. The hierarchy would then look like this: TIPI hosting MUD server | | ---Internet --Connected TI 99/4A running MUD Dungeon Master program | --TIPI Running MUD Client | | | --Connected TI 99/4A running MUD interface program | --TIPI Running MUD Client | | | --Connected TI 99/4A running MUD interface program | --TIPI Running MUD Client | --Connected TI 99/4A running MUD interface program (for however many users in the MUD you have) The Dungeon Master program would tell the running MUD server what the dungeon looks like, where to put monster spawn points, where puzzle elements are.. etc.. It's the toolbox for crafting and maintaining the dungeon. The server program running on the PI connected to the TIPI, can leverage the vastly increased amounts of RAM, local storage, and networking functions to actually handle multiple users. The client program for the PI, connects to the server over the internet, then caches the dungeon state. It relays user actions from the connected MUD interface program to the server, which then relays it to other connected clients for caching. This allows for things like graphics data to be downloaded only a single time, and be stored inside the PI's storage, as well as reducing traffic down to just the bare minimum needed to keep the dungeon stateful. The MUD interface program would interact with the client, requesting graphics data, requesting local dungeon data (as can fit in the TI's memory), and provides the UI interface for the player to interact with the dungeon. Since the connection is over the "localhost" connection with the connected TIPI, the latency of talking to the client should be minimal. This would allow the client to do all the real heavy lifting and let the TI's basically just be interface portals. It should be possible to get the PI to execute a program, upon being called by the TI to do so, by leveraging the embedded telnet. (It should even be possible to get the TI to instruct the PI to grab the needed ARM executable from a known webhost using wget, and everything, and do so transparently to the user. They just "start the game", and the "Game" starts the client, and then connects with a running server.)
  13. As for the .LY Top level domain... The Top Level Domain (TLD) has been... Relaxed... a bit in the past 10 years, because of various for-profit groups seeking to find ways to get novelty addresses. https://www.dreamhost.com/blog/complete-guide-to-new-tlds/
  14. It was my understanding that the potentiometers that make up the analog stick, have been miniaturized to a point that the base design they were made from begins to experience early mechanical and surface contact erosion based failures, and that this is the primary factor in joycon drift. https://imgur.com/gallery/58bBc43
  15. Might be-- seems to be this desktop toy. https://www.thegreenhead.com/2015/12/magic-potion-lamp.php However, the stuff inside a tidepod (the white swirl) is concentrated UV brightener, and looks just as cool when illuminated with UV light.
  16. It looks like water and laundry soap, illuminated by a UV light, contained inside an Erlenmeyer flask. (Or some similarly UV illuminating compound in water, in such an arrangement) (that wikipedia article has interesting implications.. PVA supposedly boosts the effect tremendously huh? now I want to test it!)
  17. It could be useful for running a debugger. Data could be stored in the alternate page, about the actual program in the primary page. (alternatively, you could keep two copies of the same memory, one where you make and test binary patches, and the other undoctored. Flip the GPIO to switch sets of data in memory.) Alternatively, if you dont mind it being specific to just your system, you could write software that makes use of it.
  18. Here is the expansion port. Joystick port: Cassette Cable
  19. Yes yes, but this is a home-made enclosure, for beige TIs. The actual module only ever came in a black and silver enclosure. (and a dedicated enclosure for the TIPI+32K board never existed, because this version is meant to live inside a speech enclosure.) Omega recently splurged on Yet Another TI, this time in Beige, which from what I can gather, is an event nobody ever truly anticipated. This set of enclosures (that I am still working on) are for him.
  20. Oh? Want eye candy? A bit more work done on rough sanding before bed.
  21. Steady progress. Rough sanding underway. Will eventually be smooth and sexy like the speech on the left, but has to finish getting rough sanded first.
  22. Suitable candidate for the "Compiler treatment" for the speedup then?
  23. Elegant. I like it. Some other detail changes on the prompt string might be beneficial too, so the user knows what's up. "Please enter your 6 digit PIN."
  24. One idea might be to have such a system start in "Compatible mode", where the VDP still owns the memory, waitstates are still there, etc... but introduce a new signal to switch the system out of compatible mode, and into 16bit native mode, which then is the new "how it COULD have been" full 16bit memory access with VDP not owning memory, no 8bit multiplexer in the way, and none of those nasty waitstates. It would then be able to start and run normal TI/99 code without modification, but would still be able to hotrod into something else entirely. The wiring logic would be foolishly complicated to do that though, and there's no telling what it would do to the sidecar bus without the waitstates in place, or with raw 16bit accesses going over it. (DSRs and pals would not be expecting to be in such an alien configuration, and so they would need to be culled from the memory map, etc... Getting peripherals working would require whole new drivers that know what's what, and all that...) Maybe you could still hang the sidecar bus of the VDP behind the multiplexer, but move the (lower 16k)RAM into 16bit native, and that would be enough? Give something a little bigger for scratch pad in enhanced mode too?
  • Create New...