mrvan

Ultimately the routines poll to determine if speech has stopped. The methodology is not perfected but still plays as well as XB and alllows a C program to continue executing while speaking as long as there’s brief moments of idleness, thus the cooperative part. That can be as little as scanning the keyboard. I’m thinking of future versions that add isrs and operate like the sound does. Still, makes me wonder why TI didn’t do that. Perhaps the slow responses of the voice synthesizer were a problem.

Wow, thanks FarmerPotato! Lots of good info here. Yes, Blue Wizard it is. I'll definitely look into what you provided as I get into some game development. I really like speech and I thought that made Parsec so much better than it would have otherwise have been. My routine is on the simple side, injecting words from a circular queue when the speech synthesizer is idle. User programs can send speech single words or an array of words that then are queued. It's all C except for a couple of short methods that embed ASM and that I borrowed from JediMatt42's Force Command code base. Because I'm using coop-multitasking type techniques I don't have to be overly cautious about other operations going on as a true ISR would. I have so many projects I want to get into, speech synthesis, multi-processing with paging (ala SAMS) and much more. It's probably time I get into writing a game of some sorts to force some assessment and learning.

Interesting. Thanks. I’d not have expected the EA manual to have gotten into that. I read that manual about forty years ago, LOL, but just didn’t remember that being present. Will look that over. I’ve reviewed libti99 and your force command code and have used both to develop a cooperative multitasking playback of speech words defined in libti99. The queuing is only via arrays of the speech phroms. So all dressed up and few things to say. I may resort to a solution with extremely limited dynamic “translation” and generate most speech in the dev env. I looked at a tool yesterday that runs on the Mac (my native dev platform) but it’s not been maintained for almost a decade. May need to see if it can be resurrected either by the author or other contributors, or if necessary, me. Seems to be a bit of a dark art.

Thank you that’s good to know.

Is there an existing method to translate text (char *) to the speech synthesizer's word library dynamically (while running), similar to Extended Basic's CALL SAY? A way is to generate a hash for each word to produce a lookup table, but the resources for its storage are not insignificant.

LOL, yes, you are right! Just goes to show the challenge of radix 100 on my brain.

I've noted that the compiler doesn't generate float (double) literals correctly. Has anyone other than insomnia made any successful attempts at updating the GCC compiler or are we all running with frozen version? As far as I can tell insomnia has permanently left the building. I'm willing to take a go at it at some point, being a fairly low priority. But if someone else is maintaining the compiler in anyway I will happily request help from that person. I pretty much have all the double math and conversion methods complete, including those that the GCC compiler calls when substituting operators. The descriptions and examples of radix 100 are unfortunately incorrect, possibly being the root cause of the compiler's incorrect implementation. From https://www.unige.ch/medecine/nouspikel/ti99/reals.htm: exponent mantissa decimal >40 >01 >02 >03 >04 >05 >06 >07 1.020304050607 correct >41 >01 >02 >03 >04 >05 >06 >0B 10.20304050611 incorrect -- notice that the exponent is 41, thus the number must be >= 100.0. This is mixed radix 10 and 100. The actual value is 10x that stated. >40 >10 >20 >30 >40 >50 >61 >10. 10.20304050611 correct These TI tech pages are rich with info and I've learned a lot from them. I suspect this has gone relatively unnoticed since the use for doubles is quite limited--its not as if we're all out there developing scientific applications, and generally most math going on is probably integer-based. Much of my current project is developing C libraries, usually those included in libc, at least the more commonly used, and the floating point support is just part of completing the missing aspects.

Ya, it won't likely be much longer for what I intend--maybe wait until the next weekend since I still work.

I purchased a cheap TI-99/4A off ebay with the claim it worked (it did pretty much) and had a clean and relatively indented case and came with a speech synthesizer. This is intended to be my cheapo unit with another refurbished unit coming soon. I wanted to have at least two so I have at least one usable system should one fail. The video was poor through the RF adapter. I replaced the video processor with the F18A and that cleaned up the video nicely and provided crisp VGA output. I played a few games of Parsec and Munchman with TI joysticks (that are a bit stiff). All seemed to work pretty well. I hadn't tried to program anything on it, which pretty much requires most keys on the keyboard to work) but as soon as I did I found the spacebar didn't work and then I checked all the text keys which worked. I have the Alps keyboard. I was able to clean the space bar key with contact cleaner, and it took several attempts to get it to read under 1 ohm. Silly me I put the computer back together and only then thought to fully test all the non-text keys and found FCTN didn't work either. Back apart she came. Same process worked well and I decided to spot check some more keys, including all the ctrl, shifts and alpha lock. ctrl read about 50 ohms so cleaned that as well. On the others I commonly read 0.2 to 2 but some 8-17 ohms. I know the latter range isn't great given these keys are simply switches. But considering the keyboard circuitry it seems that pretty much any resistive reading under infinity will ultimately allow a key to register. Does that make sense, or what is your experience? Next time a key doesn't register right I'll go ahead and clean them all well but seems good enough for now. I could spend all day cleaning all the keys, and truthfully I don't want to do it unless I have to. And with some use I imagine some resistance may fall. Who knows how long the computer just sat, maybe decades. Anyway, she went back together just fine and all the keys are working including CTRL and FCTN-based keys. Once my memory side car and TIPI arrive I'll be able to run some of the SW I've written, that require 32 KB and a storage device. At least I know I'm most of the way there. The refurb computer will also have the same equipment. Luckily my wife is declaring one of our rooms, soon to be spare due to a kid moving out, a man cave. Just in time!

