andym00

Too late

In wide mode I'm finding myself excessively short of cycles for some reason.. I mean way shorter than I would expect to be, so maybe it's time to roll out this tron contraption then Actually now I think about it, it's not so bad to split the sprites horizontally I guess.. If you prepared single line kernels ahead that just did lda #(max_delay-desired_delay) lsr sta .br +1 .br bcc * nop nop nop (nops for max_delay - 3 cycles) lda #xpos sta HPOS0n lda #colour sta COLPMn lda #gfx sta GRAFPn That'd give you a nice simple point to write the delay and data, and it's not a huge chunk of code, then you can prepare one for each line without much cost.. Chain them automagically for the full height of the screen, and break the chain when you need.. Yeah, there's 11 cycles or so overhead at the start.. Hmmm.. Though they'd be faster in the NMIs since you don't seem to have to ACK them like the timer IRQs which is painfully slow with lda/sta/lda sta for each one.. But I guess you want the NMIs for DLI faffing ? You can shift the tick point of 15Khz timer over into the centre of the screen (well anywhere along the line infact)[1], well probably earlier to allow interrupt entry and other shenanigans dead easily, except it doesn't work in Atari800WinPlus.. Just Set lower 3 bit of SKCTL to 0, hit STIMER, the SKCTL to 3 so you could very easily align you interrupts once per frame to the split point you want.. Maybe it'd actually be more manageable with interrupts in reality [1] Though there's some issues with IRQs occuring at the same time as DLIs and the IRQ being ignored (or was it the other way around?) Pretty sure it was IRQs.. Check the thread about this in this sub-forum for all of it.. I can't remember the ins and outs exactly, but you should read it if you're even thinking about that I guess

You're a braver man than me on this subject then if you want to try it That's a subject I don't even want to consider right now.. I just can't see how you'd feasibly work the logic into the multiplexer, and woe betide you if there's any DLIs floating around as that'll basically make parts of the screen inaccessible to your horizontal splitter, or at the very best lines will vanish from sprites in those regions.. How would you do it ? Prepare a jump table for each line of the screen where there's multiple horizontal splits, jump in, set HPOS0, then do a variable cycle jump ? But you're then at the mercy of the NMIs killing you if that have happened, or do happen in your fancy horizontal code.. Maybe you an old C64 trick might help If you can set the joystick port data direction to out, and hit the fire button line, and trigger the light-pen button, you can read back your horizontal line position from the light pen register, which might make the loop a bit simpler, at least more stable, and some chance of recovering sensibly from an IRQ murdering you, or even from interrupt jitter.. But I don't know how often you can hit do the lightpen conversion on an A8.. Maybe there's other resources the A8 can use to figure out the horizontal scanline position.. Just a thought

And you'd probably spend more cycles checking if it was the same then just setting the damn thing

lol, no chance I've had enough trouble re-using sprites in hand coded stuff trying to make a big full width single colour overlay using players so I can have a nice classic score, lives, hiscore panel overlaid over the background across the full width, and I feel like I'm back in 2600 land already Anyway, I'm not convinced that this whole flickering more than 4/5 per line will be of any use when using them as underlays on software sprites.. It'll look so unbelievably crap if the colours underlaying sprites are flickering on and off, and not the software part, though I guess you could switch the software one on and off as well for proper authentic flicker-vision

More than 4 per line isn't any more work as I said before.. I'll try to be more clear this time In the sort use a 9bit key.. The bottom bit is the last displayed flag.. If the sprite can be added to the irq chain (ie: if ypos > players_end) eor the displayed flag and add into the irq chain, else discard it.. Next time around.. The non-displayed sprites will shuffle towards a higher position in the sort, and have a naturally higher priority than the one drawn last frame.. So assume 4 sprite on the same line, the number is just displayed flag.. S0 = 0 S1 = 0 S2 = 0 S3= 0 As we parse the list, we add S0 then eor display flag, add S1 eor display flag, then S2 S3 fail and don't get added.. Now, next frame, we have the bottom bits of the YPOS/SortKey looks like : S0 = 1 S1 = 1 S2 = S3 = 0 And then, after we sort, the order will be S2,S3,S0,S1 And this time it'll display display S2,S3, and their display flags gets eor'd, and S0, S1 will get rejected *unless* the player it wants is free.. So, next frame, we have: S0 = 1 S1 =1 S2 = 1 S3 = 1 And the next sort they fall back into their natural sorted order because they're equal.. And we begin the whole cycle again.. And you can do this for as many sprites as you want.. If you want 32 on one line it just works.. It's no extra work whatsoever, well apart from having a 9bit sort, which is best with a 2 pass Radix sort.. a 5bit first pass, then a 4 bit second pass would be best for 48 or so, but with larger numbers a 6bit + 3 bit or even an 8bit + 1bit would be better if you're up to 128+.. The only extra work you do is compare the sprites Y position against the end line of the player you're about to use, if it fails discard the sprite for this frame, if it passes eor its display flag.. Okay, so there's a little extra work to insert the display bit flag into the sort key, but its like 4 or 6 cycles extra work..

