bB with native 64k cart support - 1.1d.reveng

[Chilly Willy]

Wouldn't it be better to just have two new commands: BCD and HEX? You just use BCD, then any number of arithmetic commands, then HEX to get back to normal. BCD would just be SED and HEX would be CLD. Seems better to me.

[RevEng]

Its possible to do that with minor inline assembly, so it's still an option.

 

I thought about doing it similar to how you describe. My reason for having it affect only the immediate command is that we won't have to troubleshoot code in the forum from some guy that's unknowingly left decimal mode on. Since bB supports complex math statements, its not really a limitation.

[SeaGtGruff]

Its possible to do that with minor inline assembly, so it's still an option.

 

I thought about doing it similar to how you describe. My reason for having it affect only the immediate command is that we won't have to troubleshoot code in the forum from some guy that's unknowingly left decimal mode on. Since bB supports complex math statements, its not really a limitation.

 

And if you don't want to have to type the inline assembly, you could create macros that do it (with the macros being in assembly, of course), such that you can call the macros rather than typing the inline assembly. That might seem like a bit more trouble, but I think it should allow you to call the macros on the same line as other bB commands, such as within an "if...then" statement.

[RevEng]

I haven't really played with bB macros before, but I just tested and callmacro seems to work just fine within an if...then with other commands, even when the macro contains inline assembly.

[RevEng]

Version 15 is now in the first post.

 

DPC+ virtual sprites now wrap correctly when reflected. 12 bytes used. Code for wrapping double or quad sized virtual sprites won't fit into the existing space.

 

I'm still banging my head against the vsprite glitch.

[iesposta]

Version 15 is now in the first post.

 

DPC+ virtual sprites now wrap correctly when reflected. 12 bytes used. Code for wrapping double or quad sized virtual sprites won't fit into the existing space.

 

I'm still banging my head against the vsprite glitch.

Is the vsprite Glitch really an issue? Does it still happen when the sprites are eight lines apart?

I don't know if this will help but I remember batari Saying something like the sprites need separated three lines before they begin to flicker, and I thought it weird that it is 7, so was that 3 in a 2LK should be 6? 4 in a 2 line kernel would be 8. So maybe this glitch is something in the triggering of intelligent flicker?

Maybe that helps, prob not.

[RevEng]

It doesn't seem to happen at all if the sprites have 8 pixels of spacing. If you give them 7 pixels of spacing, then it shows up in the 9th sprite. If you give them less spacing, the glitch moves higher dramatically.

 

I don't think its a case of intelligent flicker not kicking in early enough. There's something cumulative going on, and its causing the vsprite coarse positioning to eventually happen too early. That's as far as I've nailed it, though only understanding DPC+ as far as the interface source code instructs is a hindrance.

 

Ultimately the glitch isn't a big issue, but its a blemish on an otherwise lovely piece of work. I'm not ready to surrender just yet.

[+Random Terrain]

Version 15 is now in the first post.

 

DPC+ virtual sprites now wrap correctly when reflected. 12 bytes used. Code for wrapping double or quad sized virtual sprites won't fit into the existing space.

 

I'm still banging my head against the vsprite glitch.

 

Thanks. Have you tried it with player1 through player9 not flipped? I did a quick find and replace to keep those sprites from flipping and they seem to just disappear when they touch the right side instead of smoothly moving off:

 

test_ex_dpc_13_objects_2013y_08m_31d_1100t.bin

 

test_ex_dpc_13_objects_2013y_08m_31d_1100t.bas

 

 

Also, do you know if NUSIZ0{7} = 1, NUSIZ0{6} = 0, and NUSIZ0{6} = 1 are supposed to work?

 

 

Sorry to keep giving you work.

[RevEng]

I'll check it out, and no worries on the work. Its progress of a sort.

 

Those bits don't work with NUSIZ0. Player0 can't be masked. Player0 isn't virtual, so NUSIZ0 is a real hardware register that acts the same as it does in the standard kernel.

[RevEng]

Version 16 is now in the first post.

 

Apparently in C bit shifting is higher in order of operations than a binary and. A set of brackets later and the code is now working with and without reflection.

[+Random Terrain]

Thanks. Now I can upload a new version of my example program to the bB page.

[Byte Knight]

Outstanding job on this Mike- thanks for all your hard work!

 

Now, I've just got to come up with an idea for a game...

[+Random Terrain]

My example works since hex and decimal are equivalent from 0 to 9, but your form is better for an example.

 

[edit - and yes, your dec example is equivalent to the version with inline asm.]

 

When you get a chance, check this out and see if it's OK or if it needs to be adjusted:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bcd_dec

[RevEng]

This bit from my original quote isn't quite right...

 

"For example, score = score + 100 would add 1 to the middle score digit."

 

...since any one single digit isn't in the middle. The easiest fix is to make it "digits".

 

Otherwise, it looks good!

[+Random Terrain]

This bit from my original quote isn't quite right...

 

"For example, score = score + 100 would add 1 to the middle score digit."

 

...since any one single digit isn't in the middle. The easiest fix is to make it "digits".

 

