andym00

I should have mentioned that this is everything disabled, no other interrupt sources at all around, and using $FFFA, just a raw 6502 + VBXE really.. It's fair enough, it *seems* that reading BLITTER_BUSY can clear the interrupt flag.. I've modified my test case.. Ah.. Bingo! Got it now It appears the interrupt is always raised even if I poll the BLITTER_BUSY flag when that's happening, but if reading BLITTER_BUSY when the IRQ is raised., and IRQ_CONTROL should get set, that in those circumstances IRQ_CONTROL doesn't get set, or is cleared by the BLITTER_BUSY read that is currently completely before the IRQ fetch process begins.. But again, this is in Altirra, but it seems like an odd thing to happen, which is why I'm curious.. As for why, irqs & polling I just like the idea of an interrupt driven chain of events for building the screen whilst getting on with other things, and this was purely an educational exercise to get to grips with the hardware and see what we shall see I wouldn't serious use it, but I just want to understand properly the ins and outs of the VBXE..

Just wondering if it's possible to mix and match the two methods ? Whilst a purely IRQ driven approach seems to work fine, it seems that reading BLITTER_BUSY will also stop any interrupts happening if it catches it ? I mean if I start a blit with IRQs enabled, and then sit in a loop just doing: - +VBXE_Read VBXE_BLITTER_BUSY bne - And all the interrupt does is: IRQ: pha +VBXE_Read VBXE_IRQ_CONTROL and #1 bne .blitter_done pla rti .blitter_done: +VBXE_Write VBXE_IRQ_CONTROL lda #$0F sta COLBK pla rti The the IRQ will never fire.. Introducing small delays into that seems to allow the interrupt time to respond.. 0 cycles, just the LDA/BNE means the IRQ never triggers.. 6 cycles extra between the read and it's 50/50 whether or not the IRQ triggers But by the time the delay is up to 12 cycles (+the LDA/BNE time) between reads of BLITTER_BUSY the interrupt is always being triggered.. But it appears that reading that flag around the time the blitter completes also means an interrupt never gets sent ? I don't have a real VBXE (yet!) and this is only using Altirra, but is this the expected behaviour ? I know I should either really use purely an interrupt driven approach, and I absolutely intend to, but I'm curious to know the expected behaviour of this just for my own sanity edit: Anyone wanna sell me a VBXE, pretty please ?

Altirra does a very good job of the aspect ratio problem, I don't see how it could be dealt with more correctly.. With preserve aspect ratio enabled, it looks as expected in both NTSC & PAL..

That link is a bit malformed.. http://www.virtualdub.org/beta/Altirra-1.9-test20.zip

You can kind of double buffer the colour ram, sort of with a bit of VIC jiggery pokery:) If you abort the bad lines every other character line VIC will just display the same colour again, and same character data again, but still advances the colour RAM address regardless.. If you swap character sets on these (previously) badlines you can create an 8x16 character matrix with one attribute per character.. You can then swap colour RAMs by doing a line crunch on the first line, or not, so being able to swap between the odd or even lines of colour ram, and with that you have double buffered colour RAM, albeit with half the vertical resolution.. Better than nothing though.. Not sure it was ever used in a game, but it is very viable to do and only requires a few (13 or 12) timer interrupts down the screen to work the magic, and when it comes to games scrolling the colour ram gives you lot of leeway that you otherwise don't get when having to blit the colour RAM in as fast as possible..

'Fox game' (nothing to do with your Fox ) has 3 levels of full screen parallax going on Very work in progress though, and there's the source code as well if you're a curiously inclined kind of person

It's a huge shame for sure.. As for the D64 ? No idea.. I assume you're running it on Vice ? Try enabling True Drive Emulation, if I recall it needed that..

It all depends on what "coding in C" means. Obviously the 7800 doesn't have I/O which would fit stdio.h, so that's kinda out. The C compiler would also have to do the following (off the top of my head): 1. Provide a peek & poke to modify the TIA, MARIA and RIOT registers. (Although I guess this could be done with pointers.) 2. Handle the 7800 memory map (zero page $40-$FF, RAM space, ROM space) 3. Put code & data on the correct ROM addresses (for holey DMA) But it's certainly possible to use C to develop for the 7800. Much of 7800 code is basically data movement. And it's certainly possible to describe the Display List as a C structure. Of course, it's tough to match the space & speed of hand coded assembly. Handling the hardware registers and regions of specific memory are simple and elegant in C, I think For example.. #define SWCHA(*(volatile unsigned char*)0x0280) unsigned char val = SWCHA; As for memory areas, same thing: unsigned char* zeropage = (unsigned short*)0x0000; unsigned char* stack = (unsigned short*)0x0100; unsigned char* ram = (unsigned short*)0x1800; And as for specific addresses for ROM and stuff, surely that'd be something that would be something you'd handle at link time with stuff being put into specific segments ? Though I'm sure this kind of stuff is already out there for the 7800

There is no reason..

José, Cave Wizard (which was in that video) is also all in 100% Hires as well and is one of the best looking things ever I think.. I just wish the guy had carried on with it, and also been a bit more adventurous with the multiplexer for more on screen objects.. My personal favourite is Touchlight which I think has some of the nicest backgrounds in a c64 shooter, plus I've always wanted to steal their non-background backgrounds and try doing some parallax using those style patterns but with a software interleaved every other line blending of a sparse further back slower layer Just one of the ideas that sprung into my on seeing that first time.. Personally I thought you'd have been wetting your pants over Armalyte 2