I've found a few hours to do some dabbling, a little update on this sprite business, probably mainly for Heaven I've bumped it up to 48 sprites now, and copying is in, yeah, I know not very adventurous I know It's not double buffered, but you'd never know anyway.. It still doesn't use the 5th player, since I'd always assumed that when you set the 5th player bit that the hardware would take care of positioning the 4 missiles together for you, but now I realise that in fact all it does is make the missiles use PF3, which is handy in a way, but the loading cost of the 5th player is scary, like 24 cycles or so!! But I'll add it since I think having one more player will ease the load on the plexer quite a lot.. To be honest I'm amazed what you can get away with with only 4 sprites.. I'm seriously losing my patience with Atari800WinPlus and trying to hold onto some solid timing reality Anyway, worst case on the real-hardware is that it's all one line out, I think.. Actually, worst case is it (probably) doesn't work at all.. Can anyone tell me for certain on which line players are started to be drawn relative to the screen ? I assume there's some line they start to load from, but what line is it exactly ? And is there a reason there's the empty 1K of memory at the bottom of PMBASE ? And one more question, what's the maximum screen height I can safely go to on PAL machines ? Is there some common values in A8 land ? There's 2 versions, one with colours on the interrupts for curiosities sake.. And there's nothing handling more than 4 sprites cleverly yet, so the mess at the top and bottom is inevitable when they all pile up there.. Anyway, back to this miserable 5th player contraption.. playertest.zip

edit: stupid stupid post editor.. playertest.zip

Aha, that'll make for the perfect way to understand it now I good hunt for that will be in order this afternoon then..

