Jump to content

Tursi

Members
  • Content Count

    7,220
  • Joined

  • Last visited

  • Days Won

    8

Tursi last won the day on September 7 2019

Tursi had the most liked content!

Community Reputation

6,738 Excellent

2 Followers

About Tursi

  • Rank
    Quadrunner
  • Birthday 11/29/1971

Contact / Social Media

Profile Information

  • Custom Status
    HarmlessLion
  • Gender
    Male
  • Location
    YYC
  • Interests
    Buy me a Kofi! https://Ko-fi.com/tursilion

    Or fill in my 'SurveyWalrus' and help choose my next task!
    https://harmlesslion.com/cgi-bin/walrusquery.cgi
  • Currently Playing
    Current Project: Classic99 v400
  • Playing Next
    Next project (per survey): Website update

Recent Profile Visitors

31,354 profile views
  1. Tursi

    Hello

    Many things about the TI are confusing. You have to embrace that!
  2. Isn't that revealed by the "Subscriber" tag under your profile pic?
  3. This is a copy/paste of the example section I added to the docs: To convert a VGM file containing SN compatible music (such as from the Sega Master System) for SN output, with no editing or conversion, you would follow these steps: vgm_psg2psg.exe ab_psg.vgz My example here is the file “ab_psg.vgz”, which is a VGM containing music from Afterburner on the Master System This will output 4 files, one for each channel. They will use the file name “ab_psg.vgz” as a prefix, and then append information about the channel, in particular “_ton00” for the first tone channel, “_ton01” and “_ton02” for the second and third tone channels, and “_noi03” to indicate the fourth channel is noise data. All files will have the extension “.60hz” to indicate they are intended to play at 60hz. prepare4SN.exe ab_psg.vgz_ton00.60hz ab_psg.vgz_ton01.60hz ab_psg.vgz_ton02.60hz ab_psg.vgz_noi03.60hz ab_psg.psgsn This program reads in the processed (if any) psg files and combines them into a single text file containing all four channels. It also enforces any chip level restrictions on frequency or volume at this point - in short this output file is now SN-valid data I named my output file ab_psg.psgsn - I like to use “psgXX” to remember which chip the data is formatted for, but no syntax is enforced here. This particular file output a warning about “47 mutes mapped” - all this means is that there were channels currently muted, but they changed their frequency. To improve compression, that change was discarded until it was needed, if ever. The report will tell you if any changes were ‘lossy’, meaning the output quality is affected. In all cases you can use other tools to control how those lossy values are handled - the prepare tool will use the most heavy handed mapping available to it. The output file is now ready to be compressed. vgmcomp2.exe -sn ab_psg.psgsn ab_psg.sbf The -sn is passed to tell the compressor it is working on an SN file. It will do a final check for valid data but will just fail out if anything is not valid. We then pass the input file, and specify the binary output file. I use the extension .sbf, but this is not mandated. You can pass multiple input files to compress them into a single sound block. You should not mix chip types in the same compressed file. You will get some statistics about how well it compressed, as well as the cost in bytes per second to play back. And on my screen, it looks like this: ab_psg.vgz
  4. All right, it took a lot longer than I expected, but I have a system that auto-generates the single-file assembly versions now, so although it's not terribly pretty, it's low impact on my side and it works. Also looked at the manual and noticed it was still full of development notes in the beginning areas, so removed that, cleaned up the section headers, and added an example with explanations at the end. Download the zip again, and then have a look in Players/ti_raw - you'll see, like the old version, one source file for each combination that you might be able. The readme.txt in this folder contains condensed instructions - just select the scenario you want and you'll get a reference of the basic important functions. In that folder is also an SfxSNSample which is the exact case you were asking about, it's a quick and dirty port of the same old test app, re-written in assembly and using COPY directives to pull in the data and player, rather than linking. (Since I used winAsm994a, the copy directives have hard coded paths - change that before trying to build). The readme.txt in this file reiterates that and comments quickly what each file is - main.a99 is the one you want to look at for "how to use". EA#5 object files are included to see it run. https://github.com/tursilion/vgmcomp2/blob/master/dist/VGMComp2.zip?raw=true
  5. Yeah, but at some point he was talking about a tool that specifically changed the palette. I guess since nobody is speaking up it was nobody who is still here, or I dimension hopped again. Slideshow99 is supposed to restore the palette when you exit
  6. You've never used a def to provide a start address to LOAD AND RUN? That's impressive if so. I guess with the modern tools you can get away with it. They are very simple though. When you want to make a symbol public so that any other file can see it, DEF symbol. When you want to use a symbol from another file, REF symbol. That's it. As long as every REF has a matching DEF, you're done, the files all link together. With the standard TI assembler, the linking happens during LOAD AND RUN. Keep in mind it's been 7 months since I last looked at this. Anyway, start in Players\libtivgm2. Link with libtivgm2 - assuming you can link with GCC libraries it's already built. If not, then you are going to need to build CPlayerCommonHandEdit.asm, CPlayerTIHandEdit.asm, CPlayerTIHandlers.asm, CPlayerTISfx.asm and CPlayerTISfxHandlers.asm. It's all broken up so that C programs only load the code and data they actually need to use. CPlayerCommonHandEdit contains shared code and data used by all the playback functions. This is mostly the decompressor, and a large comment block describes the register usage (TLDR: all of them at >8300, but they are not persistent like the old player). You don't call anything in here directly. CPlayerTIHandEdit contains the main code SongLoop that you call every frame. CPlayerTIHandlers contains other functions you need to call - StartSong and StopSong. CPlayerTISfx contains the main code SfxLoop that you call every frame for sound effects. Call this before SongLoop so the mutes are set right. CPlayerTISfxHandlers contains the other functions for SFX - StartSfx and StopSfx You didn't ask, but it's worth noting that the 30hz players are different from before - instead of only functioning every other call, they process 2 of the 4 channels every call in order to spread the load. Technically this /could/ cause slight aliasing of the music (ie: a chord that starts some channels 1/60th of a second before the others), but in practice you don't really hear it. I figured if one wanted the old method, one would be smart enough to just call the 60hz player at 30hz themselves with appropriate data. We can probably merge all this into a single big file that xas or asm994a can handle. Each file contains its own data and they are pretty much marked by the sections. In gcc, you can just pass the desired address for a section to the linker, that's why I did that. If we merge it into one big file, then we can just throw all the data at the top as per normal and then it's easy to find. I would attempt it, but then I would not sleep at all today . I can potentially get to it late tomorrow night tonight. Although it's all written in C, Samples/TISNSFX contains a sample program that shows usage of music and sfx (it's the same program as the old sample, just updated). That's why I told you what page to jump to Given the amount of interest I generally get, I just write references for my own use rather than tutorials. AAAAANNND.. if you hate all this and just fall back on the old one, nobody will mind. The performance and memory gains are often only in the single digit percentages. I was expecting much better and the only reason I personally like this one more is the conversion and editing features let me do what I always wanted to do foreign music sources.
  7. I thought someone wrote such a tool already for Omega? Or did that just load a fixed palette?
  8. Tursi

    Hello

    Best reason would be you like odd architectures and brushed aluminum.
  9. Less memory used, less CPU used, better compression, and much richer toolset. Both compressors are non-lossy (most of the time), so sound quality isn't really a feature. Downsides, more complex process, but this was a deliberate choice, as I wanted to be able to convert many more sources and edit the channels. My workflow is basically to determine the processing I want to use and put it in the makefile, so it's still one typed command anyway. The code was written for GCC, and the assembly is hand-tuned from GCC's generated code. So I built with gas. The size macros can be deleted, and you can remove the section macros if you pay attention to the comments that explain why they are there (mostly to make moving the various bits of data in RAM easier). I did the same with the previous player, but I released a version with the dseg and pseg commented out. I'm not sure what you are asking here... like most TI code refs and defs are used to reference symbols in other files. Those two concepts go together...? The documentation actually summarizes the tools by what they do, just scroll down to page 8. You use three tools for that process, since you won't need to do any editing. My early code called our chip the PSG, so you have to live with that naming. Thus, you would start with vgm_psg2psg. This will output four files, one for each channel. The intent of this is that each channel can be edited with the edit tools, or even by hand since they are all text files with one row per frame. There are 9 input converters, six for different VGM chips and three for other formats. Depending on the chip, the output may not be directly playable by the TI chip, but the system has several output devices as well. Next you run prepare4sn and pass it the four channels. It will verify that all the data is valid for the SN (and it should be due to the source), and pack into a single file. It's still a text file, but it has all four channels in one. Anything that is out of range is clipped or dropped at this point - the intent is to use the editing tools to massage the data before this step, so that you can control what happens to that data. Since you're starting with the same chip, there's not going to be any out of range data. Finally, vgmcomp2 does the actual compression. At any point in the process you can run testplayer to hear what the current state of the song sounds like (roughly, the timing is hit or miss, but it reports the frame rate it's actually managing ). Looks like I didn't do a video for that basic scheme.
  10. The biggest reason for F18A garbage at startup on the ColecoVision is the short reset time -- if it's that, pressing the reset button should start the software clean, and that's the giveaway. Software that bypasses the BIOS delay needs to compensate by waiting a short time before initializing the VDP (it's usually enough to do other init first, but I have a short delay in my own crt). It's also possible to mod the reset circuit in the hardware for a longer delay. But start by seeing if that's the problem by pressing reset. (edit: my delay is about 200ms, according to my notes, and it's in my VDP startup code like so: volatile unsigned int x; // before touching VDP, a brief delay. This gives time for the F18A to finish // initializing before we touch the VDP itself. This is needed on the Coleco if // you don't use the BIOS startup delay. This is roughly 200ms. x=60000; while (++x != 0) { } // counts till we loop at 65536 VDP_STATUS_MIRROR = VDPST; // init and clear any pending interrupt (VDP_STATUS_MIRROR is my own variable, of course, and VDPST is the port for reading the VDP Status register.)
  11. For what it's worth here - you should initialize your hardware in the crt0 anyway, so that it's available before the C code starts up. You'll want to do it before the crt0 loads initialized data, if your crt does that.
  12. If you have the asm file as a separate compilation object, you can just link it in with all your other object files. You can include asm inline in SDCC with _asm, _endasm... sample here: // return the distance between a and b unsigned char distance(unsigned char a, unsigned char b) __naked { a;b; _asm push ix ld ix,#0 add ix,sp ;helpers.c:495: if (a>b) { ld a,5 (ix) sub a,4 (ix) jr NC,mikejmp1 ;helpers.c:496: return a-b; neg ld l,a pop ix ret mikejmp1: ;helpers.c:498: return b-a; ld l,a pop ix ret _endasm ; } (Not the neatest example, but the first one I knew where to find )
  13. It's amazing, isn't it? My old BBS system used to run that way. The coffee warmer was so cool I sometimes thought it was turned off. Mine blew out and was powered by the internal power supply.
×
×
  • Create New...