sack-c0s

well... I really don't know what to say on this one... Having only gotten one opportunity to meet the legenday creature in person and ply her with digestives I can safely say she will be missed. looking on the bright side there can't have been many animals which have had so much love and attention lavished on them over 16 years. My thoughts are with Jeff and the rest of his Menagerie (sp?) at this time...

The other problem is not *how much* time is taken - but rather where in a frameloop it comes from. given the colour limitations of the graphics hardware quite a bit of CPU time is taken to compensate which usually requires precision timing, making interruptions a definate no-no. sample playback is often just a case of loading a sample, placing it in the sound register, updating a pointer and exiting the interrupt but that knackers up your timings. unless of course you weave your sample code into your display kernel which would be a coding nightmare and involve overhauling the RMT playroutine. ...which has actually just reminded me of a feature - would it be possible to add some way of adding sync points into RMT tunes? a command with a parameter which gets dumped into a memory location during playback with the playroutine would work - that way you would have a sync-to-music mechanism.

Fair comment - but my tunes are done for a demo group as background music so consequently I can't go chewing up every last cycle for music playback or there's no time for video updates and other processing. I also think the 'standard Atari music style' has grown out of these limitations as a way of producing something reasonable sounding (and actually very good in cases). I don't understand what you mean by the SID being lower-pitched. surely it's outputting at the same pitch (albeit with a higher resolution, so it can be controlled and output closer to standard note pitches) otherwise it would be generating different notes and be detuned?

and if you come across an action replay on ebay I strongly recommend you grab it

Granted the SID has it's problems - but the thing that gets me about the Pokey is the lack of control over the duty cycle control on the waveforms - so sometimes it's a pain to try and avoid interference with notes across channels. sometimes a note on one channel can collide with another and wipe each others out. at least on the 64 you can use the different waveforms or if you want to just stick with the squarewave(pulse) you can set the pulsewidths to avoid these problems. I would never accuse the SID of being noisy. if anything I think *muffled* is the problem at times - but that's down to the user rather than the chip. No arguments about Mitch+Dane though. http://www.student.oulu.fi/~loorni/covert/...ols/goattrk.zip - I'd be interested to see what you can manage with a SID tracker. here's GoatTracker (Admittedly in some places not as good an editor as RMT, but a damn good player) Edit: Attached is a tune I converted from a mod by 4-Mat a642.zip

I don't think it's so much a problem with the filter (although nobody in their right mind will deny that filter can be a bitch) as some musicians are a bit heavy on the filter, although it is strange to hear a pokey fan referring to it as 'noisy' JCH (among others) is sometimes a bit OTT on the filter it has to be said. but that's maybe because all I have is new-SID machines and got used to the sound. Listen to 'chordian' from JCHs directory with it set to 6580 and 8580 - I reckon that sounds a lot better on the '80

I have to agree - that was the last C64 game I ever brought. The main character (Mayhem) is a stack of single colour hires sprites as apposed to a lores 3 colour sprite. enemies used colour flickering to blend new colours, the parallax was down to bitshifting a repeated pattern in a character block. OH - and the level preview bouncing in is down to a hardware scroll hack. These are all old tested tricks though - any C64 coder could do them, what made mayhem in monsterland special though was the Rowland brothers knew how to put together a bloody good game No matter how you dress it up a laserdisc game is still a laserdisc game. Admittedly timetraveller was a good one and you pretty much did feel like you were playing it. Holosseum was little better - but there were much better fighting games out there on more traditional displays. in short: I think players saw through the hologram and into the games and saw they weren't really that special after all. plus you could be sure some prick would wave their hand through the screen at a crucial moment, ruining your focus and forcing you to make a wrong move.

heh - my rendition will be finished as soon as reality allows (Currently got a job search on my hands, PC projects related to that ongoing and a handful of bits of music for Atari/C64) I do like the drums in that version though - Have you Listened to Arkanoid on the C64 by any chance emkay? I wonder what you could make of the drums in that... Edit: whilst I'm here - have another C64 cover (TMR will no doubt tell you where the original came from because from the top of my head I really can't remember ) arkanoid.zip introtune.zip

