Jump to content
IGNORED

Next version of bB


batari

Recommended Posts

I think I've read somewhere here where it was being talked about bB.v11d causing compile issues and that using bB.v11c resolved them for now.

This reminds me - did v.11d fix your compile issues you had earlier with extra statements being added to if-thens? I had to guess at what the issue might be and I changed two things in keywords.c, but one of them caused issues with other people's code, so I've reverted that one. If your issue is still there, I may just revert both.
  • Like 2
Link to comment
Share on other sites

So try what I've attached below, bB.v11c + updated DPCplus.arm + custom2.bin update. No Visual Batari included, just replace your existing Atari2600\bB folder with the contents of this one.

Thanks, that works. No more crashing, but the score bounces when the screen is scrolled. One of the files in link below used to get rid of the bounce:

 

http://www.atariage.com/forums/topic/133529-updated-bb-files-to-download/

 

I'm just not sure if we can use any of those files anymore since bB has changed.

 

 

Here's a related post that you might want to check out:

 

http://www.atariage.com/forums/topic/73160-bug-report-thread/page__st__125__p__1517363#entry1517363

 

 

After looking back, it seems that std_kernel.asm is what we need to look at for fixing the score jitter/bounce. It was fixed at one time, but now the latest version of std_kernel.asm seems to be missing the score jitter fix.

 

I compared the std_kernel.asm files using WinMerge, but I don't know enough about asm to see where the problem might be.

Edited by Random Terrain
Link to comment
Share on other sites

Here is a new 2600basic.exe with the troublesome change reverted.

 

Please let me know if this still fixes issues while not crashing with vbB.

 

If it does work, if you guys want to create another archive with all the latest bB and vbB files, that will be good. What I want to do is create an automated Windows installer including all of these files as admittedly the current way to get a working, up-to-date version of bB running is a bit clunky.

bb11d_2600basic.zip

Link to comment
Share on other sites

After looking back, it seems that std_kernel.asm is what we need to look at for fixing the score jitter/bounce. It was fixed at one time, but now the latest version of std_kernel.asm seems to be missing the score jitter fix.

 

I compared the std_kernel.asm files using WinMerge, but I don't know enough about asm to see where the problem might be.

Here's an example of the score bounce:

 

scrolling_test_2011y_08m_09d_0251t.bin

 

 

scrolling_test_2011y_08m_09d_0251t.bas

Link to comment
Share on other sites

I have to change score color often in my program but if I use

scorecolors:
$0A
$0A
$0A
$0A
$0A
$0A
$0A
$0A
end

more than once the program doesn't compile.

* Would it be possible to include support for collisions between missile0/1 and a virtual sprite?

* If we aren't using the playfield pixels in our program, is there a way to recover that memory for other uses?

* I noticed that when we use the pfscore option, the pfscore2 bits are mirrored on either side of the score. Not sure if this is a bug or not.

Will it be possible to use pfscore1 as before?

Link to comment
Share on other sites

  • 2 weeks later...

Hey Batari,

 

This is huge, I've just skimmed it, but I need to read it over complete. I've been meaning to re-write my game Atomic Meltdown, and from the looks of this, I now can and add all the features that weren't there before.

 

I need to refresh myself on my BatariBasic!!!

 

-Disjaukifa

Link to comment
Share on other sites

Here is a new 2600basic.exe with the troublesome change reverted.

 

Please let me know if this still fixes issues while not crashing with vbB.

 

If it does work, if you guys want to create another archive with all the latest bB and vbB files, that will be good. What I want to do is create an automated Windows installer including all of these files as admittedly the current way to get a working, up-to-date version of bB running is a bit clunky.

 

Hey Batari,

 

Can we get a Mac OS X build of this?

 

Thanks

Disjaukifa

Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...

Well, if anybody knows the read addresses for the playfield then we could make our own pfread routines as a temporary measure until an official routine is made.

 

The DPC+ Demo seems to have a clue in DPCPlus.h. I don't have enough assembly knowledge to see how it's implemented in DPCPlus.asm.

