vidak

the random number generator routine from SpiceWare's /Collect/ should do it. I also think /Collect/ has a 2 digit score routine you can scavenge or change for your purposes

Okay I think I know why. The graphics are being loaded from the bottom of the table. The padding of 15 lines pushes the graphics data far enough down to make it ready to be loaded on the first scanline it is called. say we have a band which is 40 lines long. 40-2 = 38 (see below). The height of the temporary GRP1 graphics is 23. So 38-23 =15. The graphics need to be padded to the height of the band, and the last line of the 38 byte long table is the first byte always loaded. I am also not drawing GRP1 on the first two scanlines of every band up and down the screen. The reason why the colours are wrong still evades me. Screen band 0 is more or less correct, but none of the others are. That leads me to believe I've messed up the code which copies over the pointers from Band 0's pointers. GRP0's shape changes on the RIGHT side of the screen. Perhaps this is a kernel timing issue... this is what I mean when I talk about artefacts.

I want to put this update in just in case it helps... Padding the GRP1 graphics with 2 less bytes of data ended up showing the top two lines of the graphics properly... question to myself: why is the graphics only showing after 15 lines of $00 graphics? coloured_guerrilla026.asm

Moving the GRP1 graphics table labels to the top of the table, and deleting any adjustment numbers in setting up the pointers improves the situation. The problem is, I don't know why. There are 17 bytes of zeroes, yet everything but the top 2 lines of graphics data is displayed. Also the GRP1 colours remain unchanged from before. Interesting... coloured_guerrilla025.asm

Okay I improved the graphics for Che, but there are now artifacts. It was a bug in the Y positioning routine. I wrote ADC instead of SBC. There are now artifacts, however... coloured_guerrilla024.asm

Okay I've finished my first attempt at the pointers for GRP1. But I need some help - could someone assist in some debugging? The masking for GRP0 works, and the graphics pointers for GRP0 work. The colour pointer for GRP0 is wayyyy off, though. It's pointing way too far down, right into the temporary GRP1 colour data table. When I compiled the code the first time, both the colour and graphics pointers for GRP0 worked, but after I fiddled with the GRP1 labels, the colour pointer stopped working. Confusing. The second problem I have is that the graphics and colour pointers for GRP1 don't work at all. I am attempting to statically and manually fix all 5 bands of GRP1 to a single couple of tables... maybe the tables are crossing a page boundary? The two black bands that comprise most of the glitchy GRP1 graphics is the value $2C. I think the location being loaded is $ED10 - Stella debug reports this as CXP1FB. ANOTHER problem I'm having is that the vertical controls appear to be flipped. Pushing down moves Che upwards and vice versa. BUT: There are no more real artifacts as Che, GRP0 moves between bands. This is a huge improvement over the last kernel version. Anyway, as always, help is always greatly appreciated. Thanks in advance. PS. One weird thing I'm noticing is that the Stella debugger formats my graphics data differently every time I compile a new version of the binary. Sometimes it recognises the graphics data as graphics, and sometimes it doesn't... coloured_guerrilla023.asm guerrilla23.zip

OKAY. I have finished coding the pointers for the GRP0 main player character, Che. Almost all the code is lifted from Stay Frosty. Now what I need to do in order to get a full demo working is re-code the pointers for the repeated GRP1 graphics. Please find the attached source code. coloured_guerrilla022.asm

It's bootlicker.party

