Jump to content
Lillapojkenpåön

DPC+ simple custom kernel help needed

Recommended Posts

I'm trying to make a very simple kernel that only draws playfield, playfieldcolor and backgroundcolor that I can jump to when needed.

 

I thought it would be very simple and that the playfield, playfieldcolors and backgroundcolors you had set in bB would have all the fetchers and pointers ready to just add for example this before the kernel

 

LDA #255
STA DF6FRACINC
LDA DF6FRACDATA ; priming read (first value will be read twice)
and this in the kernel to draw your bgcolors
lda #<DF6FRACDATA
sta COLUBK

 

but that didn't work, do you have to set the fetchers or something every frame to?

DF?LOW
DF?HI
DF?FRACLOW
DF?FRACHI

 

Share this post


Link to post
Share on other sites
It makes sense that you have to reset the pointer, I guess you do that like this, it works atleast.


lda #<BKCOLS

sta DF6FRACLOW

lda #(>BKCOLS) & $0F

sta DF6FRACHI




LDA #128 ;255 resulted in single line, weird, I have DF6FRACINC=255 in the bB loop, is the bB kernel 2 lines?

STA DF6FRACINC

LDA DF6FRACDATA ; priming read (first value will be read twice)

Edited by Lillapojkenpåön
  • Like 1

Share this post


Link to post
Share on other sites

If someone wants to help me with the playfield that would be awesome.

 

 

dffraclow2
.byte <PF1L
.byte <PF2L
.byte <PF1R
.byte <PF2R
.byte <PFCOLS
.byte <NUSIZREFP
.byte <BKCOLS
.byte <P1HMP
dffrachi2
.byte (>PF1L) & $0F
.byte (>PF2L) & $0F
.byte (>PF1R) & $0F
.byte (>PF2R) & $0F
.byte (>PFCOLS) & $0F
.byte (>NUSIZREFP) & $0F
.byte (>BKCOLS) & $0F
.byte (>P1HMP) & $0F
VerticalBlank:
ldx #7
setloopfrac2
lda dffraclow2,x
sta DF0FRACLOW,x
lda dffrachi2,x
sta DF0FRACHI,x
dex
bpl setloopfrac2
LDA #128 ; 255 and 2lk might be better
STA DF6FRACINC
LDA DF6FRACDATA ; priming read (first value will be read twice)
STA DF4FRACINC
LDA DF4FRACDATA ; priming read (first value will be read twice)
LDA #64 ; 128 and 2lk might be better
STA DF0FRACINC
LDA DF0FRACDATA ; priming read (first value will be read twice)
STA DF1FRACINC
LDA DF1FRACDATA ; priming read (first value will be read twice)
STA DF2FRACINC
LDA DF2FRACDATA ; priming read (first value will be read twice)
STA DF3FRACINC
LDA DF3FRACDATA ; priming read (first value will be read twice)
;The Kernel is the section of code that draws the screen.
Kernel:
sta WSYNC ; Wait for SYNC (halts CPU until end of scanline)
lda INTIM ; check the timer
bne Kernel ; Branch if its Not Equal to 0
; turn on the display
sta VBLANK
; draw the screen
; ldx #96 ; for 2lk
ldx #192 ; Load X with 192
lda #0
sta FASTFETCH
KernelLoop:
sta WSYNC ; Wait for SYNC (halts CPU until end of scanline)
lda #<DF6FRACDATA
sta COLUBK
lda #<DF0FRACDATA
sta PF1
lda #<DF1FRACDATA
sta PF2
lda #<DF2FRACDATA
sta PF1
lda #<DF3FRACDATA
sta PF2
lda #<DF4FRACDATA
sta COLUPF
dex ; DEcrement X by 1
bne KernelLoop ; Branch if Not Equal to 0
OverScan:
ldx #255
stx FASTFETCH

Share this post


Link to post
Share on other sites

In batari Basic just write code using playfield, playfieldcolor and backgroundcolor.

If using VisualbB uncheck "clean up" or remove temporary files.

 

bB outputs 2 .asm files you can study, along with .sym and .lst text files.

 

Lots of bB DPC+ use a 2 line kernel, however the Players are 1 line kernel, playfield is 1 line kernel.

color is every other line change for playfield and background I am not sure if that is due to the 2 line kernel parts or not?

Share this post


Link to post
Share on other sites

That's what I usually do, but that doesn't help much with the kernel, the kernel has this for playfield

 

lda #<DF0FRACDATA
sta PF1 ; (PF1L)
lda #<DF1FRACDATA
sta PF2 ; 31 (PF2L)
lda #<DF2FRACDATA ;45
sta PF2 ; 48
lda #<DF3FRACDATA ;53
sta PF1 ; 56
While the documentation has this
; then in the kernel read the Fractional Data Fetchers and update the playfield
; LDA DF0FRACDATA
; STA PF0
; LDA PF1FRACDATA
; STA PF1
; ... repeat for Data Fetchers 2-5, putting them in PF2, PF0, PF1 and PF2
It doesn't match, also believe there's some crucial timing to consider when you update playfield, I will try again tomorrow, would just like some tips or something :)

