Closed Esshahn closed 5 years ago
Also I noticed that you assign the border and bg colors directly like
lda #$07
sta $d020
For consistency, I'd recommend to assign these in the same modular way as the chars and colram, therefore
lda frame0000
sta $d020
lda frame0000+1
sta $d021
All of this makes sense. Will implement maybe even for 0.4 already.
Cool! While you are at it, I think it makes sense to put the bg+border colors at the end of the data section, this would save you the many +2 additions on char and colram copy code, like:
lda (screen_pointer)+2+0*$100,x
sta $0400+0*$100,x
lda (screen_pointer)+2+25*40+0*$100,x
sta $d800+0*$100,x
I implemented https://github.com/nurpax/petmate/issues/100#issuecomment-417635399 now.
The last https://github.com/nurpax/petmate/issues/100#issuecomment-417715496 I'd prefer not to implement because that'd change the binary layout of the .asm files. There are probably not many users of petmate generated .asm files but at least Viza already made a demo with Petmate asms. If I change it, any code using Petmate .asm exported files would break. The adds are free as it's the assembler that computes the add.
Not sure how useful the color & screen labels are. If you know the binary layout, then at least in KickAssembler you can do
.const screen000 = screen_000 + 2
.const color000 = screen_000 + 1002
Why not add them? Well, the fewer symbols the .asm defines, the less chance there is for a name conflict between .asm exported files and the code using it.
Nice that you are concerned about me, but not necessary :)
Anyway, in that particular case, I used the C export, and ignored the bg/border colors completely (cause that was the same for the whole intro). Plus done a bunch of modifications by hand - one of them was the renaming of the screens, but in other cases I used only parts of the exports (only the character data for the scroll letters, copied parts of the color data for color scrolls/flashes), and for the scroll letters I heavily rearranged the whole data to use a three chars tall long strip instead of trying to index the chars on a 40x25 screen in three lines...
Well, most of this doesn't matter, just sharing my workflow :) There will be always uses, when one needs to edit the data to suit her needs... To handle that petmate should support some kind of exporting scripting language or something, which is probably beyond its scope, i guess.
To handle that petmate should support some kind of exporting scripting language or something, which is probably beyond its scope, i guess.
Well, this scripting language already exists. It's called Python. :) Shouldn't be too hard to load either .c or .asm files (or just .petmate) and then re-export into any output format.
Well, actually petmate has already support for a scripting language, called javascript :) I don't know if "eval" would still work in this environment, but granting access to the drawing data still can cause problems. It would be doable (probable), but IMHO not worth the effort.
I agree with Viza, no way to please everybody. I'm actually okay with not adding more labels, your have valid points for not doing it nurpax.
As for the position of the border and bg bytes, I can rearrange them by hand I guess.
@Esshahn: I don’t understand why the adds are a problem? The machine code will be the same in both cases, just the ptr offset changes and that’s computed by the assembler.
Marq’s petscii .c also has the colors at the beginning so I just went with that since to me this is just a comvention.
Nevermind, it's really just me trying to make my code work :D
The "modular" petscii display routine is basically working with your asm format, just some optimization and correcting the 4th loop length needed.
petscii_init
lda #<screen_001 ; address low
sta $03 ; store in ZP
lda #>screen_001 ; address high
sta $04 ; store in ZP
lda #<screen_001+1002 ; address low
sta $05 ; store in ZP
lda #>screen_001+1002 ; address high
sta $06 ; store in ZP
ldy #0
lda ($03),y ; load bg color
sta $d020 ; store bg color
iny
lda ($03),y ; load border color
sta $d021 ; store border color
inc $03 ; increment 2 times to get to the char ram
inc $03
ldx #4 ; loop counter
ldy #0 ; value index for loop
petsciiloop
lda ($03),y ; load value in address to read from
sta $0400,y ; store value in screen ram
iny ; we want to cycle all 256 values
bne petsciiloop ; not 0 again yet? repeat
inc $04 ; increment address high in ZP
inc petsciiloop+4 ; increment address high of screen ram
dex ; decrement loop counter
bne petsciiloop ; end of loop reached?
ldx #4
ldy #0
colramloop
lda ($05),y ; load value in address to read from
sta $d800,y ; store value in screen ram
iny ; we want to cycle all 256 values
bne colramloop ; not 0 again yet? repeat
inc $06 ; increment address high in ZP
inc colramloop+4 ; increment address high of screen ram
dex ; decrement loop counter
bne colramloop ; end of loop reached?
rts ; done
Marq is adding labels to the asm export, which makes it very easy to locate the colram. Would this be working for petmate as well?
e.g.