Hey. I do a lot of stuff. I do this: - Upload my thesis versions and write essays on my blog: bootlickers.party - Vlog on YouTube: www.YouTube.com/JollyCommunist - Run the Hip Hegelian Memes Facebook meme page: www.facebook.com/goodoldhiphegel - Develop Homebrew Communist Atari 2600 Games: http://atariage.com/forums/topic/269750-sierra-maestra-an-early-wip/ - Run an Educational Blog on Atari 2600 Programming: http://atariage.com/forums/blog/703-vidaks-blog/ - Run a Blog on Video Game Hardware and Aesthetics: https://jumpnshoot9000.wordpress.com - Full Time Unpaid Socialist Activist in Sydney, Australia - Full Time PhD student. - Write poetry: http://burninghotelsdown.tumblr.com/ I only get 27 000 AUD a year from my PhD scholarship, and I live in one of the most expensive cities in the world. This is less than the minimum wage for a full time worker in Australia, and is only twice the unemployment benefit. I applied for 200-300 jobs last year, and was only hired to push trolleys at a supermarket chain. It would take be 4 hours of travelling by public transport every day to do that job. This is the reality of modern life for future academics under neoliberalism. If you'd like to buy me a coffee, go ahead. If you can't say something nice, keep quiet. At the very least, just realise that I am not an exception as a PhD student, let alone a philosophy PhD student. http://ko-fi.com/hiphegelianvidak

Personally I'd just grab one of those HDMI to Composite converter from Alibaba! If I have read you rightly, you're just after something quick and cheap!

I too quite like RF - but there's no need for anyone to dictate someone's preference a

Very cool!

I was gonna say YES WE NEED A BETTER MOBILE WEB BROWSER VERSION OF THE FORUM ... but then I realised it wasn't the point of this topic

I can't see HMOVE anywhere in this code! I use the linux text editor called "Kate", and it seems to be showing some strange varying quality of indentation in your code. 1. Please fix the indentation in your code text so that it is uniform 2. I don't think you've initialised your constants properly. For instance here: YPos .byte What is the actual binary value Ypos is supposed to be holding? 3. You have not formatted your program labels properly. This is incorrect: Start sei ; disable interrupts Do either of these: .Start sei OR Start: sei That's all I have time for right now, I'll come back soon.

You should check out SpiceWare's Collect Tutorial HERE. The routine listed has a few variations - you can also fiddle with it. From my understanding, RESPX needs to be set at cycle 23. The way HMOVE works on the Atari 2600 is that it will automatically draw the Player Graphics at whatever horizontal location you set it. So after you do a HMOVE, and when you finally draw GRP0 or GRP1 at the right VERTICAL position, the 2600 will be waiting for you to STA GRP0 and will automatically draw GRP0 at the right horizontal position. It's a little bit like magic!

I'd be interested in doing a kind of 8bitworkshop.com style introduction to batari BASIC. Lots of people have mastered bB so I'm sure anyone can make sense of it.