Otherwise, it looks good!

 

Just updated it. Thanks.

 

I'll get back to work on the DPC+ section later today.

[RevEng]

Version 17 is now in the first post.

With a small bit of massaging, batari's DPC+ pfscore code is now working. This operates the same as pfscore in the standard kernel.

I believe I've tracked down the source of the vertical vsprite glitch, but I don't think there's going to be much I can do about it. It appears to be the result of a cumulative rounding error, but it's an issue that's fundamental to the way the multisprite part of the kernel works, and I don't have enough bytes left to compensate for it.

If you need to stack a bunch of vsprites close together like this, you can ensure that it doesn't show up by putting them all on even or all odd rows, depending if the height of the vsprites are even or odd.

[+Random Terrain]

Thanks. I adjusted the 13 objects example program:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_13_objects

Do you know if it would be possible to add some kind of pointer to this version of bB so the programmer could select the line on the playfield where playfield: will start? Here's an example of what it might look like:

__

   playfieldpointer = 21

   playfield:
   ..XXXX....XXXX....XXXX....XXXX..
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   ..XXXX....XXXX....XXXX....XXXX..
end

[iesposta]

Thanks. I adjusted the 13 objects example program: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_13_objects Do you know if it would be possible to add some kind of pointer to this version of bB so the programmer could select the line on the playfield where playfield: will start? Here's an example of what it might look like:__

   playfieldpointer = 21

 

Yes, or tell us how to find and set the pointer.

I need a double tall PF, and a pointer to switch between the top / bottom.

[RevEng]

I took a quick look at this yesterday. Presently all of the data from playfield: gets stored as a continuous strip, and then a subroutine does DPC+ish stuff to it. So either one of these requests would take some rewriting.

 

In the next couple days I'll have a better look and see if any more flexibility can be added.

[+Gemintronic]

I think the playfieldpointer feature was used in a vertical scrolling example once. The playfield data was larger than one screen. The example seemed to adjust the value to playfieldpointer to "scroll" the screen. With that in mind I think implementing this would enable at least scrolling for the vertical plain! Something like an updated SeaGtGruffs pfhscoll routine could be used for horizontal scrolling.

[RevEng]

There is no 6507 playfieldpointer in the DPC+ playfield: memory map, so that won't work the way it used to. DPC+ playfield rom locations instead get stuffed into the DPC+ queue by the 6507, strip by strip.

 

I'm sure something can be done here to add flexibility... hopefully solely in the DPC+ kernel, instead of the ARM code. ARM code instructions take up way more rom.

[iesposta]

Ok Rev, but I can "poke" the playfield like i do in Satans Hollow:

 

i just haven't found a way to figure out the low hi yet.. I looked in the file is the compiler makes but I haven't found it yet.

 
 
  DF7LOW = 96
  DF7HI = 41
  DF7PUSH = rand
  DF7PUSH = rand
  DF7PUSH = rand
  DF7PUSH = bridge
  DF7PUSH = bridge
  DF7PUSH = bridge
  DF7PUSH = bridge
 

[RevEng]

You can do that, but that's through DPC+ functions rather than 6507 memory. To implement some of the functions the guys are talking about - like offsetting a playfield, scrolling - it would take a terrible amount of time interfacing with DPC+ queues one byte at a time.

 

It would be faster codewise if I reconfigure the pfsetup assembly and playfield: source a bit to allow for offsetting.

 

So far as what that address you're using is... The high byte more or less represents which of the data fetchers is being accessed. Higher bits of the byte are masked off, so your 41 is equivalent to 9, which does the same thing. The fetcher that's responsible for the left column of the playfield is #6, the one next to that is #7, ...

 

The low byte is basically the location of the byte within the queue, though you have to add an offset of 8 to get to the start.

 

I'm simplifying it a bit to make it digestable, because DPC+ does a bit of math pulling other values out of the address code, but that's not particularly useful. If you want the gritty details in source code, it's all in the stella DPC+ source.

 

Its worth mentioning that you don't need to worry about the addresses changing, unless DPC+ gets revised, which I don't see happening as it would break existing DPC+ games.

[+Random Terrain]

I'll just be glad if you figure out that it's possible to place playfield: data starting at any row on the screen. Then I could make a random-ish maze game using the DPC+ kernel. I'd love it if the DPC+ kernel could do something similar to this:

 

ex_random_maze_move_joystick.bin

 

(Move the joystick up, down, left, or right to change the 3 sections of the maze.)

[RevEng]

Version 18 is now in the first post.

 

Changes...

• My DPC+ pfread code had a bad bug, which is now fixed. (the test program unintentionally worked around the bug)
• COLUBK is now set to 0 prior to the DPC+ kernel running, to avoid a partial stripe of background color.
• COLUM0 is set prior to the first line pre-0 playfield line in the DPC+ kernel. If the bB program sets ENAM0 before drawscreen to enable missile display on the pre-0 line, it now displays with the correct COLUM0 color.
• multiplication by all powers-of-two uses shifting, instead of larger numbers requiring the mul8 library.

I haven't had the chance to take on any playfield offset code.