Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About eswartz

  • Rank
    Space Invader
  • Birthday 03/04/1975

Contact / Social Media

Profile Information

  • Gender
  1. Northway, OK, it sounds like you're taking on something more complex than you may realize. Some clarification from the other side: -- TMS5220 is essentially a LPC-10 decoder chip, taking sets of bit-encoded equations and producing audio samples from it. This was done with 1978-era hardware, so, definitely a 68020 could handle the calculations (more) easily. -- But, TMS5220 is not a general audio playback chip. The audio is not "compressed", but in a completely different format, which is in the form of equations, as it were. Those equations are in a bitstream that tries to minimize storage. Several seconds of speech use only hundreds of bytes, but from that it makes an 8 KHz PCM stream with 8-bit samples. See http://www.nouspikel.com/ti99/speech.htm for more details. The sources I posted encapsulate this logic. -- So, yes, if you are able to get a high-quality PCM recording of the Gauntlet speech, and run it through whatever software the person in the video used, then you could get data suitable for the TMS5220, with all its limitations. But it's pretty much only useful if you're running it in emulated 99/4A/etc hardware. There'd be no point doing this for a different processor that doesn't use a TMS5220, since I believe the 68020 could handle much better-sounding LPC. -- Take a look at e.g. http://src.gnu-darwin.org/ports/audio/hawkvoice/work/HawkVoiceDI/src/openlpc/openlpc.c -- this is a general-purpose LPC encoder/decoder that seems like it is flexible enough for your purposes, and which doesn't have any of the emulator-specific logic buried in it. -- Ed
  2. Probably both of these emulators have accurate TMS5220 support. I compared my implementation with MAME's (the precursor to MESS) to compare some decoding tables, but the two emulators have otherwise independent implementations of the speech synthesis. I guess the distinction is whether you can use the innards well enough in a "standalone" way and are more comfortable with hacking in C or Java. See https://github.com/eswartz/emul/tree/master/v9t9/v9t9-java/v9t9-engine/src/v9t9/engine/speech for the guts of V9t9's version. (Reviewing it now, I'm a bit embarrassed at how messy it looks -- it was hand-converted from C a long time ago . But it works.) If you're willing to do some hacking, V9t9's sources has a standalone speech generator program which speaks some phrases from speech ROM and from direct data. (https://github.com/eswartz/emul/blob/master/v9t9/v9t9-java/v9t9-machines/tests/v9t9/machine/common/tests/ManualTestSpeech.java). There are quite a few things to fix in that file to make it generically useful, but if you have questions, I'd be willing to help. -- Ed
  3. Ok, this is my bug. Due to the way various OSes send keyboard events, I have to do some chicanery to ensure a smooth typing experience, and I expect CRU addresses >6 and >8 both to be read at some point before updating the keyboard and joystick state. A short-term workaround is to do TB >1 before TB >0, I think. Not directly, yet... V9t9 supports them, but it's not exposed yet. I'm pretty busy these days -- would you mind filing bug reports or feature requests for these on my github page <https://github.com/eswartz/emul/issues> ? Thanks, -- Ed
  4. Use the "Advanced Controls" (right click on the screen) and you'll get a button bar at the bottom of the screen. One of them is the debugger. (SysRq is usually captured by OSes nowadays...) I'd be interested to see what is blocking you from using your games. I'll try to fix it as soon as possible. Not at this time, though don't let that stop you from trying Thanks, -- Ed
  5. Tursi, retroclouds, thanks for the info about the .rpk format. I'll look into it. As for arc303, I do remember it challenged the earlier disk system emulation. This is definitely where debuggers help out. I once hacked in a feature to help in situations like this, which could be developed as follows: When a certain mode was enabled, the emulator could record a circular queue of recent instructions, with actual operands and all, then at a certain point (like, when an i/o error was triggered), it would dump the queue to disk. This would be preferable to what v9t9 does now, which is let you start and stop dumping this info at some point based solely on watching the screen in user time, which usually results in huge files with little context.
  6. Not to toot too many horns, but V9t9 supports the hardware-level disk access too. I was able to get it to comprehend the Millers Graphics encrypted disks. Only trouble is, you need a way to transfer all the tracks from the 99/4A to your PC. I think all the software I used for that is long rusted. I agree on this count. Serial support is hard. (The new V9t9 does not even pretend to support it.) No one wants to use the DSR level for it, and there are such bad bugs in the RS232 DSR interrupt handler that it's hard to tell whether it's working correctly or not. I fought serial support in the DOS V9t9 for a long time before just kind of giving up on it. I've seen it said before, but three cheers to Thierry Nouspiekel for providing the info that would make either of us even consider implementing serial support
  7. Okay. I've updated V9t9 with support for Pitfall (banking + keyboard fix). Like above, you'll need to make a modules.xml and add this: <module name="Pitfall"> <memoryEntries> <bankedModuleEntry fileName="PITFALL.bin" reversed="true" /> </memoryEntries> </module> (note the "reversed" attribute lets you switch the ordering).
  8. I vaguely remember this. IIRC, it comes down to supporting e.g. "SRC reg, >0" properly, when R0 also contains either a 0 or 16. 16 really means 16 in that case.
  9. Hmm, I'm not sure. Someone did contribute support for handling German keyboards... was that you? -- Ed
  10. For now, there's not much info except in the source -- it's just a pet project of mine. Basically, it's an invented processor whose opcodes are Forth primitives (DUP, LIT, BRANCH, etc). Most are one byte except for double-width primitives. It was a test-bed for the V9938 support. The ROM is built with a Forth compiler written in Java (also buried in sources). I had tried in the early aughts to use GNU Forth's cross compiler (written in Forth!) to build a Forth ROM (for 9900), but it was a royal pain. I was going to post information about how to invoke the F99B machine, but I realize I didn't include the required files in the build. Maybe I could add that at some point or mail you instructions... -- Ed
  11. Cool! I noticed you were working on an emulator... kind of lit a fire under my butt to get some of this newer stuff out there.
  12. You must have the wrong person O.o !
  13. Hmm, it worked for me with Editor/Assembler by pointing to the pitfall directory and loading DSK1.PITFALLB. Error 0 would be 'device not found'... which software do you mean when you say #EA5? (I am definitely behind the times with regard to recent retro computing.) If not E/A, then it'd be interesting to see what DSR calls it's attempting. Nope -- the file is in classic V9t9 format, which still works. If you are still having trouble, email me the config and workspace.StandardTI994A files from the ".v9t9j" directory in your home directory, so I can see if there's anything odd going on.
  14. So, what is this bank-switching method called? Guidry-switching? Thanks! I was able to make the necessary changes and get it to run from the module (this brings back memories! nice work!). But the keyboard support doesn't seem to work as expected, as you found. I'll be checking the assembly to see where I'm going wrong. -- Ed
  • Create New...