andym00

Great idea, a my weather is better than your weather thread 4C this morning, lovely blue sky, but to have gone from 30C to 4C in 2 weeks is shocking to the system

Missed this thread until just now, but by god there's some horrendously bad sounding stuff in here that isn't doing Pokey any favours at all, especially the shonky SID ripoffs.. My ears have been assaulted

I think the acceptance is down to the fact the original game was on the IIe which meant it had 128K of RAM.. If you read the thread on CSDB you can see there's people asking that same question.. http://noname.c64.org/csdb/forums/?roomid=7&topicid=87318&showallposts=1

Techinically he never left.. He has always received a salary from apple..

Altirra has always worked fine on my Vista x64 machine, and also on all my Windows7 x64 machines.. Never had any problems with it..

Then learn.. You *know* you'll get all the support (and way way more) you could ask for from people both here, and 'there' 6502 is not hard.. Load stuff from one place, optionally do something with the data, put it in another is pretty much all it is, oh, and sometimes go somewhere if a condition is met.. He apparently knows how to program so he can write it if he wants, instead he gets some kind of buzzkill out of busting everyones balls that nothing makes his beloved machine shine..

Do I win a prize because you're wrong ? http://www.gtw64.co....f/Shots_Fox.php Hm. On layer still image, one layer half char movement, and one layer full char movement with heavy flicker and simple squares.... No, no price. Oh well, can't have everything can we.. Meets my definition of 3 layers though..

Do I win a prize because you're wrong ? http://www.gtw64.co.uk/Pages/f/Shots_Fox.php

The evil side ? Which one ? I believe there was a C64 demo where the music was streamed from the disk CPU in this fashion.. ie: the drive ran the music driver and just sent register writes over the serial port.. The name escapes me though right now!! It will come to me..

Interesting... I wonder how the TurboGrafx 16 did it with it's twin 8-bit CPUs? It didn't have two cpus, is how.. You might be getting confused with the SuperGrafx, has two video chips, but still exactly the same *single* 6280 cpu..

Would be better if it was in tune.. Oh!.. Hang on

That's really cool

With ARM assistance . Ssshh Otherwise they'll debate that rather than trying to write single line kernal multiplexers edit: Bugger.. You edited it

Too 2600 like is something you say far too often.. It's sad the A8 doesn't try to use it's PMs more instead of just opting for software sprites.. I mean, look what the little VCS is banging out now http://www.atariage....picewares-blog/ To be fair though - isn't that using a 70MHz chip in the Harmony cart? Yeah, but to be fair, it's not actually doing a lot though.. Just always wondered why the A8 brigade never went for single line kernels and changing PM colours like that.. Either way, you're soon going to have a VCS game that poops on the best PM use on the A8

Too 2600 like is something you say far too often.. It's sad the A8 doesn't try to use it's PMs more instead of just opting for software sprites.. I mean, look what the little VCS is banging out now http://www.atariage....picewares-blog/

That looks really gorgeous!

He did Jelly Monsters ?? Holy cow )

lol, it wasn't the first time, and it won't be the last time

Sorry, Phaeron's right.. I ballsed the read macro up, and it was writing instead of reading!! It was all just luck since it was using whatever happened to be in the A register when the irq occurred to determine the interrupt source.. Hence the stupid beaviour I saw Nothing wrong with Altirra or VBXE.. Just I need better glasses

Ah!! You've hit the nail right on the head and I'm officially an idiot!! I was playing with the macros to do read/writes, intending to make them store a relocation table of accesses that had to be modified when the address was determined! Guess who somehow made the read macro actually do a write! I must have looked at the code 10 times yesterday but it never quite twigged that it was writing when it should have been reading.. One of those moments of reading the code, but not seeing what's actually there! I feel utterly stupid now I should have known Altirra wasn't to blame, or that it wasn't a fault of VBXE.. Anyway.. Full steam ahead then, with just a marginally dented pride

Actually, the Blitter interrupts seem to be a bit wonky full stop, in that the interrupt is raised but more often that not there's no corresponding set bit in the blitter irq status to indicate the source of the IRQ.. Odd.. Most odd.. Just having one single blit, and increasing the size slowly see the interrupts sometimes triggering and sometimes not triggering.. That explains a lot then, I thought I was going mad

I don't really know anyone who has the skills for that kind of thing unfortunately.. And I've the soldering skills to a blindfolded Orang-outang What's up with it ? Just soldering issues with the VBXE install ? Or a more deeply unhappy 65XE than that ?

Not convinced it's related to any scanline accuracy things since it's unrelated to the size of the blit I do.. BUt for sure it's a pretty hefty thing to emulate on a cycle for cycle basis.. Maybe you might be right though, since I recall one of the demos i looked at, the scroller that was kind of transparent but with character sized cells changing size for the letters was running in 2 frames, when it smelt like it should maybe have been in one frame and seems to be doing lots of small blits from the look of it and a cursory glance at the code.. Though possibly that was the intention.. Ah.. It was one of the "Scroll" demos by Electron from the release samples .zip.. Anyway.. It's not important really.. Was just curious if this was normal behaviour on the real VBXE hardware as well.. I've distracted myself long enough with this for now, and need to learn more VBXE things ff you do try them on the real thing, I'd love to know the outcome..

Oh, the IRQ_CONTROL bit seems to function as intended as long as you don't read BLITTER_BUSY around the time the interrupt would be triggered.. So no show-stopping issue there as such, just it seems to be cleared by a I intend to use only IRQ driven stuff really, makes sense, and I don't imagine there'd be much glueing together of different blits.. But then 2nd level as you describe is kind of where I'd like to work.. Seems the easiest and simplest to work with.. As for the 3rd ? I did a mountain load of that back in the 80s in a certain platform, and never again I can tell you! Simply from the debugging point of view Anyway.. Here's 3 XEXs to show what I mean.. The only difference is the timing of the rate at which BLITTER_BUSY is polled while the blit is executing.. DoBlit: lda #0 +VBXE_Write VBXE_BL_ADR0 lda #0 +VBXE_Write VBXE_BL_ADR2 lda #9 +VBXE_Write VBXE_BL_ADR1 lda #1 +VBXE_Write VBXE_BLITTER_START lda #1 +VBXE_Write VBXE_IRQ_CONTROL - ; nop ; nop ; nop ; nop ; nop ; nop lda $d600+VBXE_BLITTER_BUSY bne - lda #$1F sta COLBK rts The no delay version has no nops in the above.. The 12 cycle delay 6 nops, and the 6 cycle delays 3 nops... The blit is quite large, 256*64 in copy mode, so it's a fair time to complete, so it's not some race condition on entering the above polling loop.. The colour of the border is: Green if the IRQ activated *AND* IRQ_CONTROL indicates is was a VBXE interrupt.. Red if the IRQ activated and the IRQ_CONTROL indicates it was not a VBXE interrupt.. On Altirra here.. The no delay version is always RED.. The 6 cycle delay version flickers between RED & Green The 12 cycle delay version is always green.. Removing any polling of BLITTER_BUSY gives a solid green result as expected.. edit: Oh, and it's expecting the VBXE $D600, because I'm still learning NoDelay.xex 6CyclesDelay.xex 12CyclesDelay.xex