Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
Warnings about File Attachments - Please Read!

eswartz

Members
 View Profile  See their activity

  • Posts

    16

  • Joined

  • Last visited

 Content Type 

Everything posted by eswartz

  1. eswartz
    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. eswartz
    Sorry, I was replying to NorthWay.
  3. eswartz
    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
  4. eswartz
    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
  5. eswartz
    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
  6. eswartz
    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.
  7. eswartz
    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
  8. eswartz
    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).
  9. eswartz
    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.
  10. eswartz
    Hmm, I'm not sure. Someone did contribute support for handling German keyboards... was that you? -- Ed
  11. eswartz
    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
  12. eswartz
    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.
  13. eswartz
    You must have the wrong person O.o !
  14. eswartz
    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.
  15. eswartz
    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
  16. eswartz
    Thanks for the post (and email). Wow, I wasn't aware of a Pitfall for the 99/4A. V9t9 supports the usual two-bank module ROM switching method -- which is probably the "old" method. V9t9 has a registry of known modules in it, to make setup easy, but there's nothing for Pitfall yet. In the meantime, try registering the module ROMs with V9t9 and see if it "just works": 1) You can create a "modules.xml" file in one of the paths mentioned in "Search Locations" in the "Setup ROMs" dialog. 2) Add content like this (assuming the files are named as below): <modules> <module name="Pitfall!"> <memoryEntries> <bankedModuleEntry fileName="pitfallc.bin" fileName2="pitfalld.bin" /> <gromModuleEntry fileName="pitfallg.bin" /> </memoryEntries> </module> </modules> 3) Then click the "Switch Modules" button again and the new entry should be in the list. If indeed Pitfall does something different, then if you could provide info about Pitfall's bank-switching method (and, of course, testable versions), I'd be happy to support it. Let me know what issues you had, specifically, and I can try to help. It'd be good to get feedback on usability issues or just plain bugs V9t9 should be able to handle TIFILES or V9t9 style files in host directories, sector-based disk images, or V9t9-format track-based images. Note that I've only tested single-density disks -- never got my hands on the Corcomp controller ROMs. If you were trying that, then some work will be needed
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...