LinkoVitch

They may make a single click at the start on occasion. If the sensors wire breaks it will be unusable and just make a horrible grinding noise and eventually wear out the gears/motor.

Rather than remove the sled motor I'd suggest an alternative is to remove the whole laser transport from the rubber vibration mounts, this gives you easy access to the edge of the leaf contacts (if you just need to reconnect the wire). My (now) rather ancient guide

Closest you would get to one of those would be a stock Jaguar covered in dust with dev card attached. Unless you mean the original STUB ROM jags? which were regular jags with the Atari STUB ROM instead of regular BIOS for use with the Alpine development board?

It's been a LONG time since I looked, but IIRC the Scaled objects have a bug.. sorry, feature Which is the random extra scan line you see. I *think* the solution to this is to add a blank line to the bottom of your source object. Sorry I cannot help with the remainder calcs, I haven't looked into those yet

Don't talk rubbish! everyone knows it's just 2 wires going into a FUMEZ(tm) emitter

Have you checked the voltages on the internal side of the regulator? If the internal voltages are off/missing could still be something in the power subsystem.

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

What happens?

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

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.

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

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.

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.

Welcome to the fold.. just remember to only operate it in a well ventilated area

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.

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)

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.

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).

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

That signifies "Ground"

Only Atari makes it possible!

I am sure plenty of people know this already, but just to say it again: It doesn't matter HOW you make your game, what tools you use, what language you use etc, as long as the game is fun and people enjoy it, THAT is all that matters. As for assembly, it's not the ultimate in programming languages or mad skills, it's just another language. Anyone claiming to write something new from scratch that has any complexity in 4 days of a new language I'd suggest is talking through their hats, quite probably it's more likely they are transcoding by hand previous work already written. Of course anyone blowing smoke up their own arse constantly, trying to gatekeep something like coding whilst producing pretty much bugger all ever only compounds this.

Because quite simply... the jag is a "What if.." thread necromancer! It is what it is truly capable of.. resurrection of pointless threads that should have died years ago A box of evil evil fumes! tormenting us forever!!

I personally know Retro Access from many years ago, and can say hand on heart that they only ever do anything that is of the utmost quality, making a naff product just isn't in their comprehension

I have a super cheap crappy Class 4 "J-like" 4GB in mine, working perfectly fine.