Jump to content

Tursi

Members
  • Content Count

    7,372
  • Joined

  • Last visited

  • Days Won

    8

Tursi last won the day on September 7 2019

Tursi had the most liked content!

Community Reputation

7,128 Excellent

3 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,713 profile views
  1. No, he just wants to argue. All I wanted to do was correct the mistaken impression that GPU code is required for smooth scroll on the F18A. Maybe you should read /my/ post where I said I wasn't debating your reasons, but go ahead, I'm sure you can make it so I was the one who was wrong. You stated something erroneous, you were corrected. I am now walking away.
  2. I don't think anyone mentioned split screen, but do you want to discuss it? We can make it look like a register in about 5 instructions, I can give you those five instructions and you're set.
  3. You don't have to use the GPU for scrolling - the F18A scroll offset is a register just like every other video chip with hardware scrolling... Not debating your reasons, but don't muddy the water.
  4. I posted timing diagrams for all kinds of reads and writes here as well, a few years back: https://docs.google.com/document/d/16seTZczVk_We9FNbwMp2q5hLOKgwkVJitHrRKoH4VAo/edit?usp=sharing
  5. I use SDCC under Windows as both C compiler and assembler, and BlueMSX, Colem, or Classic99 as my emulator (Classic99 isn't complete enough to be my sole tool yet ).
  6. An XB subroutine to do that is included in the zip I posted
  7. Nice! An additional solution to the last note hanging is to just make sure your input song ends with a mute command. If it doesn't, you can manually add one to the psg file (the one you create with prepare4sn.exe) by adding one extra line with all the volumes set to 0xf: 0x00001,0xF,0x00001,0xF,0x00001,0xF,0x00001,0xF
  8. In the guise of recent work, I was also inspired by confusion between VGMComp and ROM Playlists... So there is now also a psg2playlist exporter and playlist2psg importer. Mostly good for curiousity, I think, but it was fun to play with @Asmusr's sound list ripper. That's on top of the Extended BASIC sample player routine I added but never mentioned here. Everything was updated: https://github.com/tursilion/vgmcomp2/blob/master/readme.md
  9. Yes... this is what Classic99 injects into TI BASIC programs to detect if they are breakpointed (when creating a BASIC loader cart, there's an option to prevent that ) * The protection code itself - checks if the BASIC program is still running. * if not, it resets the console. PROTECT MOV @>8344,R0 * Test state - 0=not running JEQ REBOOT MOV R11,R0 * Save return address (CLEAR test only uses R12) BL @>0020 * use the console routine to check CLEAR JEQ REBOOT B *R0 * all okay REBOOT CLR @>83C4 * Disable interrupt BLWP @>0000 * reset The first test shows 1 when running and 0 when not running, unfortunately, pressing FCTN-4 to break the program doesn't clear the flag until the user presses enter at the prompt (any command, even empty). That's why I added the FCTN-4 check too. (If the program exits naturally, it resets to 0, but if an error occurs it is set to 0xff until the user presses enter). I suspect my code should be testing not equal to 1 rather than equal to 0, to catch errors too... but that's okay. I don't know where this info came from though... so there may be a better way.
  10. Thanks for your efforts, @senior_falcon. I've posted the updates to the XB player code over in the other thread so it was in the same place as the first one.
  11. Even though some of this discussion has moved over into the XB256 thread, I wanted to post the update here so it's all in one place. To be clear to future generations reading this thread, the XB player is part of the VGMComp2 package and the latest version is also in that. Anyway, this is an updated zip to help compatibility with the compiler - the only real change is that it recognizes both 'MUSIC' and 'music' as the DEF tag for the song, but this required changes to the TISNOnly.obj and the XB subroutines that were in the readme file. Everything XBish is still in this archive. ti_xb.zip
  12. Yeah, the confusion that you are seeing, @whoami999ster, is that my compressed audio is NOT a sound list. It's just data. A "sound list" is actually another specific data format, that is played by the TI's ROM code. The byte data looks the same, true, but the meaning of all those bytes is completely different. Your music has a lot of volume changes (to make the sound of the instrument), and in a sound list each of those is another couple of bytes of data. I don't think your music would fit in memory as a sound list. IIRC, it was pretty close to full even with the compressed music. @senior_falcon - the player I've suggested that he use doesn't have sound effect capability, but I have one that does. The "sfx" version will let the music keep playing with only the channels that the sound effects use being overridden. However, since it takes twice the RAM and up to twice the CPU time, I wanted to keep it simple. Sorry it turned out not to be
  13. I already have a tool that converts binary files to EA#3, though it's not terribly flexible (it only outputs absolute data). I used it for some XB stuff way back in the day. I dunno. Offered if it's useful. While I use OBJ2BIN a lot, BIN2OBJ I haven't looked at in many years. https://github.com/tursilion/tiobj2bin
  14. Well, since you have to assemble it anyway, you could just copy/paste tiSNOnly.a99 into the same file as Guile.a99 and build them together (just make sure there's only one "END" statement ). That will give you a single object file and should load fine. (I did a quick test here and it worked fine). When you modify the XB side, just make very sure you keep the CALL LINK("STOPSN") after the load. That does some startup initialization on the player. (The earlier STOPSN is also important - if you run the program twice in a row, it makes sure that the interrupt is turned off before the CALL LOAD happens - otherwise you'll probably crash ) But yeah, just copy the code and data into the same assembler source file. Delete the extra END and it will work fine.
×
×
  • Create New...