Getting started with the DPC+ Kernel

[+Gemintronic]

I just installed 3.9 and I get black flashes when running this binary. Just another data point.

[+Atarius Maximus]

I just installed 3.9 and I get black flashes when running this binary. Just another data point.

I guess it's not related to Stella then. It's been a while since I've looked at it, but I can do a review of the code and see if there are any obvious errors.

[+Atarius Maximus]

I can't seem to replicate the problem now on 3.8.1 or 3.9, it's working fine on both. The only obvious potential problem I see is the number of lines I used in the playfield. According to the original chart posted by batari, setting DF(0-3)FRACINC to 255 should provide 176 lines of playfield resolution and I have 175 defined. Maybe that's the problem? This version simply adds one line of playfield resolution to the bottom. Unfortunately I can't really troubleshoot this without being able to replicate the problem.

dpcgame7.bin

dpcgame7.txt

[RevEng]

That doesn't seem to help, but compiling with official 1.1d does. There seems to be a difference between the binaries produced here between the bB releases, but the asm produced doesn't have anything unusual, so I'm thinking it's some arm issue. [edit - definitely an arm code issue, though not an obvious one]

 

Leave it with me guys. I'll push and pull on it tonight.

[+Atarius Maximus]

That doesn't seem to help, but compiling with official 1.1d does. There seems to be a difference between the binaries produced here between the bB releases, but the asm produced doesn't have anything unusual, so I'm thinking it's some arm issue. [edit - definitely an arm code issue, though not an obvious one]

 

Leave it with me guys. I'll push and pull on it tonight.

Thanks Mike, we'll leave it to the expert. I was compiling with the older version of bb (not the updated one) which is why I couldn't replicate the problem again. The binary that RT posted flashes to black and has an unsteady scanline count regardless of the Stella version.

[RevEng]

I've updated my code to v10, and with the program seems to work the same as with previous bB versions, without the blackout.

 

I think it was some kind of arm alignment issue I'm not up to speed on. Shrinking my added pfread command appears to have done the trick.

[+Random Terrain]

I've updated my code to v10, and with the program seems to work the same as with previous bB versions, without the blackout.

 

I think it was some kind of arm alignment issue I'm not up to speed on. Shrinking my added pfread command appears to have done the trick.

 

Problem seems to be gone. Thanks.

[iesposta]

RevEng,

The last post batari left said,

"Here is the latest build;It fixes many of the issues that have been reported since the last release, and adds some requested features in DPC+. I added:

multiple player definitions (untested)

pfpixel, pfvline and pfhline

Collision detection:

* Pixel-perfect collision(player#,player#) where # is 0-9, for any two real or virtual player sprites (doesn't support NUSIZ changes yet, sorry.)

* A kernel_option controls an in-kernel read of a standard hardware collision register (example: set kernel_options collision(player1,playfield) will return the y-coordinate where the first such collision occurs, so you can later figure out what sprite it was.) Value is returned in temp4 after a drawscreen.

Smooth scroll in from left or right (upper two bits of NUSIZ control this.)

There is more, and I'll expand on that later."

 

About that last line, can you find any undocumented DPC+ commands in the source code?

I have looked and remember seeing something near the end of one of the files...

Thanks for implementing pfread, what a bonus. I'll have to learn how to use that.

Also the next command hacked in could be vertical Playfield scrolling so I can make Xevious and Bump N Jump.

[RevEng]

Nothing has jumped out at me so far. I'll go on a more detailed hunt tomorrow.

 

At this point I'm going to avoid adding any new commands, fix any further bugs that pop up in the next few weeks, try to hand off to batari, and call it done. The future of the language belongs in batari's hands.

[+Random Terrain]

The future of the language belongs in batari's hands.

 

Hopefully all future updates and fixes can be posted in once place, like you have done here.

[RevEng]

About that last line, can you find any undocumented DPC+ commands in the source code?

 

I dug for a bit. I don't see any undocumented DPC+ commands in the source.

[iesposta]

I was particularly interested in these:

I don't think I have ever seen them, let alone know how to use them or if they work.

You can see other things that do work and are used like missile0y, etc.

RAMcopybegin? statusbarlength? lifecolor? lifepointer? lives?

I think Scumsoft was doing things with ram copy, but he is no longer around.

 

RAMcopybegin = SpriteGfxIndex

RAMcopylength = *-RAMcopybegin

 

missile0y ds 1

missile1y ds 1

bally ds 1

 

missile0height ds 1

missile1height ds 1

ballheight ds 1

 

statusbarlength ds 1 ; needed?

aux3 = statusbarlength

 

lifecolor ds 1

pfscorecolor = lifecolor

aux4 ds 1

 

lifepointer ds 1

lives ds 1

pfscore1 = lifepointer

pfscore2 = lives

aux5 = pfscore1

aux6 = pfscore2

 

playfieldpos ds 1

 

temp1 ds 1 ; used in sprite flickering

temp2 ds 1 ;are obliterated when drawscreen is called.

temp3 ds 1

temp4 ds 1

temp5 ds 1

temp6 ds 1

temp7 = topP1x ; This is used to aid in bankswitching

 

 

 

KERNEL_LINES = 178*76/64 ; warning: not all values will work

OVERSCAN_LINES = 128+33*76/64 ; again, not all values work

C_function = FETCHER_BEGIN

CcodeData = C_function + 4

playerpointers = CcodeData + RAMcopylength

P1GFX = playerpointers + 38

P1COLOR = P1GFX + 256

P0GFX = P1COLOR + 256

P0COLOR = P0GFX + 256

PF1L = P0COLOR + 256

PF2L = PF1L + 256

PF1R = PF2L + 256

PF2R = PF1R + 256

PFCOLS = PF2R + 256

JUMPTABLELO = PFCOLS + 256

JUMPTABLEHI = JUMPTABLELO + 12

P1HMP = JUMPTABLEHI + 12

P1SKIP = P1HMP + 13

NUSIZREFP = P1SKIP + 12

scoredata = NUSIZREFP + 12

BKCOLS = scoredata + 96

STACKbegin = BKCOLS + 256

USERSTACK = STACKbegin + 256 ; stack starts here and goes down!!!!

[RevEng]

The RAMcopy memory is just used for some sprite-ordering kernel prep. I don't see it tied to any bB functions.

 

I do see some apparently broken code for pfscores. If you enable it as-is right now, it will mess up the 6th score character. Maybe that's what batari was referring to.