Jump to content

wierd_w

Members
  • Content Count

    1,434
  • Joined

  • Last visited

Everything posted by wierd_w

  1. 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
  2. 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.
  3. 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!)
  4. 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.
  5. Here is the expansion port. Joystick port: Cassette Cable
  6. 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.
  7. Oh? Want eye candy? A bit more work done on rough sanding before bed.
  8. 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.
  9. Suitable candidate for the "Compiler treatment" for the speedup then?
  10. 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."
  11. 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?
  12. I dunno if my ISP offers NNTP or not... I should check. I remember once upon a time it was a standard feature of ISPs.. but that was aeons ago. EDIT: GIGGLESNORT! Check out how dated this page is!! http://tools.centurylink.net/help/newsgroups.html Netscape navigator! Oh--- How quaint!
  13. Upon reflection, perhaps the Horizon Ramdisk could be adapted? It just needs memory access (which we have with WE, MEMEN, and pals), the GROM select (to get its DSR), which we have-- and access to the CRU bus, which we have with CRUIN. (Does need CRUCLK though... Again, does the Tutor use CPUCLK for this instead?) Somebody with more skill than I have is needed, but it might be a good candidate for an existing device that could be adapted to this system.
  14. He does not have perfect matches in the image you supplied already. Compare the rightmost enclosure there, with the orange of his data recorder. (Or even the shell of his FinalGrom, with is spraypainted beige TI) Personally, I would not use paint on the beige TI anyway. I would use vinyl dye.
  15. why spray it-- just print it in orange.
  16. Comparing notes, some lines are not present in the Tutor, while others not found in the 99/4A are. Specifically, it looks like CRUCLK is not exposed. (which is odd.. why expose CRUIN, without the clock? Is it sync'd with GROMCLK or CPUCLK on the tutor?) Additionally, IAQ, MBE, PHI3, and AUDIOIN do not seem exposed. You DO however, get some extra voltage rails, and "whatever those "INTx" lines are. Otherwise, the data and address lines are conserved, you have WE, MEMEN, DBIN, and pals--- So some things might work fine, others not so much. Perhaps if you slipped a small microcontroller on to generate the missing signals, and had some way to keep it in sync with the tutor, you could drop 4A peripherals on it.
  17. Ahh-- There is a pinout for the "IO PORT". CRUIN, MEMEN, and co appear to be present. This looks like a derivative of the sidecar bus. That looks like it would be your most appropriate target. It would be hilarious to mangle up a custom connector to attach a PEB.
  18. I was meaning, what lines are exposed by the cartridge port? It might be possible if WE and pals are exposed, to put a storage device on there.
  19. It might be even EASIER to just straight up pad 6 bytes worth of spaces. This is especially true if there is no upperbound condition for failure on string length. It would satisfy the requirement (input string > 6 bytes), in fewer decisions. (input less than 6? Pad 6. End of discussion. Length of 6 guaranteed)
  20. Sounds to me that the better solution is to pad a short string (less than 6 characters needed) with some space characters at either the beginning or end. If the player inputs a short string, inject the correct amount of padding for the function to be successful. This means the password written and read back will have pad bytes, the function will fire properly, and the user is none-the-wiser. (It will act as if it accepted and used their short password) It should be doable with like, 3 lines of code (if even that) with an inline IF statement. EG, IF LEN(INPUT$) < "6" THEN IF LEN(INPUT$) = 1 PASS$ =" "+INPUT$ ELSE IF LEN(INPUT$)=2 THEN PASS$=" "+INPUT$ ELSE IF LEN(INPUT$)=3 THEN PASS$=" "+INPUT$ ELSE IF.... Etc.
  21. He gets that on the speech synth enclosure.
  22. (Still thinks that having a shared mount with NFS over a NAS is the way to go. Define it in /etc/fstab so it gets mounted very early in the boot process, before the TIPI daemons run. Then your disk images are all natively on the NAS rather than on the SDCard in the TIPI, and your configuration data is conserved too. Clever use of ssh at the NAS would let you use symbolic links with several discrete shares set up for different TIPIs, so that the same disk images are natively available to all TIPIs in the constellation, while retaining unique configuration folder structures, etc..)
×
×
  • Create New...