Thanks Matthew180. Excellent feedback. I’m looking forward to trying out the f18a after I get some ram. All the demos I have req the memory expansion as does my personal code base.

Thanks mizapf. I think this is my issue. I’ll check into the logging.

I have a lot 0f learning to do on this vdp. I just installed it on my eBay special ti99 but don’t have any expansion ram yet to try thing out.

Good to know. I don’t know much about extended attributes yet. I would rather reuse what is present.

I was attempting to increase performance and did so, primarily due to minimizing the updating of the vdp address for every character written. The resource utilization in my implementation is high though, and reduces compatibility in an already small community. My current thoughts are to mostly use your conio but augment slightly to minimize the address writes. I think that could be done by not driving all output through the putc method and allowing puts to write chars sequentially to vdp as possible.

I’ve developed a conio prototype that otherwise uses libti99 with gcc. It is relatively quick in that vdp writes are aggregated eliminating setting the vdp write address for each byte. Screen scrolls are also faster as the parts of the display that have been written to are cached in ram thus eliminating the reads from vdp. I wrote this as most of my planned work is expected to be text based. But as one could imagine there’s several costs, being extra RAM, and about 2KB code. The RAM is about 1KB and will be around 2 in the 80x24 text mode of the F18A. I understand vdp ram access to be slowed mostly due to the fact that the stock vdp is busy updating the screen. Does the F18A eliminate much of the delay since it runs at 100MHz? The trade off of resources to performance in my implementation are significant and I wonder if the gains will pretty much be lost in using the F18A. I thought I read it has some sort of hardware scroll as well. Thoughts?

I'm not yet using TIPI in in the MAME emulation, just emulated floppy and hard drives. I should look into that, though, as TIPI will be my only drive source in the physical TI99 I'll have once you ship me my machine :-). I'm looking forward to its receipt now that I have the FinalGROM and nowhere to insert it.

Ooh. That's great information. I coded a table of lowest addresses for the FDP reserved area from what I found on the TI Tech Pages. Then used the array index based on the value passed to files(). Reading from scratchpad will be far more satisfying.

Thanks FarmerPotato. This is all excellent advice. I'm using libti99 and it's keeping me honest and not using any external references, other than those for floating point support. They're fixed in ROM in the machine so relatively safe. I'm setting up the VDP registers and charsets. Amusingly the charset patterns were in the file that wasn't being opened so I was getting those clunky versions from the TI startup screen. Initially I thought my program was crashing because I saw nothing at all. That was because my style is mostly using lower case and those definitions were all blank--goodness! I found the references for VDP memory usage by # of files that can be simultaneously opened and use libti99's files() method to set them. One of my libraries is tracking allocations in RAM and VRAM so I can determine if any area is double booked.

Also good to know. libti99 is at the core of all the work I'm doing. I'm very much depending on it. Thanks for developing it. And BTW, I saw a YouTube video of your Dragon's Lair port to TI99. I'm in awe. I also found the notes you took while on the journey and enjoyed reading them. I looked all over for a DL cartridge I could purchase and found not a one. I'm sure everyone that has one will not be letting theirs go.

Thanks jedimatt42, I am using libti99. That was a big help confirming the dsrlnk methods from a rom based program (fcmd). Knowing that I could trust those methods allowed me to chase this elsewhere. I have discovered the problem...and how glad I am... Through a bit of trial and error, I've realized that there is a small number of seconds (~ 3) after startup for which my emulated hard disk drive controller doesn't respond to requests. I can start MAME and enter the cartridge program in less than a second and if I do so the hard drive will not respond. If I wait 3 or more seconds from the startup screen, file access works just fine. Doesn't require staying on the startup screen--moving to the cartridge menu is ok. So this could be an emulation thing only, or how the hard drive controller is, etc. I may never know. I don't have a physical TI machine yet. I have one on order, but even then will not have a real hard drive or floppy drive. The only "disk" access will be via TIPI.

So I'm still chasing down these extra things that XB and EA set up that allow for file access using the DSRs. I began to wonder if my MAME configuration was somehow damaged, so I wrote a small TI Basic program to read one of the files I have on the emulated hard drive. It read just fine with the emulated cartridge inserted. By happenstance, I exited TI Basic with 'bye' and went to the TI splash screen and then selected my cartridge. It ran just fine. Fonts were loaded from disk, my sample file display method ran while using the C stdio f* methods, and all was good. Something was different... Turns out my cartridge program works after using TI Basic but not without. There's got to be something my ROM based program needs to do, and probably my EA5 programs should do. Any ideas???

Excellent, I've ordered one. I'm looking forward to all the gear I ordered with it.

Hi Arcadeshopper, is this batch still available? I ordered several items from your site a few days back and some were preorder as well. Perhaps this’ availability will be similar. This would be nice to have even if only for the more crisp display.

I have a semi-complex program that I've culled down to fit in a ROM. It includes file access though the DSRs. Migrating the program from EA5 to a ROM yields an otherwise working program short of the ability to perform file access. The DSR_OPEN dsrlnk returns 0 as expected, but DSR_READ dsrlnk returns DSR_ERR_FILEERROR. This only happens with the ROM program and not the EA5. I suspect that something is set up by Extended Basic or Editor Assembler that then allows the EA5 to happily open and use files. This same something doesn't happen with my ROM-based program. I've found info that describes what XB and EA do to initialize the system but that seems to all be associated with setting up the VDP (modes, screen address, pattern address, etc.). Any thoughts on what that missing something is, or perhaps some pointers to documentation? Thank you in advance.

Yes, it certainly is. Seems it would work just fine.