Share this post


Link to post
Share on other sites

The second assembly, when compiling a file, called bB.asm Has more native code than the first one.

 

Is this for bB or pure assembly game?

 

Im not clear what you need to do, but it is probably awesome!

 

The Titlescreen Kernel is an example of an independent Kernel. Any shared variables restored when returning to bB. It doesnt use data and graphics from the bB code.

 

In bB when you call drawscreen the compiled code chooses from around 12 canned kernels depending on what has been set and programmed. These canned kernels are include from bBs includes folder.

Study those text files to find the kernels.

Share this post


Link to post
Share on other sites

It's assembly for bB, my thought was that there are a couple occasions in my game where there's nothing going on, only the playfield and background is being drawn, where I wish I could have text, like when you kill the boss and your points are being counted, would be cool if I could write "bonus points" or something using the players.

 

It would be absolutely impossible to modify the existing bB kernels to do that, but what if you jumped to a inline assembly custom kernel that does only that? Might work?

Share this post


Link to post
Share on other sites

I would love some sort of ability to write to the screen. Change of level, game over messages etc would be awesome!

Share this post


Link to post
Share on other sites

I would love some sort of ability to write to the screen. Change of level, game over messages etc would be awesome!

Me too! I will try and look at how it's done in the titlescreen kernel, if RevEng or someone wants to make it happen in two seconds they are more then welcome to :)

 

 

Hitting fire doesn't seem to do anything.

Haha good, then it works!

Share this post


Link to post
Share on other sites

 

Haha good, then it works!

 

How could you tell if it wasn't working, then? :P

 

I guess I figured that your custom kernel would do something different!

Share this post


Link to post
Share on other sites

 

I guess I figured that your custom kernel would do something different!

I tried merging it with your bBsplash Mr. G, do you think there's any chance there's enough time for this in the LogoLoop?

 

lda #<DF6FRACDATA
sta COLUBK
lda #<DF0FRACDATA ;PF1L
sta PF1
lda #<DF1FRACDATA ;PF2L
sta PF2
lda #<DF4FRACDATA
sta COLUPF
lda #<DF2FRACDATA ;PF1R
sta PF2
lda #<DF3FRACDATA ;PF2R
sta PF1

 

;----------------------------------------
; Fast Fetch Mode
;----------------------------------------
; Fast Fetch Mode enables the fastest way to read DPC+ registers. Normal
; reads use LDA Absolute addressing (LDA DF0DATA) which takes 4 cycles to
; process. Fast Fetch Mode intercepts LDA Immediate addressing (LDA #<DF0DATA)
; which takes only 2 cycles! Only immediate values < $28 are intercepted
;
; set Fast Fetch Mode
; LDA #0
; STA FASTFETCH
;
; then use immediate mode to read the registers, takes just 5 cycles to update
; any TIA register
;
; LDA #<DF0DATA
; STA GRP0
;
; when done, turn off Fast Fetch Mode using any non-zero value
; LDA #$FF
; STA FASTFETCH
;
; NOTE: if you forget to turn off FASTFETCH mode, then code like this will not
; work as you expect
; LDA #0 ; returns a RANDOM NUMBER, not 0.
; STA COLUPF
;----------------------------------------
FASTFETCH DS 1 ; $58

 

 

Maybe it would even be possible to use DF5FRACDATA and DF7FRACDATA for the first GRP0 and GRP1 then turn off fastfetch?

I think they will reset to what they usually do when you return to the bB kernel.

 

Or load the values after the logo has been drawn, and update before on the next scanline?

 

I'm not gonna get any further then this right now so I hope someone picks up the ball.

 

custom_kernel2.bas

Share this post


Link to post
Share on other sites

My experience with DPC+ and fastfetch is very limited. I guess it would save you 18 cycles due to the loads being 2 cycles instead of 5, and you are trying to add 30. It probably wouldn't be enough, and also the timing matters, too - you aren't going to be able to break-up a 48-pixel routine in the middle by loading the right half of your playfield and have it still work.

Share this post


Link to post
Share on other sites

I wanted score and pfscore in my custom kernel to so I'm gosub'ing to the allready existing scorekernel to save space.

Had to modify the DPCplus_kernel slightly so it either returns or returns otherbank depending on what's in temp5

 

It's very close to working, only the scoredigits aren't showing (or being colored?) until after atleast one bB drawscreen has been called.

 

Just replace the following line at the very bottom of includes/DPCplus_kernel.asm

 

rts

 

With this..

 

lda temp5
cmp #255
beq _return_otherbank
rts
_return_otherbank
JMP BS_return
and SAVE (just restore it later)
What is it that I am missing?
Jump to the custom kernel with joy0fire
Edited by Lillapojkenpåön

Share this post


Link to post
Share on other sites

I don't really want to make other standalone kernels - if something more than a simple single-color 48-pixel splash screen is needed, I suggest using the actual Titlescreen kernel. It's a bit of work, but it's well-documented and worth the effort.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...