JBit 1.4.0 preview

2011-05-29
2013-05-30
  • A preview of JBit 1.4.0 is available here:

    http://jbit.sourceforge.net/files/JBit2F_140A.jar

    If this causes any problems, you can get the previous version here:

    http://jbit.sourceforge.net/files/JBit2F_132.jar

    Both include the Paint and the FileIO modules.

    1. TONE / VIBRA SUPPORT

    There are new requests for simple tone generation and vibra. See the new "effects" demo. In theory, the requests should be non-blocking (e.g. in the "effects" demo, the screen update should not slow down), but in practice this varies from phone to phone.

    FXTONE(40) t, tone, vol
    FXVIBRA(41) t
    

    Where:
    t: time in 10ms ticks (e.g. 20 => 200ms)
    tone: 0-127; quality varies a lot from phone to phone and is usually quite low (values 50-100 seem to work best)
    vol: 0-100

    In theory, flashing the backlight is supported too, but on the few phones that I've tried, at best it didn't work. On a phone (Motorola V360) it even blanked the screen forcing you to restart JBit. I left the functionality in because it's only a few bytes of code and it might work on some phones, but I suggest you NOT to use it if you're going to redistribute your programs.

    FXFLASH(42) t
    

    2. BREAKPOINTS, NEXT AND STEP OUT

    There are some improvements on the Monitor (debugger). The idea was get the most benefit with the least amount of code (i.e. below 1K).

    The Monitor has now minimal support for ONE breakpoint. The breakpoint is not saved with the program. You can set it from the Editor, and set/unset it from the Monitor. If you insert/delete some code, resize the program, load a new program, etc… the breakpoint is not updated.

    New monitor keys:

    7: NEXT. Unlike step, next doesn't follow subroutines, so if you are on a JSR instruction, the program continues until it reaches the next line.

    9: STEP OUT. The program continues until it's out of the current subroutine.

    Using the new features (i.e. breakpoint, next and step out) causes the CPU to slow down. Here is some idea of the slow down. On a Sony Ericsson K550i (a very fast phone), this is the timing for the "cpubm" demo:

    normal: 6.50s
    code break point: 8.40s
    step out: 8.40s
    step out + code break point: 9.20s

    Note that the "cpubm" demo is the worst case scenario, most programs should not be CPU-bound.

     
  • Back at SourceForge at last! Hi, Emanuele! I've tried 1.4.0. It would work fine, but you wrote "40-42" instead of "60-62". I tried to use 40, but failed. Well, I had a problem. After 30 FXTONE requests, the request stops working. It happens in the "effects" demo and my "Bleep" note counter program (now uploaded). But all-in-all, tone and vibrate works. Oops, haven't tried flash-be right back!

     
  • Funny. I got it wrong. By "60-62," I meant "64-66." Flash works if I debug it (right after STA 2:4), but the light won't turn on (unless I press a key). Flash DOES NOT work when I run the program. I wonder, JBit is a virtual machine (like Java), right? So can I make an OS using JBit's CPU?

     
  • Yes, I meant 64-66. Without noticing, I cut and pasted the requests from a place where values are written in hexadecimal.

    The FX requests are in fact very unreliable, and how/if they work depends mostly on the phone you have. They are straight mappings into the following Java calls:

    display.flashBacklight(t);
    display.vibrate(t);
    Manager.playTone(tone, t, vol);
    

    So no much JBit can (or should) do. My view is that, since they are so cheap to implement, JBit is better with than without them. However, in general I would suggest anyone to find out what works on his phone, but avoid using it in public code.

    FXVIBRA is probably the most supported, but still the feeling you get varies from phone to phone.

    For FXFLASH, you might try to issue a FXFLASH 0 (maybe after a few 2:18). Since FXFLASH usually doesn't work, I guess they really meant it for you to use it on monochrome phones only.

    The right solution to music/sound of course would be a proper MIDI encoder and some form of WAV synthetizer. My view right now is that it would be too much effort and too much code. Support would also vary from phone to phone.

    I suppose you could write something based on the concepts you study in OS classes. If you do, just treat it like a learning experience and don't expect anything useful to come out of it. Studying and praticing data structures (lists, trees, graphs, etc…) seems a better use of your time to me. It's a lot harder and won't give you much to show for it, though.

    For good flow and immediate rewards, polishing a very simple game is probably the best that JBit has to offer. I mean: intro screen, in-game instructions, smooth animations, varied graphics, etc… Mantaining a single code base for a longer period of time would also teach you a lot about good coding practices.

     
  • Bleep (now in the gallery) works indefinitely on a Sony Ericsson K550i. One idea could be to try to repeat 2:18 a few times (with normal frame rate, 1 time = 100ms) to make sure that you play a new note only after the last one has finished.

     
  • Yeah, that's what I thought, that it was my phone's problem. The vibrate works indefinitely for me, too. Well, if that's that, I see no problem/bugs in JBit. The new Debugger features are nice, and definitely a huge improvement. Thanks for making such a great software again.

    As for "well-polished" games, I'm trying to develop the "Snake" game. It should have smooth animation and well-detailed colored graphics. But I always get into trouble while coding it, and I started from scratch several times. But I'll make it… in time.

    P.S.: Used Puppy Linux on a computer to post this! SourceForge looks nice on a computer, unlike on my phone…

     
  • Well, I don't think Snake is very simple at all and how you store the snake is crucial. As usual, there isn't a right way to do it. Here's my two cents. Of course, if you've already committed to something that works, please ignore my advice.

    A plain array with the head (or the tail) at index 0 is probably too slow (you have to move every element at each step). A list is probably overkill (you don't need to add/remove elements in the middle) and a bit too complex to implement (you have no malloc/free, so you have to keep track of the free cells). A circular array is probably the easiest way and, if you limit the length of the snake to less than 256, it's also simple in 6502 (if not, you'll have to use the (n),y address mode for pointers).

    The most efficient way is probably to use the IO tile memory, but it might be the most involved in terms of logic. You can point to the head and the tail with two pairs of coordinates. That's all you need to know. The cells for the head/tail need 4 directions each (UP, DOWN, LEFT, RIGHT), while the cells of the body need 6 directions each (HORIZ, VERT, UP+LEFT, UP+RIGHT, LEFT+DOWN, RIGHT+DOWN), or maybe 12 if you want an enlarged body for when the sanke eats the fruit. At each step you only need to work on the head, the next cell (found by the direction of the head), the tail and last cell of the body (found by the direction of the tail).

    Anyway, good luck. If you manage to finish it, it's something you should really be proud of.

     
  • Hi. I'm late. I got kicked out (almost literally) of a computer café for using a Puppy Linux LiveCD; they thought that I was virus-ing their computers. I'm so offended that I can curse them right now: "Damn YOU and your crappy 256MB 400MHz computers to HELL!"! I'm sorry for saying that, but I got to release some tension. Okay, I'm back to Windows (-:

    I decided to store the snake on zero-page, using X index as the pointer to the tail, and Y index for the head, but after reading your suggestions, I think my decision was bad. I mean, what fun is a snake that can only be up to 256 segments long? So I decided that I will just use the IO tile memory for determining the tail's direction, and I already got a good idea on how to code that (-; But I really don't know when I'll finish it-school has started and 4th year high school (after that, it's College!) is really strict. By the way, if the job I want is to just sit in front of a computer all day (almost) and program/code something, then I get paid for my code (in short, I want to be a software programmer), what course do I get? Is Computer Science appropriate? Thanks, and have a great day!

     
  • Oh, just to tell you, I plan of writing a C or C++ (most probably C++) JBit Emulator. Now, if I just know how to access individual bytes in a file………..

     
  • Sorry to hear about your misfortunes at the Internet Café..

    About Snake. It's all right, doing well at your school is more important.

    I think that the best way for you to get a job as a software programmer depends on the job market in the Philippines. I can only advise you to ask someone more local. Computer Science in theory is mostly applied math and not much about programming (but I wouldn't accept labels at face value; doing some research on what are the subjects they actually teach is a good idea anyway).  Something else you might want to check is Software Engineering. Another route is to go to study something else altogether (e.g. Finance, Biology, etc…) and practice/study programming on your own.