Jump to content

LinkoVitch

Members
  • Content Count

    2,706
  • Joined

  • Last visited

  • Days Won

    14

LinkoVitch last won the day on October 21 2013

LinkoVitch had the most liked content!

Community Reputation

1,948 Excellent

About LinkoVitch

  • Rank
    River Patroller
  • Birthday 03/06/1976

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Mossley, UK
  • Interests
    Coding, Computers, gaming, whisky, beer

Recent Profile Visitors

15,159 profile views
  1. If you don't init the mod does the FX work as expected? Just looked at the source and u235se+6 isn't correct for modinit. modinit would be u235se+0 that however will always start with position 0, you need to get to U235SE_modinitpos, which unfortunately I haven't setup a branch to! doh! Dirty hack for now if you modify the bra.s at the head of the binary blob to jump 1 word further it will go to modinitpos instead. The code in the bin is: start: moveq #0,d0 ; If modinit has been called the default song position will be 0 modinitpos:: U235SE_modinitpos:: movem.l d0-d7/a0-a6, -(sp) ; If we were called by modinitpos then d0 should hold the desired position to start playing the song from and.l #$ff,d0 start is the label where the modinit call normally jumps to, if you modify that bra.s to jump to the movem.l after it, it will be hitting modinitpos and d0 will behave as you want. I'll add this bug to the todo list for my next release. Sorry for the cockup
  2. Which version are you using? The latest version made some changes to how things are setup. There is included demo code for both the relocatable binary blob and also the static object versions. These both init a mod and start it. 1) Yes, stopping a module call just sets a flag to say to stop the module. 2) usually the 68K won't be fast enough to have an issue to init a new mod right after a stop. I have never added any waits in myself, but I have also never tried stopping and then starting a new mod immediately afterwards. If you are not already I would recommend grabbing the latest version of the engine and using that. There were various improvements in playback quality, performance and also stopping and starting modules. HTH
  3. TBH I suspect that slapping SRAM in a cart whilst it would be faster than a ROM cart isn't suddenly going to boost the performance of the Jag to unheard of levels. IIRC, there is ONE bus, Main RAM, the BIOS, Cartridge and all the hardware sits on it.. so no clever cart ROM -> Main RAM dual bus copy action. The cart bus is 32bit, so already 50% of the max throughput of Tom. I think SainTs cart, whilst a thing of beauty and really useful, isn't designed or intended as use as a system accelerator... Huge extra capacity, and possibly slightly faster loading time for some cart games, and maybe even some extra new shiny dev toys down the line.. But its not going to turn the jag into something it's not.
  4. GGN: If you are not using Hyper-V under Windows 10, I'd recommend grabbing VMWare Player (VMWare Desktop Free, or whatever it's called this week), and use that to spin up a Linux VM.. I use it myself for $dayjob and some Jagdev funs, works really well and you can always have a VM for a specific task. It's free to use as long as not commercial use. Might be easier than fighting whatever abomination MS has fused into Win10
  5. Disagree on point 2.. Amiga was born as a home computer, it was developed and used for video editing IIRC (hence its use for titles and stuff in the era for TV and film). It was actually presented to Atari before Commodore but Atari already had the ST in the pipeline and turned it down. It's architecture that allowed it to work well for Video also meant it had some better in roads for games. Other than actual games consoles I don't think ANY manufacturer sets out to build a "computer" as a games console, they build a machine and then get it in as many markets as they can to make money, obviously the Amiga was excellent for games so a lot were made for it and that would have no doubt lead to more advertising pushing it as a computer for use at home and playing games. There is a whole branch of machines Commodore built in the Amiga line that were targeted at business, much like the MegaST and TT ranges from Atari were not aimed at the home market. You can get games for the PC back in the day, doesn't make the PC a Games console.
  6. Short answer "No" Jaguar = Games console, Amiga = Home computer. Just because the games have a similar look doesn't make it part of the family. The Amiga wasn't a games machine, it was used as such sure, but also used as a business and general computer too (look at the 2000 to 4000 range). Also the Jaguar's hardware is a step backwards in some regards to a 1200, so it doesn't even make sense in that regard.
  7. Welcome to the fold.. just remember to only operate it in a well ventilated area
  8. If the sample playback rate is higher, the pitch will also sound higher and the sample will end sooner than with a lower playback rate.
  9. From that I guess you mean "Higher pitch" rather than "faster"? Try hard coding your code to init the jag in PAL mode instead (I guess it's an actual PAL jag you have set to 60Hz?). Internally a PAL jag will look like a PAL jag even if you flip the refresh to 60Hz I'd imagine. So your code will always detect it as a PAL jag. (I've not tested this so could be wrong, but I imagine that is what's happening)
  10. You have said that they sound faster but also that they sound the same? Sorry I am a bit confused by this. Do you mean they are of a higher pitch or the module plays faster? There should be no difference in pitch (assuming your code to detect PAL/NTSC is correct, and even then really slight). There is possibly a slight bugette in the modinit routine that only sets up the mod interval to 50Hz for one system type (PAL/NTSC do have slightly different physical clocks, but the difference should be very very slight), of course if you are just using a 50/60Hz switch on a jag this could cause timing errors in the modplayer as the system clock speed won't be changed, so things may sounds a little off, both Pitch and timing.
  11. I *think* there may be some issues with the ELF build, I haven't had time to dig into it further so it is hanging around as an issue I am afraid. Might be worth you using the relocatable version which I think SwapD0 has been doing? I use RMAC & RLN exclusively to build things, the actual memory locations for those are also in the u235se-rel.inc include file if that's of help for you? (at the end of the file after all the equates).
  12. Latest release (0.24) of the U-235 SoundEngine just uploaded to our site. There are some breaking changes in this release so PLEASE read the changelog before trying to use, they are only minor but without them it won't work. Big improvements in bus access and sound quality in this release too, so I highly recommend it. And thanks to feedback from CJ an annoying bug that would intermittently kill off module playback when changing modules has been resolved! Full Update here
×
×
  • Create New...