RevEng

Really nice work! Thanks for sharing!

Here's all I got... Jump Jet Squeeze Out Blast Though Rock Rocket Jumping to Conclusions

The Empire Strikes Back (atari 2600) Conan (atari 8-bit) Star Trek (vector arcade) Star Wars (vector arcade) Tron (arcade) Jurassic Park (arcade) Spiderman 2&3 (xbox/ps2/ngc) Buffy the Vampire Slayer: Chaos Bleeds (xbox/ps2/ngc) The Hulk (xbox/ps2/ngc) Star Wars Battlefront I & II (xbox) Batman: Arkham Asylum (360/ps3)

True enough that's how it started, but even then certain bB instructions that look atomic do switch banks and jump into subroutines without the user necessarily being aware of it. (a=b/3, the pf* commands, ...). In truth the thread wasn't meant to be a definitive cycle-accurate list - just a stab at how relatively expensive certain common instructions actually were. Everybody talks about how bad non-power-of-2 divisions are, for example, but it was interesting to see the scale of the issue. Totally agreed that a definitive cycle-chart would be great, but problematic to create. You'd need at least 2 values for each operation in non-bankswitched and bankswitched binaries, then you'd need asterix exceptions for stuff like pfscroll, and all the other issues you noted. It might be better to just create a graph of relative cycle times, without a scale. or with a scale but without scale dividers. The point being it's relative expense that's being displayed. Certain operations that are highly variable (like non-power-of-2 divisions) might show a fuzzy/transparent area from the minimum cycle to maximum cycle time. My 2 cents anyway.

Similar to what SeaGtGruff is suggesting, just bracket your a=a+5 thusly... asm sed ; set decimal mode end a=a+5 asm cld ; clear decimal mode end

There's nothing wrong with the way I tested them, if you don't mind working with a margin of error. The stella method you outline is good for simple short code, but often it's more complex code you're interested in measuring. With my method, even when there are subroutines and bankswitching involved, I can get a "good enough" answer literally in a few seconds. Then I can tweak and re-time the code without having to step into subroutines and add up dozens or hundreds of opcode timings. These are the cases where our answers disagree... (the other were in my stated margin of error) RevEng: a.d=b.b+c.f : 11.52 cycles (+-1.3 cycles) SeaGtGruff: a.d=b.b+c.f : 105 cycles Comment: The discrepancy is due to a bB bug, reported in this thread and acknowledged by batari. A 8.8=4.4+8.8 should have called the library (with a bankswitch in a bankswitched binary) but it didn't. RevEng: a.d=b.e+c.c : 160.0 cycles (+-6.4 cycles) ** SeaGtGruff: a.d=b.e+c.c : 105 cycles Comment: Mine was for a bankswitched binary, so there's bank switching overhead. It was mentioned later in the thread that changing to a 4k binary changed the time to "106.6 cycles (+-4.2 cycles)". RevEng: a=b/3 : 460.8 cycles (+-12.8 cycles) SeaGtGruff: a=b/3 : 38 cycles Comment: I used a non-zero value for b to get more of a typical case, since dividing in bB is iterative, and dividing 0 by 3 is an unusually fast corner-case. Also I was bankswitching. If I use b=0 and then the non-banked answer would be 38.66 +-1.33 cycles, which agrees with your result. What does using b=128 (the value I used, IIRC) and using bankswitching add up to with your method?

If some of the arrays would be used for generating repeatable but unpredictable data, like unique scenery or enemy placement, you could probably instead use a LFSR seeded with the player position. Pitfall used this to great effect on the Atari 2600, to generate 255 unique screens with a small amount of rom. A 16-bit LFSR can produce 65535 unique values.

With the present code multiple titlescreen kernels won't work, for reasons similar to those that limit you to one bB kernel at a time. It's possible to animate an image within a titlescreen, so long as the animation takes 256 vertical lines or less. (so you could create 4 frames of a graphic 64 lines tall)

Thanks for the encouragement and kind words, Guys. Not a stupid question at all. It's possible to kludge in a data change to turn in a titlescreen into a game-over screen, but it would eat variables and might not be worth it. A minimal game-over addition could be done... but I'm not looking at taking on additional features until the official titlescreen kernel is released and the dust settles. If I do take it on, I'll also make a similarly optional "built with bB" logo screen. That alpha is the only released version so far. I'm looking at releasing the latest code in a week or two, if I can get the time to work on the docs. The data format is changing for the bitmap minikernels, so I could only recommend using the alpha if you're just playing around. If you're trying to build something you want to keep, then wait for the official release.