i think what he really means is 'sack - where the *fuck* is my music?'

Well I have to apologise for slacking somewhat (the job centre are getting rather insistent I find a job, and there's other music underway too... ) but anyhow - here's a preview of what I've got done so far - I know it needs finishing (obviously) and the instruments need balancing out volume-wise. I did ditch the original .rmt file posted to the thread though, so if that counts as cheating then I'm just a big fat cheat cybernoid_preview.zip

whereas the 8580 has almost no filtering whatsoever. I think the 6581 sounds better - but at the end of the day it's down to personal preference. The 8580 takes a different voltage anyhow IIRC, so changing from one to the other could require a bit of redesigning of hardware

Emkay: just shut up and write some music will you? Let the finished product do the talking

if the clock frequency is higher than that of a c64 passing the same frequency value to the chip will produce a higher pitched sound. to make use of existing tunes and editor clocking the chip at the same frequency as a PAL C64 would be ideal. but I'm not sure of the practicalities of that on the hardware front but on the plus side 100/200hz update tunes (like the wizball theme) sould be able to run alongside demo parts or ingame as it isn't stealing cpu time to update the music

oh balls... so that counts out calling a c64 driver once a frame then copying the register values to the new SID space...

How do they work from a programming point of view - do the SID registers just appear in the atari memory map at some point? if you could map them to the same address as they appear on the C64 it's be fantastic because it'd then open up a a mass of prewritten music (not to mention an existing windows music editor)

easiest thing to do with the c64 kernal (BIOS) is to flip the banking bit and use the RAM under it instead the kernal won't be much help - and any decent debugging is usually on the cartridge (I recommend the action replay)

About 'the fourth voice' Maybe this is a reference to SIDplay, which had a fourth voice added to the emulator and some SID rips were patched to play samples using it as opposed to (as martin galway so elegantly put it) 'wiggling the volume register' ? If so this was a hack by emulator authors and never existed as hardware.

I'm up fer that one

But on the plus side you could upload your own code to the 1541 and have it run native on the drive. by doing these you could implement a pretty fast disk turboloader. or there's the good old action replay cartridge

well if you want a snapshot of it with Robin hood, or alongside the oldest pub in england I could do that

regardless of the C64 vs Atari argument (Although I'd have to side with the 64 too) I don't think either company could pull an advert out of it's ass to save its life

I'd recommend either the C64 or the atari home computers. probably the C64. The thing with the C64 is you can set your own limits - if you don't want to get too bogged down with limitations of hardware you've got a nice machine there with decent graphics capabilites for an 8-bit, hardware sprites that are easy enough to use and you don't have masses and masses of overhead like you do on the beeb. once you've gotten the hang of that you can start playing with the other things the machine does - like border removal, FLD/FLI graphics tricks and whatever (these tricks take a bit of thinking about - but are pretty much bread & butter stuff for VCS coders ) There's also plenty of folks willing to help you and tools available. the emulators (VICE and ccs64) are pretty much spot-on so there's not much likelyhood of you doing something that breaks and emulator that works on real hardware and vice-versa.

so.. it's pirates who send devco's out of business eh? publishers changing thier minds, pissing developers about and holding off payment until the last possible minute wouldn't be a contributing factor then? I like the way they say that paying for your software is as easy as picking up the phone - they seem to have forgotten the 'earning shitloads of cash to pay for it' part. and in a lot of cases (take computing studebnts for example) that software is needed to build up the skills to get the job to buy the software. Catch-22.

I'm 22, started buying Atari stuff at 19 (Not really a serious collector or anything - just go for things I'd like to play). had my first computer (Commodore 16) aged 5, taught myself 6502 aged 12... now I get funny looks for being an old bastard in a young body

No bro.. you obviously don't know what crap is. I own an Acorn Archimedes - so I think I've got a pretty good idea There's a big difference between 'a bit crap' and 'the worst game ever written' though. After a bit of a play sesh today I thought it was better now I know what the hell I'm doing - but sometimes the collision detection is bloody infuriating (It looked as if I should be picking something up but in actual fact I fell down a bloody pit again - AARRGGHHhhhh)