IuriNery
-
Content Count
18 -
Joined
-
Last visited
Posts posted by IuriNery
-
-
Hi,
I'm using the z26 emulator for my software, but I've tested on both z26 & Stella, and they both reproduce the same thing.
I also tested in the original hardware using the Harmony cartridge, and the glitch happens on both situations (using sleep 6 and 7), but it seems like it's worst using the original value:
Using Sleep 7 (Original):
Using Sleep 6:
I'm also attaching the .BIN files below.
-
Hey RevEng, thanks for helping me out.
Good job on the TitleScreen kernel, looks awesome, but I assume it doesn't work for 4kb games because of rom space?
About the Score Kernel, I downloaded the latest one from the link you provided, and it seems to work, but the first digit has some glitch, please take a look:
I tried changing the digit from "LDA #$12" to "LDA #$22" to check if the problem is with the "1" sprite, but the same glitch happens. Do you know what could be the cause?
Thanks!
EDIT: Ok, I tried changing this line: "sleep 7" to "sleep 6" and it worked!
-
Hello everyone,
I'm making a software to build atari games, I already managed to make the players show in the screen with the help of some people on this other thread (http://atariage.com/forums/topic/291513-loop-through-table-every-x-lines/), and now I'm trying to implement a 6 digit kernel I found on the internet.
I've managed to show the score on the screen, but I'm not being able to change the numbers of the score.
I tried changing the "score" variable but no success. I also tried changing the "score+1" and "score+2", but when I load a value into it like: "LDA #8", I have to store this value on both pointers to be able to show a different number on the score, and the result is still wrong, it shows something like this: "080808" instead of "000008".
Here is the score kernel I found:
DrawScore lax score+0 jsr miniscorepointerset sty scorepointers+8 stx scorepointers+0 lax score+1 jsr miniscorepointerset sty scorepointers+4 stx scorepointers+6 lax score+2 jsr miniscorepointerset sty scorepointers+10 stx scorepointers+2 sta HMCLR tsx stx stack1 ldx #$B0 stx HMP0 ldx #0 sta WSYNC ; 0 STx GRP0 ; 3 STx GRP1 ; seems to be needed because of vdel ; 6 sleep 5 ; 13 lda #>ScoreGfx sta scorepointers+1 sta scorepointers+3 ; 22 sta scorepointers+5,x sta scorepointers+7,x sta scorepointers+9,x sta scorepointers+11,x ; 38 LDY #7 ; 41 sleep 2 STA RESP0 ; 44 STA RESP1 ; 47 LDA #$03 STA NUSIZ0 STA NUSIZ1 STA VDELP0 STA VDELP1 ;LDA #$20 LDA #$C0 STA HMP1 ; 68 hmovebreak LDA #SCORE_COLOR ; 71 sleep 3 STA HMOVE ; cycle 73 ? ifconst score_kernel_fade and score_kernel_fade endif STA COLUP0 STA COLUP1 lda (scorepointers),y sta GRP0 lda (scorepointers+,y sleep 54 ; sta WSYNC ; sleep 2 ; 2 jmp beginscoreloop ; 5 if ((<*)>$28) align 256 ; kludge that potentially wastes space! should be fixed! endif scoreloop2 lda (scorepointers),y ;+5 68 204 sta GRP0 ;+3 71 213 D1 -- -- -- ifconst pfscore lda.w pfscore1 sta PF1 else sleep 7 endif ; cycle 0 beginscoreloop lda (scorepointers+$,y ;+5 5 15 sta GRP1 ;+3 8 24 D1 D1 D2 -- lda (scorepointers+$6),y ;+5 13 39 sta GRP0 ;+3 16 48 D3 D1 D2 D2 lax (scorepointers+$2),y ;+5 29 87 txs lax (scorepointers+$4),y ;+5 36 108 sleep 3 ifconst pfscore lda pfscore2 sta PF1 else ifconst scorefade sta COLUP0 sta COLUP1 else sleep 6 endif endif lda (scorepointers+$A),y ;+5 21 63 stx GRP1 ;+3 44 132 D3 D3 D4 D2! tsx stx GRP0 ;+3 47 141 D5 D3! D4 D4 sta GRP1 ;+3 50 150 D5 D5 D6 D4! sty GRP0 ;+3 53 159 D4* D5! D6 D6 dey bpl scoreloop2 ;+2 60 180 scoreloop2end ; 53 ;echo "critical size: ",(scoreloop2end-scoreloop2) ldx stack1 txs LDA #0 sta PF1 STA GRP0 STA GRP1 STA VDELP0 STA VDELP1 STA NUSIZ0 STA NUSIZ1 ; clear out the score pointers in case they're stolen DPC variables... ldx #11 clearscoreploop sta scorepointers,x dex bpl clearscoreploop ;;ldy temp3 ; ldy scorepointers+8 ; sty scorepointers+3 ;;ldy temp5 ; ldy scorepointers+10 ; sty scorepointers+5 rts miniscorepointerset and #$0F asl asl asl adc #<ScoreGfx tay txa and #$F0 lsr adc #<ScoreGfx tax rtsI'm also going to attach the SOURCE and BIN files for the project if someone wants to take a look.
If someone can help me showing where is the problem I would appreciate that.
-
Thanks JeremiahK, I will take a look into your code to see if it works.
I'm also going to take a look into the CollectMini on your tutorial SpiceWare, I think it has some stuff that I can learn from that, and it's less advanced then the actual tutorial itself, so it may be easier for me.
Thanks!
-
That's similar to what I do in Collect. I use Y to control the loop, and a RAM value called ArenaIndex that's loaded into X when it's time to draw the playfield.
The problem is that I'm using Y for the PF Color, maybe I should make use of some variables...
If I understand correctly reading the tutorials, the Player sprites should be draw at the same time as the Playfields/Background? So that way you can control the X/Y position of the sprite, right?
So, this is actually impossible to do?
JSR Kernel (draw the PF etc.)
JSR DrawSprites (draw the player)
-
Hi,
Yes, I'm actually studying your tutorial, very good, I'm trying to get the player sprite show in the Playfield, but it's a little complicated, I don't think it's possible using this Kernel that I'm using without some heavy modifications I guess.
I tried your code, like this:
But this is the result:
My guess is that the program is trying to access values from the table that are not there?
(The tables have only 48 values).
What I want is to draw the PF in a #96 loop, but using tables that have 48 values, is this even possible? Maybe using a variable to store the kernel loops?
-
Hello everyone,
I'm working on a project and I have a few questions:
First, take a look into this code:
; Kernel
; ------Kernel STA WSYNC LDA INTIM BNE Kernel ; Turn ON Display STA VBLANK LDX #48KernelLoop ; Preload Colors LDA Screen_1_BKColor-1,X LDY Screen_1_PFColor-1,X ; BK/PF Colors STA WSYNC STA COLUBK STY COLUPF ; Draw Playfield LDA Screen_1_PF0-1,X STA PF0 LDA Screen_1_PF1-1,X STA PF1 LDA Screen_1_PF2-1,X STA PF2 ; Skip Lines STA WSYNC STA WSYNC STA WSYNC DEX BNE KernelLoop RTS
As you can see, I'm loading X with #48, because the shape & color tables have 48 values each, this is the result:
Now to the questions:
1. If I use #96 instead of #48, how do I update the Playfield only every 2 values? (What I'm trying to ask here is how do I modify the #48 and use #96 but still get the same results? So I can draw sprites using the #96 loop).
2. Is it still possible to draw sprites (Player/Ball) using that amount of resources in the Kernel? (Updating the PF & BK like in the code above).
Thank you.
-
Hi,
Is there a way to use this code outside batari basic? What if I want to add a 6 digit score in my game?
Thanks and sorry for ressurecting this thread.
-
I think you are waiting too many cycles to write to the registers after WSYNC. You only have 22ish cycles of Hblank .
try moving the writes to COLUxx right after WSYNC and before writes to PFx . Still not perfect but it is better.
I moved COLUPF & COLUBK as you said, it's better indeed. There are only 2 small issues now:
I think you might also be writing to PF after HBLANK and need to preload graphics for next line.Can you please elaborate on that?
Work your way through the Collect tutorial. This particular issue is known as shearing, and is covered in Step 4 - 2 Line Kernel.
I will take a look, thanks!
Interesting, so this is a common thing that happens with Atari games that has lots of colors, gradients etc.?
EDIT: is there a way to set the COLUPF and COLUBK for all the lines once? (outside the game main loop)
-
Hello everyone, I'm trying to create a playfield with different colors, but something weird is happening. Some of the lines of PF/BK are not aligned properly.
Here is the Screenshot:
Here is the assembly code:
If I set COLUPF or COLUBK on the main loop, it seems that it messes with some of the lines, but if I set a single color for both COLUPF and COLUBK before the StartOfFrame, everything seems to work fine.
I don't know what I'm doing wrong here, if someone could help me I would be really glad. Thank for your time.
-
Hi again,
I've added the possibility to paint the lines with different colors, added a button to change the way the Playfield is drawn and I've also added a shortcut to use a Color Picker.
Here are the results:
1. Screenshot
2. Code
3. Binary
There is still something weird happening to the playfield though, if you run the binary file you will see that there are some lines on the left of the screen that doesn't have the correct size or is at the wrong position (I don't know what is causing it yet).
I love this project, but Nukey is right about the limitations of the Atari 2600.
I agree that probably the best way forward for this project would be to have some set made kernels which beginners and drag and drop some limited customisation onto.
Like you could have a Tank game, a Defender-like game, a Jungle Hunt game...
I guess I'm also a lot stricter about how I like people to approach computers. I personally would like people to develop their computer literacy. I suppose this would be like a "gateway drug" for that.
I think you should teach beginners about branching, indexing graphics in ROM, about variables, about loops and conditional statements... The beginner should probably also eventually come to learn about what makes the 2600 so unique (racing the beam).
Like Chairman Mao said, "let a thousand flowers bloom' - in other words, we should always encourage people to finish their projects and let many diverse plans be set.
I suppose I am a very smart person, but I don't see 2600 kernel writing as terribly difficult - really you're just writing to hardwired registers on a timer.
I'm here if you want some help!
Thanks!
Yeah, I will have to study a lot to optimize the code, and having different game templates may be the way to go.
My IDE will have 2 options for the programmer to choose (Drag & Drop and Assembly), the Assembly is just a text editor with syntax hilighting, the Drag & Drop will feature more tools and will be much easier for the developer to add stuff into the game.
What I want to do is to add different pre-defined movements and actions so the programmer can choose which to use for each object. For example: if the programmer wanted to move the "Hero" around the playfield in 8 directions, the only thing he/she would need to do is to add a "8 Direction Movement" into that object, and adjust it's speed accordingly.
Great project, looking forward to seeing this develop!
bB still requires a lot of programming knowledge, would be cool to see more game maker programs where coding is optional, imo the limitations of the 2600, don't cross over to the mainframe running the IDE.
Checkout the links in my signature for some related ideas - Flashback BASIC and SuperCharger BASIC support programming visuals and sound without any code required, as well as high level BASIC and also an old school BASIC mode like bitd.
Thanks!
Cool, I will take a look into your project, looks pretty good from what I've seen.
If anyone wants to take a look and test the IDE, this is what I've got so far:
https://www.dropbox.com/s/z3jcqebknju0k2r/AtariX.zip?dl=0
To use the Color Picker, just hold the "LEFT CONTROL" and click on the desired color on the playfield.
-
Hi again,
I have fixed the problem with the Top/Bottom edges of the screen by adding COLUPF & COLUBK to the Vertical Blank/Overscan.
I've also added the suggestion made by Nukey Shay.
Here is the generated assembly file:
The approach used by NESmaker is to provide a number of complete game engines for various game genres, that users can customize via the supplied tools. A lot of non-coders appear to be into that kind of thing, judging by the success of the Kickstarter campaign!Exactly! I have a lot of friends who would like to start making games for Atari but are too scared of Assembly.
-
Creating something as complex as a game without any programming experience is going to be pretty much impossible on the 2600. Ultimately, you would be substituting one language (low-level assembly) for another (high-level Basic or something similar). bBasic is currently the go-to method there.
Since you are just plugging values into the PF registers line-by-line, there is no need to use such a large kernel to do it. You could cut this down by using an indexed loop.
LDX #192 Loop: STA WYSNC LDA PF0data-1,X STA PF0 LDA PF1data-1,X STA PF1 LDA PF2data-1,X STA PF2 DEX BNE Loop
...then include 3 192-byte data tables for the values. Also, delay timing is going to be needed if you include an asymmetrical option (i.e differing PF values for the left and right halves of the screen).
But there is really no need to reinvent the wheel. The TIA Playfield Painter already covers this.
Not sure what you are trying to indicate with the arrows...when the PF colors appear and are removed on the screen? Relocating your VBLANK calls would be that solution.
Hi,
What I mean by creating a game without any programming experience is that the user will be able to add stuff to modify a default game template as they wish, my goal is to create something to prototype and introduce beginners into atari development.
Thanks for your suggestion about the indexed loop, is there a real difference on the final binary file using this method? Or is it only for making the code more compact?
I haven't heard about TIA Playfield Painter before, I would love to test it but it seems it's only available on DOS. Just to be clear, my IDE will be more than a playfield painter, the user will be able to add objets, manage actions and so on.
About the arrows, it seems that there are extra pixels on top/bottom of the screen whenever I test , I was asking if there was a way to remove/clear those pixels or if it's a normal behavior that happens when you play on an emulator.
Thanks for taking your time to answer my questions.
-
Hello everyone,
I'm a beginner on Atari programming and I'm creating an IDE to allow people to create Atari games without having to write a single line of code. I'm learning Assembly as I go through the IDE and add more stuff, it's helping me a lot.
This is what I've got so far:
A simple IDE that lets you draw the playfield and change the color of both playfield (COLUPF) and background (COLUBK).
If you hit the "Play" button, it will produce the following result on an emulator:
This also generates an assembly code file, please take a look at this file to help me with the questions:
So, considering I've read a few articles about programming, I've come to a conclusion that every single line of code matters when you're programming for Atari. So I would like to ask a few questions:
1. Looking at the file (atarix_result.asm), is the generated code bad? What optimizations should I look forward? How can I optimize this code?
2. What kind of things should I avoid when drawing to the playfield?
3. Also, is there a way to get rid of the parts showed on the second screenshot? (Where the arrows point at). Or is this an expected behavior?
Thanks!
-
1
-
-
Very cool game.
I've manged to beat the Bread Cat, but I can't pass through the ghosts
The Carrot King???
-
1
-
-
Looks good!
How are you displaying your binary numbers? I'm using jEdit and have it configured so binary numbers display in such a way that the graphic data is very obvious (see below).
I've written a tutorial that takes you through writing a 2K game. You may find it useful as well.
Thanks!
I haven't heard about jEdit before, seems like a very good program with lots of features, I will definitely check it out!
The binary numbers on AtariX are displayed in a very simple way:
I haven't though too much deep about it (because I'm still learning and I don't know what ".byte" means haha). But the idea of highlighting the 1's is something I will definitely add, as you said, it helps a lot visualizing the data.
I also fav your tutorials, I will read it after I finish Andrew's tutorials.
Thanks for the suggestion =)
-
1
-
-
AtariX
Hello everyone, my name is Iuri Nery, and a few days ago I started reading some tutorials at RandomTerrain to learn more about Atari programming, and so far I’m finding everything fascinating. I’m right now at number #16 of Andrew Davie’s tutorial (Atari 2600 Programming for Newbies). I’m learning a lot from it, and to learn faster, I needed to built something to help me testing the sample projects, that’s why I made this IDE.
AtariX is a very simple IDE, but has a couple of features that can help novice users to get into Assembly programming:
· Save/Load assembly files (.asm/.s);
· Build binary files by pressing the “Export” button;
· Test your games with 1 click;
· Colored syntax for comments, assembly instructions, numbers, binary numbers and also for the labels from “vcs.h” (like COLUPF);
Files included:
· “vcs.h” and “macro.h” (unmodified);
· DASM Assembler;
· z26 Emulator;
· AtariX executable;
How to use:
1. Open the assembly file you want to test;
2. Put all the included files in the “include” folder;
3. Click on the “Play” button (you can also press F5);
Credits:
; AtariX ; ------ ; Copyright © 2017 by Iuri Nery ; DASM Assembler ; -------------- ; Copyright © 1988-2002 by Matthew Dillon ; Copyright © 1995 by Olaf "Rhialto" Seibert ; Copyright © 2003-2008 by Andrew Davie ; Copyright © 2008 by Peter H. Froehlich ; z26 Emulator ; ------------ ; Copyright © 1997-2004 by John Saeger
.
This is not an advanced IDE or anything like that, just wanted to share it with you guys, I hope it can help someone.
ps: I’m not an experienced programmer, so any tips are apreciated, also I don’t know if this is the correct session to post this kind of stuff.
Thanks!
-
5
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
AtariX - Work In Progress #1
in Homebrew Discussion
Posted
Hello everyone,
Today I've released the first Work in Progress video for the AtariX IDE I've been working on.
The video showcases some of the tools in the IDE, like the Playfield Editor and the Object Editor, also the HUD which allows you to pick a font and a color for the 6 Digit Score.
Next thing I'm going to work on is the LOGIC part of the Object Editor, which will allow developers to add properties to the object (like collisions, input etc) without having to write a single line of code.
The main goal of AtariX is to help newbies to get into Atari game development and also for advanced users to build some prototypes, so you can export the Assembly code and add more advanced stuff into your game.
If you have any thoughs or ideas, please let me know.