vidak

I think it's possible - the idea just dawned on me, though. People have already written compilers for brainfuck, and have done it in around 1KB. I suppose I would just have to reimplement their sourcecode. I think I would perhaps implement the 7-bit ASCII character set, but that would take up room. Perhaps I could go with a 5-bit character set, and forego lower case characters. The code for "Hello World" looks like this: 1 +++++ +++ Set Cell #0 to 8 2 [ 3 >++++ Add 4 to Cell #1; this will always set Cell #1 to 4 4 [ as the cell will be cleared by the loop 5 >++ Add 4*2 to Cell #2 6 >+++ Add 4*3 to Cell #3 7 >+++ Add 4*3 to Cell #4 8 >+ Add 4 to Cell #5 9 <<<<- Decrement the loop counter in Cell #1 10 ] Loop till Cell #1 is zero 11 >+ Add 1 to Cell #2 12 >+ Add 1 to Cell #3 13 >- Subtract 1 from Cell #4 14 >>+ Add 1 to Cell #6 15 [<] Move back to the first zero cell you find; this will 16 be Cell #1 which was cleared by the previous loop 17 <- Decrement the loop Counter in Cell #0 18 ] Loop till Cell #0 is zero 19 20 The result of this is: 21 Cell No : 0 1 2 3 4 5 6 22 Contents: 0 0 72 104 88 32 8 23 Pointer : ^ 24 25 >>. Cell #2 has value 72 which is 'H' 26 >---. Subtract 3 from Cell #3 to get 101 which is 'e' 27 +++++ ++..+++. Likewise for 'llo' from Cell #3 28 >>. Cell #5 is 32 for the space 29 <-. Subtract 1 from Cell #4 for 87 to give a 'W' 30 <. Cell #3 was set to 'o' from the end of 'Hello' 31 +++.----- -.----- ---. Cell #3 for 'rl' and 'd' 32 >>+. Add 1 to Cell #5 gives us an exclamation point 33 >++. And finally a newline from Cell #6 The same program in minimised form: ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++. The main problem is having enough RAM. Writing brainfuck as an interpreter would take up RAM, and writing a compiler would require the 2600 to /write/ the program somewhere on the cart, and that may be possible with some extra bankswitched SRAM or some sort of non-volatile RAM? Anyway I just wanted to bring this idea I had up to see if anyone found it interesting.

Well what I mean is I could make a cart not unlike Warren Robinett's BASIC cartridge except you would have a much lower and more powerful control of the hardware while programming on the 2600. You would only need at least 8 buttons, as well, not counting text formatting keys. The premise of brainfuck is that you have a one-dimensional array of memory cells, that can each hold an 8-bit number. You may move left and right along the memory cell list, and you may decrement and increment the value in a memory cell. You may also write out the value of the memory cell to the console, and you may read in a value from the console. You may also set up loops, and nested loops, to iterate over sections of code. I believe this esoteric language is sufficiently simple enough to allow some limited programming natively on the Atari 2600 console, so you may write and execute programs in real time on your own 2600.

I've done some googling, and it is possible. I also know you can do self modifying code - changing the code in RAM and /then/ executing it. I think the general idea is to point the program counter to the address locations in RAM. So you'd need to set RORG to somewhere between the beginning of RAM ($80) and the end of RAM, I think.

I vote for a challenge too!

I have to be brief because my partner is calling me haha: - there is an esoteric langauge with 8 operations - they are represented by the symbols .,<>[]+- - the compiler can be as small as 1KB - it is called 'brainfuck' programming ON the 2600??

Okay today I implemented the bank switching. I think this makes my data structures much more parsimonious. don't forget to check out where I keep my code: github.com/bootlicker/guerrilla-game === Things I still need to do in this phase are: - write out the debug graphics into the kernel - finish implementing the 24-bit Random Number Generator - link the RNG and the Environment Graphics pointers InitSystem.asm OverworldVB.asm che_main.asm

Okay hopefully I have understood this correctly: ORG and RORG stand for the 'origin' in the address space for the 6502/6510 processor. RORG stands for 'relocatable origin', and is more powerful than ORG. ORG just stands for 'origin'. The way they work is like this: - Every processor has a memory address space. The 6502 has a 16-bit address space, whereas the 6510 has a 12-bit address space (why is not important here). - The processor loads instructions, or accesses RAM, or controls video cards by recieving or sending data to different address locations. - Here are some address locations: $0000, the top of memory; $FFFF, the bottom of memory, also known as the top of the stack; $80, or $0080, the top of the RAM in the Atari 2600. The importance of the commands ORG and RORG is to sort of 'virtually' control where the CPU thinks it is addressing. So you have the 'real' origin, then you have the 'controlled' origin which is determined by RORG and ORG. Remember the address space of the 6510 in the 2600 is 12-bit, which means it can only access $0000 to $0FFF. But we have the ability of compiling code beyond these limits. What you can do to sort of 'simulate' address spaces bigger than 12 bits is use RORG to relocate the memory address location $0000 to a different place. So when you write: RORG $1000 you are relocating the apparent location of $0000 to $1000 in the memory address of the ROM. So the processor thinks it is at $0000 but actually it is executing from $1000. The same goes for RORG $1FF4, RORG $FFFB etc. All of these commands make the CPU actually execute from $1FF4 or $FFFB, but the processor will think it is executing from $0000. Now what about ORG? It would be irritating to have to be guessing where you were within a RORG 'jump'. You can shift within a 'virtual' RORG by using ORG. Here's an example: RORG $0000 (or REND) ORG $1000 Here we are executing from the REAL top of memory, so the origin is the REAL origin, and then we jump to $1000 in memory. So we are executing from $1000 in reality, and the processor THINKS it is executing from $1000. Another example: RORG $E000 ORG $0300 Here we relocate the virtual address $0000 to $E000, and then we jump to $0300 within $E000. So the processor is in reality executing from $E300, but the processor thinks it is executing from $0300. == Why is this useful? When it comes to bank switching, you must use RORG to shift the apparent/virtual memory address because your overall code may be 16K, 8KB, or say 32KB. The 6510 can only address 4KB of memory because of the way it is manufactured (I predict there will be some arguments about it actually being able to address 8KB, but I am just going to wait for someone else to address that), so you need to make sure it thinks it is executing within addresses $0000 and $0FFF, otherwise you will be addressing memory it absolutely cannot access. I have read 80% of the Stella Mailing List, and I never saw this come up, so hopefully this helps someone.