He is agreeing I think, just there's two ways to do it, top of the the screen or bottom of the screen The jist of it is this.. Set an interrupt on line $2F and disable the screen.. $D011:[4] = 0 Interrupt again on or after $31 (up to $33) enable the screen.. $D011:[4] =1 The top and bottom borders will vanish as well, and there'll be no screen DMA, only sprite DMA (if they're enabled), and the only displayed screen data (apart from sprites) will be the idle byte from VIC which is located at the top byte of the VIC bank.. It's one byte that VIC fetches when idle and repeatedly displays it.. You can fiddle with this to do some funky effects on the screen.. The only way badlines can occur is simply if the display enable bit is set for at least one cycle on line $30.. Stop that occuring, but enable the screen again before it's started to be drawn and voila, the magical 'HyperScreen' as it's called.. It's the easiest way by miles for a display with no badlines, if you can live with sprites only..

I was wondering how you were doing that, whether you had it in a fixed chunk of memory and were manually patching it, or hacking the binary image directly or working with a dissasembly.. I'd never have guessed you were doing it like that, but that's a damn nice way of doing it

Right, I'm with you now.. I had no idea the loader worked like that, and certainly that it could handle multiple chunks like that.. That's very nice indeed.. In CBM land it's nice and caveman-like Umm, I could knock up a macro to do it, but an ORG is just an ORG in my world.. I wouldn't want the assembler doing anything else than setting the PC for me.. That's one thing that's impressed me about the A8s as well is how much more like a proper OS you've got, not that it really mattered on the C64, and in someways the A8s feel a bit over-engineered in that aspect, but I guess with your better basic and exposure of the hardware to basic that it was kind of required..

This MVP, I get it from looking at the pictures and it's fairly straight forward, but then I read the textual explanation and I'm totally lost by what addresses are supposed to where on what lines.. I can see how to implement it, but it feels like I'm missing something compared to how he describes it.. One day I will sit down and understand exactly what he means in his explanation and implement the bugger

What do you mean by the loader doesn't put it into memory ? Have I missed something obvious about the xex formats then ? Do you mean the loader only parses the first 6 bytes of the header when it loads it ? edit: What I mean is does it read the 6 bytes, then reads programend-programstart bytes into memory at address programstart, then reads the last 6 bytes (whatever the 1st 4 voodoo byte are) then jumps to the start address ? I'll put the code out for the sprite stuff when it's all doing what I want, it's a total mess from experimenting with different things, and I want to get the thing running like it should do.. But I posted the guts of the timer stuff earlier in this thread edit: Basically all it does is: @VBL: It sets an interrupt to just above the top of the visible screen line, something like 8 lines or so.. lda #86 sta AUDF4 sta WSYNC lda #1 sta STIMER In the timer interrupt (8 lines above the top of the screen) lda POT0 lda POT1 lda POT2 lda POT3 lda POT4 lda POT5 lda POT6 lda POT7 sta POTGO sta WSYNC jsr plex_display We load the 1st 4 players up in the hardware.. And set the time to the first interrupt, which will be the bottom line of sprite 0.. ; Start the irq chain.. mux_l0 = *+1 lda #$00 beq .skip sec sbc POT7 sbc #1 sta AUDF4 sta STIMER And points to the first interrupt in the irq chain.. And then at the end of the useage of a hardware player, it then sets the player up for the next sprite, no matter how many lines away it actually is used.. So.. So from now on we're just falling through a preset irq chain.. .l = * +1 lda #0 cmp POT7 bcc .next beq .next sbc POT7 sbc #1 sta AUDF4 sta STIMER lda #0 sta IRQEN lda #4 sta IRQEN lda #<.next_irq sta $fffe And there's a seperate chunk of interrupt code for each sprite, with the last ones setting an interrupt up to give me a stable interrupt at the bottom of the visible screen to start doing stuff, rather than waiting for the VBL.. In fact any irq will exit to the last interrupt if it gets a y-position of 0..

I do like that and the ability to do LMS on every line and have the screen layed out however you want.. I still don't get what Emkay and TMR are squabbling about with LMS in that other thread though.. More to read up I guess I'm still trying to get my head around the fancy scroll technique (MCP/MWP or something like that), but then there's still much to learn about this little beasty.. I do like it a lot though, but I find triggering interrupts (that are dynamic in anyway) to be a royal pain in the butt, especially when you're doing an LMS on every line..

* = $2000 !byte $ff,$ff !word program_start !word program_end Simply because I didn't know what your memory map looked like (where basic memory starts and so on, or even how you handle loading), so just took a guess with $2000 being suitably free on the very first program I wrote And it's just stayed like that as I've been experimenting

That's interesting.. I didn't realise that was the case from the reading I did, that P4 will stay above the playfield in that case.. I think I should start thinking more about underlaying the playfield then since now it's been pointed out it does make a lot more sense, and it'll work much better with a mutliplexer taking care of the horizontal expansions as well It's just a concept I found unusual at first, but now can really start to see the benefits of it..

I think after years of having chuffing big borders and having to do dec $d016/inc $d016 at cycle 56 I'm so going to enjoy not having side-borders the size of Russia on the screen, so wide screen mode all the way for me

That's pretty damn cool actually Hmmm, time to play around with this stuff then

Just a bit of a brain dump that I need to get out before I forget it all.. Players & PRIOR modes, and how to achieve colourful playfields has been bugging me for a few days now.. Hell I even dreamt about P0/P1 and P2/P3 playfield combinations last night Okay, thinking about graphics options for rendering a game with lots of sprite, and trying to keep things as colourful as possible.. For the kind of scenario I'm thinking I'm imagining some horizontal based game, using soft sprites with players on top (either simple overlays or OR'd contraptions), and also using players on top of static (actually animated) background imagery.. The idea is that a general purpose multiplexer manages players and colours, and horizontal sizes, so that normal sized players can be used for overlaying software sprites.. Using PRIOR OR'd 'voodoo'.. Means we really have to use the 5 colour background character mode, so limits us to character modes, and no bitmap modes, otherwise with only 4 colour P2/P3 will only have access to one colour, though this would be manageable I imagine, so include bitmap modes back in.. It doesn't feel so useable since it means we have to ensure a certain player is allocated into either P0/P1 or P2/P3 which although manageable easily from the multiplexers point of, and doing so would mean that variable height sprites would naturally fall out of the system, I'm not entirely convinced that it's practical due to the constraints it brings with it.. It just feels far too limiting in terms of being able to easily manage a screen without things falling to pieces should a sprite fail to allocate the the P0/P1 or P2/P3 slots they absolutely need.. For example we've got 2 sprites on a line that need to be in P0/P1 and a 3rd joins the club, we're a bit screwed.. P2/P3 might be free, but they're no help in this mode.. From a fairly general point of view I don't see this being so practical in a game with a fair amount of freedom for objects to move.. Plus the Missiles don't seem to be fantastically useful in this mode if using 5 colour mode.. Using 4 colour background and limit used bitpatterns and palette.. Use 4 colour background mode and only use bitpatterns 00,01,10 with 11 being set to the same colour as 01, and 10 not being combinable with players.. This means don't have to worry about which Player a sprite gets allocated.. It can go into P0/P1 or P2/P3 and it makes no graphical difference.. It means we have 3 colour backgrounds, but each player can add 2 additional colours to the underlaid graphics (be that software sprite or static background imagery).. Missiles do become useful here in this mode, but only in the context of single colour objects.. No OR'd mode.. And just 4 or 5 colour backgrounds with overlays and then use use a Player as a simple overlay, adding only 1 colour.. If combined with 5 colour character mode, this isn't far off what the 64 is typically managing, in that PF3 would be like SPRMC0, and we'd just be one common multicolour short on each sprite.. Missiles are useful here in 4 colour modes since that's essentially a fifth player for the system.. The other downside to the OR'd mode is that is makes using colours splits down the screen for the screen harder to work with.. I like the OR'd mode a lot, just it feels very difficult to use well in a general purpose scenario especially given the different P0/P1 P2/P3 combinations, I mean P0/P1 with PF0/PF1 and P2/P3 with PF2/3.. But maybe I'm missing some magical point of clarity ? Unless I'm mistaken, the 5 colour modes makes software sprites a wee bit hellish to do ? (edit: It just occured to me, that it wouldn't be any harder than managing the OR'd mode sprites anyway when it comes to restricting how stuff overlaps, so maybe scratch the comment).. My brain is exploding thinking about the various possibilities, and I'm curious if anyone has any thoughts on the subject, and if there's other real-world possiblities that haven't entered my mind yet ?? Or maybe I've completely misunderstood the above graphics possibilities ?? But keeping it real please, not heading off into G2F land Anyway, off to collect my 130XE and possibly an unopened/sealed 800XL as well

Aha, the missiles.. Okay

Atari takes all the fun out of those kind of things Though not having (mostly) R/W hardware registers more makes up for it I never really understood why there was all of this shadowing of the hardware registers until I thought, 'I know I want to just switch the player DMA off on this line'.. Big oops On A8, what is the standard solution for blanking players out at screen horizontal edges ? Is it just to use wide mode and hope that nobody has a tv large enough to see ?

But unless I run with timer values of 0, once I enter the timer interrupt, the timer has already reset itself to it's AUDFx value and begun counting again ? No ? So me reseting it to a known value won't take effect until the *current* timer period has elapsed, which means you have to stick the correct AUDFx value in one interrupt ahead of where it's actually needed.. That's the impression I got from reading the docs and running on Altirra ? It only reloads from AUDFx when it underflows ? Which means that an interrupt can't instantly change the timer value, until the current period has elapsed.. Unless you hit STIMER.. It sounds like what you're saying is that once the Timer underflows and generates an interrupt the internal counter isn't reloaded until the next 15Khz tick, during which time I can reload it without needing to write to STIMER ? Which isn't the behaviour I saw in Altirra.. But I guess I can't take anything for granted until I get running on real hardware..

Error 404 It moved here some time back.. Look unders "Rants" at the bottom.. http://cadaver.homeftp.net/

I'll being driving to Bratislava tomorrow morning to pick up a dirt cheap 130XE (and it's the perfect excuse to hit the Tesco there as well ), but I've still got to get off my arse and sort out some PC connection gizmo as well Anyway.. I'd be curious if this even works on a real A8.. It looks bizarre because it doesn't load the player graphics yet into the correct positions, it's just been a little experiment in learning the A8 and of doing raster splits with timers.. It won't work on Altirra because the Pots don't seemingly work, and also because it doesn't support some illegal opcodes.. Atari800WinPlus will be okay, but the timers are all out by a line or so.. sprites.zip