http://www.atariage.com/forums/topic/163495-harmony-dpc-programming/

 


;----------------------------------------
; Data Fetcher
;----------------------------------------
; There are 8 Data Fetchers which are used to access data stored in the Display
; Data bank.  Before using, you must point the Data Fetcher at the data to read
; via DFxLOW and DFxHI.  After each read the Data Fetcher will update to point
; to the next byte of data to return.
;
; psuedo code* to point Data Fetcher 1 to the color data
;    lda #<(ColorDataPosition - HowFarDownScreen)
;    sta DF1LOW
;    lda #>(ColorDataPosition - HowFarDownScreen)
;    sta DF1HI
;    ....
; then in the kernel read the Data Fetcher and update the color, takes 7 cycles
;    LDA DF1DATA
;    STA COLUP0
;
; * see DPCplus.asm for actual code
;----------------------------------------
DF0DATA	   DS 1    ; $08
DF1DATA	   DS 1    ; $09
DF2DATA	   DS 1    ; $0A
DF3DATA	   DS 1    ; $0B
DF4DATA	   DS 1    ; $0C
DF5DATA	   DS 1    ; $0D
DF6DATA	   DS 1    ; $0E
DF7DATA	   DS 1    ; $0F

Link to comment
Share on other sites

  • 5 months later...

Is the msdpc.bas still working for people?

Is it time for another semi official release of bB with all of the random fixes already in there?

 

I get this:

Compile started at 6/8/2012 9:01:50 AM
Compiling C:\bB11\msdpc.bas
DASM V2.20.07, Macro Assembler (C)1988-2003
free ram: 7
$1ae1
  bytes of ROM space left in bank 1
--> HMdiv 1a41				  
  bytes of ROM space left in bank 2
  bytes of ROM space left in bank 3
  bytes of ROM space left in bank 4
  bytes of ROM space left in bank 5
  bytes of ROM space left in bank 6
$d1a0
  bytes of ROM space left in graphics bank
free ram: 7
$1ae1
  854 bytes of ROM space left in bank 1
  2960 bytes of ROM space left in bank 2
  3923 bytes of ROM space left in bank 3
  3923 bytes of ROM space left in bank 4
  3923 bytes of ROM space left in bank 5
  3923 bytes of ROM space left in bank 6
$d1a0
  3329 bytes of ROM space left in graphics bank
free ram: 7
  2960 bytes of ROM space left in bank 2
  3923 bytes of ROM space left in bank 3
  3923 bytes of ROM space left in bank 4
  3923 bytes of ROM space left in bank 5
  3923 bytes of ROM space left in bank 6
$d1a0
  3329 bytes of ROM space left in graphics bank
free ram: 7
  2960 bytes of ROM space left in bank 2
  3923 bytes of ROM space left in bank 3
  3923 bytes of ROM space left in bank 4
  3923 bytes of ROM space left in bank 5
  3923 bytes of ROM space left in bank 6
$d1a0
  3329 bytes of ROM space left in graphics bank
--- Unresolved Symbol List

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

Link to comment
Share on other sites

  • 2 months later...

Hi!

 

I have a bug report about missile color and a question regarding collision detection for bB v1.1d.

 

I'm playing around with the missiles now and there's no way to control the missile color.

I've added COLUM0 and COLUM1 variables to (sort of) control missile color. The colors won't work while the missile is on the same scanline as a player but it should work fine otherwise.

 

This patch has three files: DPCstartup.asm, DPCplusbB.h and custom/bin/custom2.bin. Unzip into the includes folder.

 

Some of this isn't tested very well so let me know if there are any issues.

 

 