far be it for me to prefer someone else's code over SpiceWare's... but i actually like yours better! what's your new project on? you've obviously finished nyancat haven't you! my email/XMPP is always open!!

okay these are my efforts for today: extending the random number generator to 32 bits, from 16 bitsI will be reducing the RNG to 24 bits, because I didn't understand the combinatorial choosing. I only need to choose 4 x 6 bits = 24 bits. 24 Choose 6 = 134596, and 134596 > 2^16 / 64k. 2^6 = 64, which means I can include 64 unique objects in the world. Extending the random number generator to 32 is still possible while drawing a (synchronised) blank frame in order to make up time for calculation of an entire row of 256 cells. So I should now be able to ensure a good degree of randomness in a 256 x 256 world. This is what I really wanted to do. Started implementing bank switching. I will be using F4 bank switching. I may not need to use every bank. Bank 1 = System Initialisation + Titlescreen + Menu Bank 2 = Vertical Blank for Overworld (Processing Map Coordinates, Joystick + NPC movement, Frame skip logic, Overworld RNG logic) Bank 3 = Overworld Kernel + Graphics (64 x 25 bytes graphics ~= 1.6k ROM) Bank 4 = Overworld Overscan (Overflow for vertical blank) Bank 5 = Vertical Blank for Battle Kernel (Processing Joystick, NPC movement within Battle mode) Bank 6 = Battle Kernel + Graphics Bank 7 = Battle Overscan (Overflow for vertical blank) Bank 8 = Empty at the moment

Would someone be able to explain F4 bank switching to me? I think I will include some how-tos on my blog about how to set it up. From looking at Stay Frosty, I gather the following code is meant to use used: ==== MAC JUMP_TABLE ; put this at the start of every bank RORG $F000 InitSystem cmp SelectBank8 ; inits system then goes to the menu jmp Label ; jump to Main Menu Kernel cmp SelectBank7 jmp KernelCode OverScan cmp SelectBank8 jmp OverScanCode ===== MAC BANKS_AND_VECTORS ; put this at the end of every bank RORG $FFF4 SelectBank1 .byte $00 SelectBank2 .byte $00 SelectBank3 .byte $00 SelectBank4 .byte $00 SelectBank5 .byte $00 SelectBank6 .byte $00 SelectBank7 .byte $00 SelectBank8 .byte $00 .word InitSystem ; NMI and 8 overlap NMI .word InitSystem ; RESET .word InitSystem ; IRQ ENDM ; Define a segment for code SEG CODE ; - bank 1 ORG $E000 JUMP_TABLE ; bank 2 ORG $F000 JUMP_TABLE My question is - I want to use all eight 4K banks, and Stay Frosty only uses two. I include BANKS_AND_VECTORS at the end of every bank. I assume I must include a different ORG vector/statement that is not $E000 or $F000 for the other banks, but what locations do I give? Thanks in advance!

I'm more than happy to host the full de-linked commo dig on my blog https://bootlicker.party !

oh holy crap! that's awesome! i'm glad it helped someone!

OKAY. I AM BACK. I AM DEDICATING TIME TO THIS TODAY. I am making the world procedurally generated. It is what I really and actually want to do.

noice!!!

I realised after making the map that I could randomly generate a maze, but I think I will stick with a static world because the bosses and overall game progression would not really change

aaalrighty. i have designed the overworld. it is 171 screens. i think a 32KB cartridge will have enough space to store all the information for this. there are bosses and mini bosses. you will have to defeat a boss in order to unlock another area - i imagine to get to the mountain summit, you will have 2 boss areas accessible, and you will have to defeat both in any order in order to get to the final area. i think i will draw up the code and the lookup table for each screen on another day.

I guess I'm also still a beginner - I think maybe I am biting off too much for myself to chew too early!

Okay I have had a think, and I think I am going to ditch the procedural generation. My reasoning stems from a desire for good game design. I haven't even implemented the main game mechanic in the game, and I want to be able to teach people how to play the game as they play it. My current worry is that throwing people into a randomly generated world with very little structure, and very little easy scope for creating structure, will simply turn people off from enjoying the game. I will create a reasonably linear world, and it will step players through a learning curve, and it will give the game a lot more structure.

Awesome. Those are some great suggestions. I am going to try and get the output of whatever RNG linked to the Environment Graphics pointers, and then we'll see what happens. I was toying with the idea of avoiding random generation altogether, but I think I will stick with it.

Thanks so much!

I understand that, my original question was how does the masking affect the randomness?

Ohhh I get you now. Use BASIC as a kind of ersatz outline of what I want to do in ASM!

Have you tried disassembling small C programs? They obviously work, but they don't look logical in ASM. They use strange sequences of operations to do simple tasks - hand written ASM is always more efficient in code density and overall speed. Only really code written in ASM can be disassembled and then read as ASM - even then the output is difficult to comment and understand. You need a debugger and you need to be able to step through the code in an assembly monitor. Would it be worthwhile having me write something on 6502 ASM? It is very easy to learn, and is a very beautiful instruction set.

How do you know, Jeremiah????!!!