DPC+ simple custom kernel help needed

[Lillapojkenpåön]

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

 

[Lillapojkenpåön]

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 January 11, 2019 by Lillapojkenpåön

[Lillapojkenpåön]

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

[iesposta]

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?

[Lillapojkenpåön]

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

[iesposta]

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.

[Lillapojkenpåön]

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?

[Lillapojkenpåön]

It's not perfect but you can jump between the regular and custom kernel with joy0fire and joy1fire

 

custom_kernel.bas

[+mksmith]

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

[+Karl G]

It's not perfect but you can jump between the regular and custom kernel with joy0fire and joy1fire

 

custom_kernel.bas

 

Hitting fire doesn't seem to do anything.

[Lillapojkenpåön]

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!

[+Karl G]

 

Haha good, then it works!

 

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

 

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

[Lillapojkenpåön]

 

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

[+Karl G]

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.

[Lillapojkenpåön]

Ok, well I can still do exactly what I wanted now thanks to your splashscreen!

Requesting a standalone 96 pixel kernel from Mr. Karl G I would do it but I can't decipher the titlescreen kernel whatsoever!

Ooohh I can picture a nice NES style titlescreen

 

 

 

custom_kernel3.bas

custom_kernel3.bas.bin

 

[Lillapojkenpåön]

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

custom_kernel5.bas

custom_kernel5.bas.bin

Edited January 15, 2019 by Lillapojkenpåön

[+Karl G]

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.

[Lillapojkenpåön]

I didn't expect you to I allready got the 96 pixels working, must be my new add medicine.