More than one bit

[More than one bit]

I vote for a challenge too!

[Programming ON the 2600: esoteric langauges]

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??

["Sierra Maestra", an Early WIP]

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

["Sierra Maestra", an Early WIP]

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.

["Sierra Maestra", an Early WIP]

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!!

["Sierra Maestra", an Early WIP]

okay these are my efforts for today:

 

• extending the random number generator to 32 bits, from 16 bits
  • I 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

["Sierra Maestra", an Early WIP]

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!

[Commo Mini Dig in a single file]

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

[Commo Mini Dig in a single file]

oh holy crap!

that's awesome!

 

i'm glad it helped someone!

["Sierra Maestra", an Early WIP]

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.

[Nyan Cat Game - Work in Progress]

noice!!!

["Sierra Maestra", an Early WIP]

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

["Sierra Maestra", an Early WIP]

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.

["Sierra Maestra", an Early WIP]

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

["Sierra Maestra", an Early WIP]

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.

["Sierra Maestra", an Early WIP]

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.

["Sierra Maestra", an Early WIP]

Thanks so much!

["Sierra Maestra", an Early WIP]

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

["Sierra Maestra", an Early WIP]

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

["Sierra Maestra", an Early WIP]

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.

["Sierra Maestra", an Early WIP]

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

[Hi, I'm working on a project for school, and im unskilled with coding.]

I have documented most of the ancient Stella Mailing List here: https://bootlicker.party/commo-dig/

I have also assembled a kind of cookbook for learning Atari coding here: https://bootlicker.party/atari-2600-programming/

Check out SpiceWare's Collect tutorial, as well! Just search it in the blogs section!

OH and I'm always here if you need help.

Check out "Old Skool Coder" on youtube for how to program in 6502 Assembly Language. It's very easy.

["Sierra Maestra", an Early WIP]

No worries!

 

If I have a choice, I always use Free and Open Source software!

[Castle of Doom]

I'll see if I have some time to make a bat sprite.

["Sierra Maestra", an Early WIP]

more tree graphics! i think i've figured this out.

 

This is how you can cheat and make easy graphics for the 2600:

 

1. Get an image with a dark foreground and light background
2. Open GIMP
3. Under the Colours menu, select Levels
4. Adjust the black and white levels so that the image you want to pixelate becomes incredibly dark. Adjust the levels so that the background becomes incredibly light. The image should look like a sharp silhouette.
5. Open the Filters menu, and select the Blur submenu. Select the Pixelize option.
6. Adjust the size of the pixels in the pixellated image so that you have roughly 8 blocky pixels width-wise. I usually adjust the height of the pixels so that they match the aspect ratio of the GRP0/GRP1 pixels.
7. Copy over the silhouette image to Kirk Israel's PlayerPal2
8. Play around with the image so that it looks beautiful. Usually GIMP will only be able to help you create an intermediate image that you then finalise in the PlayerPal.