Just thought I'd post a teaser, to show you guys I'm still working on this... titledemo.bas.bin ...it's an advanced "color by flicker" example I'm building for the docs. I'm considering tossing out the "basic" variants of the minikernels, since the only real advantage they have over the "advanced" variants was a easier-to-read bitmap format. Based on the trouble a lot of people had with the formats, I'm thinking that isn't that big of an advantage. Reducing the number of minikernel choices seems the better choice. It's also worth noting that Philsan has posted the latest version of L.E.M, which uses the titlescreen kernel.

Not exactly what you're asking for, but I create a Makefile and let the command-line be my IDE. The present version of my Makefile handles the following commands: make #assembles the project if the files have changed make verbose #assembles the project with dasm verbosity set to 5 make run #launches the project in stella make debug #launches the project in stella, starting in the debugger make test #copies the .bin to the SD card I use in Harmony make clean #removes .bin and intermediate files make backup #creates a tarball of the directory and mails it to a gmail account Definitely recommended if you're comfortable with a command-line!

There's a syntax error on line 1634... "if c=3 then ballx=ballx+1 : bally-bally+1"

Thanks Animan! And thanks for the tip on the whitespace and indenting, RT! I do feel that your re-formatted example is easier to read.

Awesome is right. I had a good chuckle when I noticed the forum description change.

Has any body actually tried to give this a go? I'm fully expecting the answer to be "no" since it's only been out for a bit, but I figured I'd ask. I'm planning an official release of the Titlescreen Kernel in the next few weeks with docs based on these ones, since importing data for the Bitmap minikernel is pretty similar. If there's anything lacking or unclear in the docs let me know!

XOR has always been my favourite bitwise operation. XOR based sprite routines look quite neat when multiple sprites wind up overlapping each other... ...and they also get style points for using the exact same routine to draw the sprites as to erase them. Then there's the old trick of using XOR to swap the contents of 2 variables without using a temporary variable.

The bad guys are Recognizers from the Tron movie. I agree with theloon that the maze looks inspired by the Tron arcade game tanks sub-game. [edit - looks like the recognizers came out in later levels...]

You need to cut some traces and solder in some resistors. Not sure if that's what you'd consider easy or not.

No. The only thing a bB player0x: statement does is set a pointer to that particular block of graphics data. Your program doesn't actually need to be in the last bank when that happens. The best tip I can give is a general one - try to organise your code and data so the number of bank switches are minimised - because bank switching is very costly cyclewise.

:lol:

Thanks for the positive comments guys. Michael, your point (1) has been on my mind for a while too. I hate releasing stuff and watching it slide off the first page into oblivion a few weeks later. I also hate working on a project and later finding some guy did the same thing a few years back. Al keeps mentioning the file storage module that he paid for but hasn't had the time to implement. From the sounds of it, users will be able to tag uploaded files with categories and other searchable meta info. That said, having a secondary home would be good. The natural place this would a Unofficial/Contributed bB code section of batari's or RT's website. Release docs/guidelines (2) would be helpful. A start could be a README template with release info up top. E.g... name:______ release date:_____ author:______ code type: minikernel/kernel/subroutine/demo kernels tested with: standard/multisprite/none/NA I'm not sure where to take your idea beyond that. I don't have much experience writing formal docs. @theloon: I look forward to the label contest for Space Invader and its upcoming sequel "Good Touch/Bad Touch".

The irony being that you'll get to choose from a bunch of incomplete games with DLC that can no longer be downloaded. Gibson has double-crossed you!

As a spin-off from my titlescreen kernel work, I created a Bitmap Minikernel. Its already been incorporated into one game, Cliff Friedel's Passthrough, which uses it to display a logo above the score. But it also has the optional capability to display only part of a larger bitmap, depending on where the "bitmap_index" variable is pointing. This can be used for scrolling or skipping between the images being displayed. I've included some high level docs this time around too. Hopefully this will point would-be users in the right direction. All demo source, bins, and the docs... bitmapdemo.zip The docs... BitmapMinikernelHowTo.pdf The "advanced" demo screenshot, and the "advanced" bin... bitmapdemo.advanced.bin

Is the TV in "cable" input mode, and is it tuned to channel 3? (also try 2 and 4)

Stella knows Kaboom needs paddles because it has a game database. Do what RT said and your program will work.