This is my newest attempt at a complete kernel rewrite. It incorporates the masking technique and graphics padding that were suggested to me. It is now SO fast that I have 23 cycles left over. (76 - 53 = 23) I think I will incorporate playfield graphics! I wasn't even aiming to do so with this particular kernel! ;--------------------------------- ; ; KERNEL MACRO ; ;--------------------------------- MAC SCREEN_BANDS .BAND SET {1} ;================================= ; ; Load Line Counter for this band ; ;================================= ldy Heights+.BAND ;================================= ; ; Preload GRP0 (Che) Graphics ; ;================================= lda (Player0Ptr+.BAND*2),y ; 5 5 and (Player0Msk+.BAND*2),y ; 5 10 tax ; 2 12 lda (Player0Clr+.BAND*2),y ; 5 17 tay ; 2 19 ;================================= ; Position GRP1 independently for ; each band of the screen. ; ; Accumulator holds X value. ;================================= lda ObjectX+.BAND+1 .PositionGRP1 sec sta WSYNC ;----------------------------------------------------- ENTER FIRST SCANLINE stx GRP0 ; 3 3 sty COLUP0 ; 3 6 .DivideLoop1 sbc #15 ; 2 8 bcs .DivideLoop1 ; 2 10 eor #7 ; 2 12 asl ; 2 14 asl ; 2 16 asl ; 2 18 asl ; 2 20 sta RESP1 ; 2 23 <- set object position sta HMP1 ; 3 26 sta WSYNC ;------------------------------------------------------ ENTER SECOND SCANLINE sta HMOVE ; 3 3 ;================================= ; We haven't had time to preload ; any graphics, so now we have to ; rush and try and make sure we have ; something to draw on this line ;================================= ;================================= ; ; Load Scanline Counter Again ; and Decrement ; ;================================= ldy Heights+.SEC ; 3 6 dey ; 2 8 lda (Player0Ptr),y ; 5 13 and (Player0Msk),y ; 5 18 sta GRP0 ; 3 21 lda (Player0Clr),y ; 5 26 sta COLUP0 ; 3 29 <-- delayed. So we'll have to restrict ; Che's movement on the left of the ; screen? ;================================= ; ; Decrement Scanline Counter ; ;================================= dey ; 2 31 ;================================= ; Preload Che Graphics for THIRD ; scanline. ;================================= lda (Player0Ptr),y ; 5 36 and (Player0Msk),y ; 5 41 sta CheGfxTemp ; 3 44 lda (Player0Clr),y ; 5 49 sta COLUP0 ; 3 52 ;================================= ; ; Decrement Scanline Counter ; ;================================= dey ; 2 54 ; Prime the NUSIZ1 register with the right copies/sizing data lda EnvCopies+.BAND ; 3 57 sta NUSIZ1 ; 3 60 ;================================= ; ; Start of the actual kernel ; ;================================= .KernelLoop sta WSYNC ; 3 75/3 ;----------------------------------------------------- ENTER THIRD SCANLINE ;================================= ; ; Draw Che Graphics in time for left-most ; side of the screen. ; ;================================= lda CheGfxTemp ; 3 3 sta GRP0 ; 3 6 lda EnvGfxTemp ; 3 9 sta GRP1 ; 3 12 ;================================= ; ; Calculate Environment Graphics ; ;================================= lda (EnvGfxPtr+.BAND*2),y ; 5 17 sta EnvGfxTemp ; 3 20 lda (EnvClrPtr+.BAND*2),y ; 5 25 sta COLUP1 ; 3 28 ;================================= ; ; Calculate Che Graphics ; ;================================= lda (Player0Ptr+.BAND*2),y ; 5 33 and (Player0Msk+.BAND*2),y ; 5 38 sta CheGfxTemp ; 3 41 lda (Player0Clr*.BAND*2),y ; 5 46 sta COLUP0 ; 3 49 ;================================= ; ; Decrement line counter, and ; branch out if we're at zero. ; ;================================= dey ; 2 51 bne .KernelLoop ; 2 53 (3 17) What I still have left to do is: Set up the pointers for this kernel Pad the graphics and adjust the pointers so that the graphics appear at the right scanlines I think there's something else... I have attached the source, if you'd like to have a look. coloured_guerrilla021.asm

I absolutely loved The Last Jedi. I really, really enjoyed it.

I quit YouTube a year ago. The endless chasing of subscribers and the resulting mediocre content made me hate the place. I want to create a better video sharing platform...

That might actually help with the Sega Master System I had trouble with...

Oh you're totally right. I was like - are they pots? Are they MOSFETS? Woops!

Okay. This project is still alive. I am about to implement a new kernel - the bitwise AND masking kernel that SpiceWare used in Stay Frosty - which ZackAttack recommends. If you'd like to hear a radio interview I did about this project for a radio station in my home state of Western Australia, CLICK HERE.

I agree with this. I don't think there should be a minimum standard for which games to log down. I also agree that the categories should be objective and factual, and not normative or evaluative. I can put some time into data entry. Perhaps we should just ask everyone here to offer up some proposals on what the categories of specification should be? I also don't mind a pluralistic approach to categories. Like CoolCrab says, you can have overlapping and intersecting categories of any categorisation. Such an approach would make the wiki easy to interpret from multiple different perspectives.