I bet I don't

I'll give that a go this evening when I've more time to sit and look at the results with some concentration instead of the brief looks i'm giving it now in between builds Would be nice if there was some magical solution to it, but I fear it's not to be, and with it my dreams of a lovely looking widescreen experience.. Or horror of horrors, 40 column mode

I've already got caught out by the changing DMA that HSCROL brings with it, and observing my DLIs slipping left as HSCROL increases, and decided to limit it to only using 2 bits of scroll since that saves me having to patch up the DLIs with preceding delays based upon the HSCROLL values to get a fixed position for register changes.. Time for some value by value analysis of what's going on then and what appears where on each value.. Though I guess it's be 11xx range then I'm not too fussed about it 'really'.. It's already got the problem that the last character on the line doesn't cleanly scroll off anyway, just disappears after a few shifts, but the noise just irritates me enormously.. Though I'm still curious of the source.. In my current tests it's constant all the way down the screen and doesn't change on a scanline basis, even though the CPU is active and only the first scanline pattern is different.. It doesn't seem to be related to any of the screen fetches, data on the cpu bus.. Another read of that decapping thread I think Screen position calculations aren't an issue for this, it's all flexible enough to not care..

That rings a bell now you mention the decapping thread! Cheers.. Trying to search for this issue on here was keyword hell.. It's precisely for the widescreen TVs that I'd like to fix this somehow, if at all possible because it seems a waste to not have nice wide playfields Even though I seemingly throw cycles away like they're confetti with scrolling thrown in as well

What exactly is this graphics data being generated ? And is there anyway to kill it ? I thought maybe it was just displaying what was left on the data bus, but it's constant down the screen so that would appear to rule that out.. The only other thing that seems to make sense would be that it's the DisplayList data being displayed ? Have I gone mad this morning ?

And another 130XE comes to join the fold

lol, I love the idea of a 'patch' for SMB that turns it from a NES cart into an A8 cart

Hence me wanting to find out how fast I can blit to the screen taking into account each lines different positions

Would be almost worth having the XM have a small FIFO to drive the YM chip with to allow rapid stuffing of registers.. I looked into using the CBM Sound Expander to add support for that to something, and the only big downer was these same delays needed between writes which was massively off putting to say the least.. Also worth remembering that the Sharp X68000 (and some MSX carts) used the YM2151 and some of the music on that is really really really impressive There's a whole gamut of Adlib/FM trackers out there in chip music land, and I'm sure one of them would be easily suited to supporting the YM2151, not that any of them do at the moment to my knowledge.. And even if someone decided to write one, AdlibTracker itself wouldn't be a bad starting point for what to aim for.. As an aside, there's many people out there looking for tools to compose for the YM2151 outside of XM land, so possibly 2 (or more) birds could be killed with one stone here..

GroovyBee or Curt Either of you want to explain the the 'scroll assist logic' is all about then ? I'm intrigued now to say the least..

Isn't that what it's all about ?

Aha, OK, but this will of course only work nicely when you don't make use of software sprites. But I assume you're talking in the graphics-mode context, whereas I'm more thinking in the font-mode context (which might have some benefits when integrating swsprites). Taking Heaven's comment into account: Only use background gfx for scrolling parts. Use PMs for the rest. I can see it working with only PMs, but then again I don't like the restrictions that come with that colour wise, and in a straight 1:1 conversion I think there's too many per line, but that's workable around.. But if I'm honest, I was actually finding myself thinking more of the lines along Darius Gaiden (which I think has some of the nicest parallax effect backgrounds) and by finding a good solution for sprites and things over this kind of background you'd crack that too

That's what I thought at first

In the words of Harry Hill "FIIIIIIIGGGGGGHHHHHHHT!". Sounds like a mini Format War contest to me . In the context of this game: When trying to port it to Atari 8bit I'd cheat my ass off and use precalculated multiple fonts. Many of the backgrounds are really simple gfx, so don't really need a scrolling-on-scanline-basis method. I simply wanted to take advantage of something the A8 can do very nicely..

I spent too long thinking about this, and the amount that has to be taken into consideration is horrendous.. I won't even list it all here because the list is endless of 'little' things that have to be taken care of.. Things like given the scaled size of a repeated section, and using fractional steps to everything isn't just integer scroll steps, means you need to find a nice multiple size to extend the line size too, and then there's the 4k crossings.. And with the line extension to ensure nice multiple sizes, you are using stacks of memory,, I did end up thinking that handling each scanline as an individual scrollable region, and blocks being the shape they appear on screen could work quite well, then you could have a nice block tileable parallax region that would look awesome, but it's a lot of code maintaining counters for every single scanline and dropping in data on each line as it needs it, especially the foreground lines that move at >1 pixel per frame.. And the sprite routine where each line has a different scroll position and line addess is unforgiving in terms of overhead of code for just masking out 3 bytes (or so) of data onto the screen.. I tried, but it's just awfully slow.. The main bummer being the selecting which of 4 shifts to use quickly and efficiently, although the mucking about with lines scroll position and sprites x position isn't insignificant either.. Anyway, I spent an evening thinking about the many different ways to implement the sprite drawing and the best I could come up with ~120 cycles for each 3 bytes masked and drawn onto the screen.. In a sensible, useful in a game, kind of way.. It would look stupendous and demonstrate beautifully one of the things the A8 does very well.. But that sprite routine fills me with dread, speed wise Edit: I don't want to sound negative, but want someone to say "don't be silly, it's really simple: like this...." because I would love to see this kind of thing