Jzintv

[artrag]

How to record the audio in jzintv?

I have tried both -Vname and --voicefiles without results 

[mr_me]

Are you talking about intellivoice audio or ay8914 audio.  That switch is only for Intellivoice audio 

[artrag]

I need to record the ay8914. The best would be to have a log file with its registers recorded at any frame interrupt 

[+DZ-Jay]

I use "-Ffilename.wav".

 

You stop recording when you exit the emulator.

[artrag]

Thanks! Any option for logging into a file the AY registers at each change or at any interrupt?

[+DZ-Jay]

2 hours ago, artrag said:

Thanks! Any option for logging into a file the AY registers at each change or at any interrupt?

Not that I know of, but I'll check.

 

What are you looking to do?  Are you trying to troubleshoot the AY stream, or are you looking to dump a music track stream to optimize the music playing?

 

    dZ.

[+DZ-Jay]

Hi, @artrag,

 

Something just occurred to me:  you could run the emulator with the debugger on, and set a "write watch" (debugger command "w") on the AY register addresses.  This will dump the value written to the console.  It will do so whenever the memory being watched is updated, so if the register is updated more than once per interrupt, you will have to adapt your strategy.  (Perhaps copy the registers into temporary variables on the interrupt, and put a "watch" on those.)

 

A couple of caveats:

• This dumps the data onto the terminal console output, in real time.  If sustained for very long, the terminal window's buffer may overrun and you lose the older history.
• I guess you could figure out how to trap the debugger output into a file instead.  One possible way would be to pipe STDOUT and STDERR to a file on the command line.  Because you won't be able to see the prompts then, you could "automate" the debugger execution with a "script" of commands.  You can give the debugger the script file in its initial command line.  Off the top of my head, the script could have:
  • w <register address>
  • w <register address>
  • w <register address>
  • ...
  • r
• I haven't tested any of this, so I don't even know if piping the STDOUT to a file will trap the debugger output ...
• I'll check to see if there is some other way to trap it.

Alternatively, if you are trying to capture the raw output of the AY, maybe there are other ways to do it in software.

 

Also, what is the source of the stream to the AY?  Maybe we can transform that into a usable format ...

 

       dZ.

 

 

 

Edited August 31, 2022 by DZ-Jay

[+DZ-Jay]

1 hour ago, DZ-Jay said:

Hi, @artrag,

 

Something just occurred to me:  you could run the emulator with the debugger on, and set a "write watch" (debugger command "w") on the AY register addresses.  This will dump the value written to the console.  It will do so whenever the memory being watched is updated, so if the register is updated more than once per interrupt, you will have to adapt your strategy.  (Perhaps copy the registers into temporary variables on the interrupt, and put a "watch" on those.)

 

Good news:  It works!!!

 

I am using a Mac, so your mileage may vary in Windows.  In the command line, I redirect STDOUT to a file:

jzintv -d myprog.rom > STDOUT

 

All output goes to the file, so I can't see the prompt, but the console is still interactively receiving STDIN.  So I blindly set up the watch ("w" command), and ran the emulation ("r" command), and let it rip.  At the end of the program, I exited the emulation, and I see in my output file something like this:

Spoiler

Starting jzIntv...
 0000 0000 0000 0000 0000 0000 0000 1000 --------  JSRD R5,$1026            0
> w 1fb
Now watching writes to $01FB
> r
 WR a=$01FB d=0000 CP-1610          (PC = $173B) t=379
 WR a=$01FB d=0000 CP-1610          (PC = $173B) t=57400
 WR a=$01FB d=0000 CP-1610          (PC = $50CA) t=105002
 WR a=$01FB d=0007 CP-1610          (PC = $5281) t=111767
 WR a=$01FB d=0008 CP-1610          (PC = $5281) t=125474
 WR a=$01FB d=0007 CP-1610          (PC = $5281) t=140413
 WR a=$01FB d=0006 CP-1610          (PC = $5281) t=155267
 WR a=$01FB d=0005 CP-1610          (PC = $5281) t=170311
 WR a=$01FB d=0004 CP-1610          (PC = $5281) t=185214
 WR a=$01FB d=0003 CP-1610          (PC = $5281) t=200153
 WR a=$01FB d=0005 CP-1610          (PC = $5281) t=215645
 WR a=$01FB d=0006 CP-1610          (PC = $5281) t=230040
 WR a=$01FB d=0005 CP-1610          (PC = $5281) t=244951
 WR a=$01FB d=0004 CP-1610          (PC = $5281) t=259873
 WR a=$01FB d=0003 CP-1610          (PC = $5281) t=274765
 WR a=$01FB d=0002 CP-1610          (PC = $5281) t=289780
 WR a=$01FB d=0001 CP-1610          (PC = $5281) t=304687
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=320123
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=334494
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=349517
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=364407
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=379367
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=394234
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=409257
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=424661
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=439096
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=453971
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=468977
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=483905
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=498836
 WR a=$01FB d=0000 CP-1610          (PC = $5281) t=513707

