Yoruk

Ok thanks ! Yes I was wondering if it was better to ask here or directly in the tutorial page, I'll do that.

I am digging into the tutorial of SpiceWar. I love the concept of explaining a game design step by step (I'm thinking of a game design to apply this) but meanwhile I have to say that the Step 4 (the "two lines kernel) is a bit hard to understand for me. ? I totally understand the concept of this kernel to actually double the scanlines in order to get more time to prepare things. To avoid the small vertical offset between two objects, some registers in the TIA (Vertical delay features) allows us to solve this problem. So this is clear. Here, we are checking if we have to draw the player : ldy #ARENA_HEIGHT ; 2 7 - the arena will be 180 scanlines (from 0-89)*2 ArenaLoop: ; 13 - from bpl ArenaLoop ; continuation of line 2 of the 2LK ; this precalculates data that's used on line 1 of the 2LK lda #HUMAN_HEIGHT-1 ; 2 15 - height of the humanoid graphics, subtract 1 due to starting with 0 dcp HumanDraw ; 5 20 - Decrement HumanDraw and compare with height bcs DoDrawGrp0 ; 2 22 - (3 23) if Carry is Set, then humanoid is on current scanline lda #0 ; 2 24 - otherwise use 0 to turn off player0 .byte $2C ; 4 28 - $2C = BIT with absolute addressing, trick that ; causes the lda (HumanPtr),y to be skipped DoDrawGrp0: ; 23 - from bcs DoDrawGrp0 lda (HumanPtr),y ; 5 28 - load the shape for player0 sta WSYNC ; 3 31 ;--------------------------------------- ; start of line 1 of the 2LK sta GRP0 ; 3 3 - @ 0-22, update player0 to draw Human ldx #%11111111 ; 2 5 - playfield pattern for vertical alignment testing stx PF0 ; 3 8 - @ 0-22 I understand that (please tell me if I don't get this right) in the first part of this code we compare the actual scanline index (Y register) with the actual human Y coordinate (HumanDraw, one byte stored in RAM), to see if we have to jump to "DoDrawGrp0". (I don't see how the .byte line can allow us to jump to WSYNC, but I have time to get this) If yes, the accumulator is then loaded with the byte contents at "$HumanPtr + y" that stores the actual player shape byte for the actual scanline. We then store the accumulator into GRP0 to draw the player. The player shape is initialized here, in "PositionObjects:" (...) ; HumanPtr = HumanGfx + HUMAN_HEIGHT - 1 - Y position lda #<(HumanGfx + HUMAN_HEIGHT - 1) sec sbc ObjectY sta HumanPtr lda #>(HumanGfx + HUMAN_HEIGHT - 1) sbc #0 sta HumanPtr+1 We load into A the constant value of (HumanGfx + HUMAN_HEIGHT - 1) (low byte part), then we set the carry in order to subtract ObjectY. But in this case, what is exactly "ObjectY" ? The absolute Y coordinate of the player in the screen, or the local sprite line index ? PositionObjects is actually called before the arena draw routine, that's why I don't see how the ObjectY variable is initialized. I also don't see what the three last instructions are doing ? Why do we load and store an other gfx part, and why this part doesn't involve ObjectY ? I really want to fully understand the code presented into this tutorial step before going further. Thanks guys for helping me ?

Thanks ! Here is the result of the modifications made in the video : Nothing complicated.. To use a 27256 eprom, we just have to invert the /OE signal taken from A15. Now for the bigger capacity presented (27C010 eprom) I need to understand why an inverter isn't necessary...!

I saw these schematics, but I'm a bit confused about the memory chips. No chip reference are given, and it looks like (as presented in the video from the first post of ongikong) that we need to invert the /OE signal from the machine if we use "classical" memory ICs like a 27256. This is what I wanted to confirm...

@SpiceWar : these screens are amazing ? ! It's incredible to think that the 2600 can output this. Thanks for sharing them !

Interesting project !

Thanks ! I'll dig into this. ? By any chances, have you written down some schematics for these cartridges ? Looks like that I can re-use the original Atari design, but with adding an inverter for the /OE pins... But if you can confirm...

Many thanks guys for these explanation, it helps me a lot ! @SpiceWare : My mistake, I wanted to say 192, but I now understand that it is possible to adjust a bit this total. Things starts to be more clearer now. Reading through the Random Terrain tutorial I now see who to set-up the playfield, how to put a sprite at a given Y position (I need more time to fully understand the horizontal positioning ?). The problem is that I have issues to mix things together :like how to put two sprites, read the joystick and properly update the PF and background. I've created heavy loops that causes timing issues. I definitely need more tutorials. @SpireWar, yours looks great. I'll print it out and read it. I need to learn if there a clean and "universal" way of building the main scanlines look. Mines are actually like this : set X to 0 load playfield registers store playfield registers WSYNC test the X value to see if I reach a sprite if no, jump to "Next" calculate a local Y corrdinate call and apply the sprite color byte call and display the sprite data byte Next : compare the value of X to see if I need to update the background inx branch to kernel if x < 192 I know that it's better to start my look with X = 192 and decrease the register. But as you can see I have a very heavy loop with too much comparisons, this is what I need to optimize. I tried to study examples from the online 8-bit workshop, but the "advanced" examples are.... too advanced for me. ? Again I need more training. I'll go reading through these new tutorials ! Thanks again.

Thanks @ongikong I'll dig into this. Regarding the video it looks like the adaptation simply consists into a pin by pin rom replacement (by a 27c256) BUT I need to invert the /OE signal. Looks like the original atari ROMs OE signal is active high, not low. Didn't have my 7800 right now with me, but I'm sure that's a PAL version. I learned in your post that most of the PAL games versions are 48k, so my I'll try to adapt the C026445 version with both standard EPROMS. I'll draw a PCB, as I don't have spare carts to use... (And honestly the result presented in the video is a bit... ugly) Did you manage to build other pcbs than the 128k version + RAM ?

Thanks for taking time to explain this. Please let me re-phrase this to see if I got it completely. Again I'm quite a newbie in this, and english is not my first language ? The memory addresses of the 6502 are obviously 16 bits. When writing this in my code : PF0Table ; table 0 .byte %00000000 .byte %00000000 This STATIC label represents the address of the first byte data in this table. During assembly, DASM will replace everywhere in the code "PF0Table" by the actual two bytes of the real address. But as you explain, we can also use a word as a dynamic pointer. The word must be stored in the zero page memory. We use this syntax to get and store the address : lda #<PlayfieldData sta PFPtr lda #>PlayfieldData sta PFPtr+1 into the pointer. "#<PlayfieldData" is the low byte part of the address and "#>" the high part. To actually use the pointer, I must use this syntax : "lda (pointer),y" Is this correct ? Ok the table it looks like it works as you presented. I don't see why the total of the left column doesn't give me 196 or 196/2, but if I try to modify these values it does affect the pattern height. Thanks again !

Question again about byte tables... Could someone help me to understand this syntax : PlayfieldData .byte 4,#%00000000,#%11111110,#%00110000 .byte 8,#%11000000,#%00000001,#%01001000 .byte 15,#%00100000,#%01111110,#%10000100 .byte 20,#%00010000,#%10000000,#%00010000 .byte 20,#%00010000,#%01100011,#%10011000 .byte 15,#%00100000,#%00001100,#%01000100 .byte 8,#%11000000,#%00110000,#%00110010 .byte 4,#%00000000,#%11000000,#%00001100 .byte 0 The binary values are my playfield registers, but I don't what are the left values. The total doesn't even give 192 ! And these strange addressing modes : lda #<PlayfieldData sta PFPtr lda #>PlayfieldData sta PFPtr+1 lda #<Frame0 sta SpritePtr lda #>Frame0 sta SpritePtr+1 PFPtr and SpritePtr are ".word pointers" but I don't really see what they mean... I'll try to find some documentation on this. This code came from the example here : https://8bitworkshop.com/v3.5.1/?file=examples%2Fcomplexscene.a&platform=vcs Thanks !

I'll try to answer... So the 7800 memory map says that the ROM is 4000 - FFFF, so 48 kB in total. The only 48k schematics is this one : http://atarihq.com/danb/7800cart/C026445.shtml It uses a 32k ($8000-$FFFF) and a 16k chip ($4000-$7FFF). But there where a lot of 32k designs, like this one, described as the "standard 7800 cart" : http://atarihq.com/danb/7800cart/C024926.shtml (32k between $8000 and $FFFF) What is the "average" game size for the 7800 ? I know that is was 4k for the 2600, but it looks like 32 could be enough for a majority of games... Maybe it's better to build the first version, and put only the 32k chip for "small" games ?

Thanks, I was afraid that some special hardware was needed to avoid this problem. If it's only dealing with code it's quite easier. I'm not ready yet to run my own programs, but I'll keep this code tool in my devs folder !

Hello there, Quick question... I have a 7800 but didn't have a lot of games. For my 2600 I created a simple PCB with ROM chips inside (UVPROMs actually) that allow me to flash any game on it and play it on the real machine. I also slowly learning 2600 programming, so I'll use this board to run my own creations. ? So my question is can I do something similar with the 7800 ? There is a lot (too much ?) schematics variations available online, like these ones : http://atarihq.com/danb/7800cart/a7800cart.shtml If I choose to make one, is there an "universal" simplest design that I should follow ? And they say here about game locking authentication that "This led Atari to incorporate authentication features in its later console, the Atari 7800, to prevent other companies from creating and selling their own 7800 games without Atari's permission." So it's actually impossible/hard to play homebrew creations on the physical machine ? As you can see I'm a bit confused, so any thoughts on this are welcome !

I am still reading the Stella manual, I missed that part. I thought that D1 was low, but I had an issue with the CTRLPF assignment. Problem solved, thanks again ! ?

I discovered a mistake in my code but again I didn't manage to see what's wrong... My playfield was working fine with this : ldx #0 Kernel lda PF0Table,x sta PF0 lda PF1Table,x sta PF1 lda PF2Table,x sta PF2 lda #0 sta WSYNC ;updating colors cpx #129 bne Next lda #$C4 ;couleur Vert sta COLUBK Next cpx #148 bne Next2 lda #$F4 ; Marron sta COLUP0 ; couleur playfield GAUCHE sta COLUP1 ; couleur playfield DROITE Next2 cpx #106 bne Next3 lda #$B6 ; Vert sta COLUP0 ; couleur playfield GAUCHE sta COLUP1 ; couleur playfield DROITE Next3 inx cpx #192 bne Kernel I use some CPX instructions to compare my X register value (scanline counting) and apply some changes to the background register and playfield color. But I was wrong, I was actually writing into COLUP0 and COLUP1 registers (player sprites colors). So I updated the code to use COLUPF instead : ldx #0 Kernel lda PF0Table,x sta PF0 lda PF1Table,x sta PF1 lda PF2Table,x sta PF2 lda #0 sta WSYNC ;updating colors cpx #129 bne Next lda #$C4 ;couleur Vert sta COLUBK ; registre couleur ARRIERE PLAN Next cpx #148 bne Next2 lda #$F4 ; Marron sta COLUPF ; couleur playfield Next2 cpx #106 bne Next3 lda #$B6 ; Vert sta COLUPF ; couleur playfield Next3 inx cpx #192 bne Kernel But it doesn't works anymore... All my playfield is black. What I am doing wrong ? ?

I don't know what assembler tool is used in my online IDE, I'll check if DASM is doing the error when using it offline...

Whoaa, MANY thanks, I was really stuck ! Works perfectly now. ? So in my first case, the system was adding a blank byte after the comma because he was expecting data ?

Hello there, I am slowly digging into 6502 assembly language and 2600 programming, so please be indulgent, this is my first experiment ? I first started to deal with drawing a background. I created a small C++ app to help me convert a bitmap picture into code to fill my PF0 to PF2 registers for each scanline. Adding some color changes mid-lines and here we are : I am working with 8bitworkshop to edit, assemble and run my code. My drawing code was composed by heavy lines like this : PictureLoop1 ;clear PF registers lda #0 sta PF0 sta PF1 sta PF2 sta WSYNC inx cpx #10 ;total cumule bne PictureLoop1 ;------------------------------------------------ PictureLoop2 ;Init playfield patterns for ONE or more scanline lda #%00000000 sta PF0 lda #%00001000 sta PF1 lda #%00000000 sta PF2 sta WSYNC inx cpx #11 ;total cumule bne PictureLoop2 I simply loop on similar scanlines to draw them, and I use the X register as my main scanline counter. To add efficiency I wanted to replace these lines by a call to byte tables, as explained here. So my new drawing routine is this one : ldx #0 ;2 Kernel lda PF0Table,x ;4 sta PF0 ;3 lda PF1Table,x ;4 sta PF1 ;3 lda PF2Table,x ;4 sta PF2 ;3 sta WSYNC ;3 inx ;2 cpx #192 bne Kernel ;3(2) With PF0Table my table for PF0, and so one. And of course I have these at the end of my code : PF0Table ; table 0 .byte #%10000000, .byte #%10000000, .byte #%10000000, .byte #%11000000, (...) But it doesn't works as expected. Here is the result: It looks like that my tables are correctly loaded, but why there is a "blank" line after every scanline ? I didn't get why. Attached is the full code. Am I doing something wrong ? Thanks in advance ! problem.asm