I've noticed that the missile default color works as expected for COLUM1 and COLUM0 on the scanlines that come after their respective sprites. But for COLUM0, the colors will default to 0 (black) on non-player0 scanlines that come before it. I've included a small program to demonstrate this (move joystick up and down to change the vertical position of the sprites.

 

DPCMissileColor.bas.bin

DPCMissileColor.bas

 

 

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:

 

...

 

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.

 

What value is returned in temp4 if two virtual sprites are colliding with the playfield after the same drawscreen? This happens fairly often in a program I am trying to write, and whenever it does, temp4 doesn't seem to return any of the virtual players y-coordinates (nor "0", nor "255"). I would try to trace the address myself, but unfortunately I am a novice at Stella Debugger. Is it possible to write a post-collision statement in batari basic that accounts when two or more virtual sprites are colliding with the background simultaneously (i.e. "if temp4 = [some value] then..."

 

Thanks!

Link to comment
Share on other sites

  • 2 months later...
  • 2 weeks later...

I started off around two years ago when Batari had just released 1.1 so I have no experience with the original bB, or what is different.

That said, I think I see something wrong.

That template Scumsoft has in that thread, and that VBB uses, shows:

 

 ; *****************************************************

 ; * BANK 6

 ; *****************************************************

 bank 6

 rem temp1 = temp1 not required here as this bank is for graphics only

 rem However I have placed my TitleScreen here with no apparent consequences

 

But Bank 6 is a full empty bank that I am using like Banks 2 thru 5! (Bank 1 is almost full with Basic kernel)

There seems to be a bank AFTER that for graphics.

Am I crazy?

4K x 6 banks is 24K plus 4K graphics 28K ???

4K x 7 banks is 28K plus 4K graphics = 32K

Link to comment
Share on other sites

6 x 4k + graphics 4k + ARM bankswitching code = 32K

 

...is how I understand it.

You are right.

It is just a Visual batari Basic template error.

Sorry, twice now I've been confused and thought an error was with basic when it really was in the visual basic editor.

See the above template says bank 6 is for graphics only, but the compiler output shows a full bank:

post-29575-0-80198400-1354335483_thumb.jpg

Link to comment
Share on other sites

See also Post 268, this thread.

In vbB, choose New Item, DPC+ Kernel, and open the project.

You get a template.

It ends with:

; *****************************************************

; * BANK 6

; *****************************************************

bank 6

rem temp1 = temp1 not required here as this bank is for graphics only

rem However I have placed my TitleScreen here with no apparent consequences

 

I am pointing out this is wrong.

temp1 = temp1 is required here, and it is a full bank.

 

It is not just for graphics only.

The graphics bank is after bank 6's 4K bank.

Link to comment
Share on other sites

  • 3 months later...

DPC+ bug report... the 1.1d version of the DPCplus_kernel has a timing error if you don't use "set kernel_options collision...".

 

 lda #<DF3FRACDATA ;53
 sta PF1 ; 56
ifnconst DPC_kernel_options
 ;sleep 8 ; timing is off - results in a garbled screen
 sleep 5  ; this is better
else
 bit DPC_kernel_options
 if (DPC_kernel_options > $3F)

Link to comment
Share on other sites

  • 2 weeks later...

Another 1.1d DPC+ bug report... the COLUM0 feature only works when missile0 is below player0's y position, not above. This is a problem when the bB coder changes the player0 y position to be off-screen.

 

To fix this it takes changes to both the main.c ARM code and the DPC+ 6507 kernel...

 

; fix for DPCplus_kernel.asm

; display COLORs from top of screen, not the top of the sprite...
; sec ; not needed anymore
lda #<(P0COLOR-1)
; sbc player0y
sta DF0LOW
sta temp2
lda #>(P0COLOR-1)
; sbc #0
sta DF0HI

 

 // change main.c...
 // copy player color list to exact position in color data
 // instead of just the top of the data area...
/*
 my_memcpy(queue+(dfhigh(0)<<+dflow(0),
           flashdata+(RIOT[player0color+1]<<+RIOT[player0color], 0,
           RIOT[player0height]);
*/

 my_memcpy(queue+(dfhigh(0)<<+dflow(0)+RIOT[player0y],
           flashdata+(RIOT[player0color+1]<<+RIOT[player0color], 0,
           RIOT[player0height]);

 

Tested and working fine.

  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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