...

 

 

You can work around the "blind instrumentation" by running the debugger with a script:

jzintv -d myprog.rom --script=mydbugscript.txt > STDOUT

 

And put the debugger commands in the script.

I remind you again that the "watch" will output whenever the memory location is written to, not only once per cycle.  Therefore, if your program has the chance of updating the AY registers more often, you may want to modify your code to dump the registers to temporary variables on the ISR itself, and watch those instead.

 

We can then easily post-process the output of the debugger into a usable format.

 

    -dZ.

Edited August 31, 2022 by DZ-Jay

[+DZ-Jay]

By the way, the debugger watch output:

WR a=$01FB d=0000 CP-1610          (PC = $173B) t=379

Means:

• WR:  Memory was written (there are also RD watches on read)
• a=$01FB:  The address written to
• d=0000:  The data value written
• CP-1610:  Written by the CPU
• (PC = $173B):  The CPU instruction pointer at the moment the memory was written
• t=379:  The (approximate) CPU clock tick counter at the moment it happened (which can be correlated to a CPU history dump file, generated separately)

  dZ.

 

[artrag]

Thanks! I was trying to dump intybasic musics to raw ay data and use them in another custom player.

I will try your solution asap,  for now  passing through the wav file and estimating frequency and volume works as well, but the results have to be edited manually

 

 

[+DZ-Jay]

14 minutes ago, artrag said:

Thanks! I was trying to dump intybasic musics to raw ay data and use them in another custom player.

I will try your solution asap,  for now  passing through the wav file and estimating frequency and volume works as well, but the results have to be edited manually

 

 

 

What about using my IMT tracker?  I made a script that takes IntyBASIC music source data and converts it into the format of my IMT format.  Along the way, it splits the channel data into de-duplicated patterns, the song sequence, instruments, and all that.  The output of the script is a full-fledged IMT data file that will play just like the original IntyBASIC one (it even includes a replica of the IntyBASIC instrument definitions), but can then be manually edited and enhanced with the rest of the IMT features.

 

That's how I do my remixes:  I convert a source file from IntyBASIC, then I change the instruments, add drums, and re-arrange the patterns.  (I'm working on one right now.  The sample debugger output above was from that.) 

 

I could help you with that if you are interested, just let me know.  (The IMT can be easily integrated into an assembly or IntyBASIC program.)

 

     -dZ.

[carlsson]

I suppose a custom player that continuously inserts AY data may take fewer CPU cycles, but it sounds like a waste of space, plus that IntyBASIC music is rather limited effect wise compared to the IMT tracker. I don't know if Artrag has all the ROM storage in the world but very little CPU time but otherwise it would be a given to use this advanced tracker.

[artrag]

@DZ-Jay

Thanks for IMT but I did an asm player for AYfxedit by shiru

 

https://shiru.untergrund.net/software.shtml

 

It comes with a huge library of sfx from other platforms with the ay8910. The player is light and the data format is relatively efficient.

I have my own tool chains to generate .sfx files from .wav and from speech and I need only short jingles and sfx.

Edited August 31, 2022 by artrag

[+DZ-Jay]

5 minutes ago, artrag said:

@DZ-Jay

Thanks for IMT but I did an asm player for AYfxedit by shiru

 

https://shiru.untergrund.net/software.shtml

 

It comes with a huge library of sfx from other platforms with the ay8910. The player is light and the data format is relatively efficient.

I have my own tool chains to generate .sfx files from .wav and from speech and I need only short jingles and sfx.

Ah, no worries.  Let me know if I can help with anything.

 

    dZ.

[carlsson]

Oh yes, there is the 1tracker that I believe me and DZ-Jay has touched before when we touched possible editors for creating music.