A reboot was needed. I rewrote most of the code. The game is no longer called “The Muni Race”. Instead it is called “The Uni Games” since it will have more than one event (think of “Summer Games” but for unicycles. UNICON basically). The game will have a more-retro look and feel than before. It will only use PETSCII chars, plus sprites. No redefined characters, no bitmaps. Pure PETSCII. Pure retro effects.
New version, new features. Download Mac: vchar64-0.0.12.dmg.zip Win32: vchar64-0.0.12.win32.zip Changes [NEW] Koala Import: supports importing subregions. Useful when 256 chars are not enough to import the whole bitmap [NEW] Added unknown font. Ripped from here [NEW] VICE snapshot import: Default charset address is the one that was used at the moment the snapshot was taken [NEW] Save/Export: Plays one beep on success, two beeps on error [NEW] Main Window: Status Bar shows the coordinates of the different widgets [BUGFIX] Export: shows correct extension when browsing file [BUGFIX] VICE/Koala Import: sets the name of the imported file in the tab [BUGFIX] Koala Import: detects duplicates chars, making the conversion smaller
VChar64 v0.0.11 was released. Win32: vchar64-0.0.11.win32.zip Mac: vchar64-0.0.11.dmg.zip Source code: github It includes several bug fixes and some important new features like: Koala import support Map support Export to Assembly Full Changelog here.
Let’s crack a simple game. If you are not familiar with Radare, read Part I first. Creating and opening a VICE Snapshot file Let’s crack BC’s Quest For Tires since its copy-protection is easy to bypass. Unzip this file: http://tapes.c64.no/tapes/BCsQuestForTires.zip Open the tap file with VICE (the most popular Commodore 64 emulator), and.. …the game has some kind of copy-protection. If we enter invalid codes, we won’t be able to play the game. Since Radare supports VICE Snapshot File format, we can save an snapshot of the game, and analyze it with Radare. In VICE, go to the menu, Snapshot -> Save Snapshot Image… If we select “Save ROMs”, then the BASIC ROM and the KERNAL ROM will be saved inside the Snapshot file, and will be included as Radare sections. Radare VICE Snapshot File (VSF) support lets us inspect: The 64k RAM of the computer at the moment the snapshot was saved The BASIC and KERNAL ROMs in case they were saved. To open a VSF file, just pass the VSF file as the first argument: $ r2 bc_copy_protection_screen.vsf [0x00005689]> 0x00005689 is the PC (program counter) at the moment the snapshot was saved.
Radare is an open source portable reversing framework that can do many things, among those things it can disassemble 6502 code. Download and install radare First, download radare from github. You need a recent version in order to disassemble 6502 code. And then install it by running sys/install.sh (or sys/user.sh for local installation): $ git clone https://github.com/radare/radare2.git $ cd radare2 $ ./sys/install.sh Loading a c64 .prg Radare has many command line options. But in order to load 6502 programs we need just two: -a6502 to specify the 6502 architecture. -mMemoryAddress to map the file to a certain memory address. Use 2047 for “normal” programs. Usually they start at $0801 (2049), but we have to subtract 2 from the .prg header. Example: $ r2 -a6502 -m2047 mygame.prg Disassembling Radare doesn’t have a GUI, like IDA. Instead is has a powerful command line interface (think of GDB). Example: $ r2 -a6502 -m2047 musicplayer.prg [0x000007ff]> And 0x7ff (2047) is the seek address, meaning that all commands will use that address as the base address. Let’s print the first 32 bytes. ( px = print hexa): [0x000007ff]> px 32 offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x07ff 0108 0b08 3905 9e32 3036 3100 0000 78ad ....9..2061...x. 0x080f 0ddc a212 a000 b9d4 1a99 f020 c8d0 f7ce ........... .... The “2061” that we see, is part of the BASIC “SYS 2061” command that usually appears in all C64 programs. So, let’s disassemble the first 12 instructions from 2061. ( pd = print disassemble): [0x000007ff]> pd 12 @ 2061 0x0000080d 78 sei 0x0000080e ad0ddc lda 0xdc0d 0x00000811 a212 ldx #0x12 0x00000813 a000 ldy #0x00 ┌┌─> 0x00000815 b9d41a lda 0x1ad4,y ││ 0x00000818 99f020 sta 0x20f0,y ││ 0x0000081b c8 iny └──< 0x0000081c d0f7 bne 0xf7 │ 0x0000081e ce1708 dec 0x0817 │ 0x00000821 ce1a08 dec 0x081a │ 0x00000824 ca dex └─< 0x00000825 d0ee bne 0xee In case we don’t know the meaning of a certain opcode, we can print its description with ?d: [0x00000815]> ?d sei set interrupt disable status Or if we want to print the description in every disassembled line, we can do: e asm.describe=true And then disassemble again: [0x0000080e]> pd 12 @2061 0x080d 78 sei ; set interrupt disable status 0x080e ad0ddc lda 0xdc0d ; load accumulator with memory 0x0811 a212 ldx #0x12 ; load index x with memory 0x0813 a000 ldy #0x00 ; load index y with memory ┌─> 0x0815 b9d41a lda 0x1ad4,y ; load accumulator with memory │ 0x0818 99f020 sta 0x20f0,y ; store accumulator in memory │ 0x081b c8 iny ; increment index y by one └─< 0x081c d0f7 bne 0xf7 ; branch on result not zero 0x081e ce1708 dec 0x0817 ; decrement memory by one 0x0821 ce1a08 dec 0x081a ; decrement memory by one 0x0824 ca dex ; decrement index x by one 0x0825 d0ee bne 0xee ; branch on result not zero For more disassembling options just type p?
What was interesting about the Keynote: Brillo: the OS for the IoT… but but but, there were no talks about it, almost no information about it, nothing. Android Studio with C++ support: Finally :) The NDK really needs love, and having an IDE that supports it is great. Hey, even Microsoft is supporting the NDK now in VS2015. Photos is decoupled from Google+ with free unlimited storage: This is great. I’ve been using Picasa since day one and I never used Google+ to store my photos. So basically Photos is the same as Picasa, but with unlimited storage. Offline maps: Yeah Chrome Custom Tabs: Interesting alternative to present 3rd party views with the benefits of both the web and native worlds. What was not-that-interesting about the Keynote: The rest. I don’t care if Android has better permissions or not (yeah, the old permissions-model sucked, but I don’t find that news interesting). The Family section for Google Play is good, but not interesting. Android Pay, meh. etc. One thing that I liked, but was not announced on the Keynote, was Project Jacquard. They are using conductive threads and other stuff to create “smart” cloths. Something that Adafruit and Sparkfun have been doing for a while, BTW.
I’m good at software engineering, but in electronics, I’m a newbie. Nonetheless, I find electronics fascinating. Last year I did the first basic tutorials with Arduino, then I played a little bit with Raspberry Pi and CI20 (technically not really electronics). And this year, I built a very simple circuit to connect the RGBI output of my Commodore 128 to VGA… I have been using breadboard, so no soldering, no PCB, or anything like that. ...
Who has time to maintain two personal blogs ? It is even difficult to maintain just one. So what I did was to merge my unicycle ( monociclo.com.ar) blog into this one ( towp8.com). I divided them in categories: The unicycle blog is using the " unicycle" category. This blog is using the " programming" category
For the past 5 or 6 years, I used iPhones as my default phones. But a few months ago I decided to switch to Android. I tried Android devices before, but never as my default phone. At the beginning I started using a Samsung Galaxy S4 (a 2013 5" device), but later I switch to a Xiaomi MI4 (a 2014 5" device with better specs). Without further ado, this is my feedback: Launcher In case you don’t know what the launcher is, think of the shell that allows you to launch the applications. It is the first thing that appears when you turn on the phone. In a way, it defines the UX. Each phone maker customize the Android launcher according to its needs. And you can also download 3rd party launchers. This is both a good thing and a bad thing. The bad thing is that every phone maker have a different launcher, making it difficult to switch to other Android devices, since the UX is different. Google has its own launcher called Google Now Launcher, and tries hard to make sure that Android makers don’t differ too much from it, although that is not always true. Samsung, as an example, ships its phones with a launcher called TouchWiz. It doesn’t differ that much from Google Now Launcher, but its changes make it a worse phone, not a better one. Xiaomi, on the other hand, ships its phones with a completely different launcher which makes your Android device behave like an iOS device. The good thing is that you can use a different launcher if you don’t like the default one (or create your own). This as a good thing because everything that can be configured, changed or replaced is an opportunity for innovation (see below).
In Part I I described to how integrated LiquidFun with Cocos2d-x. In this part (part II) I’ll describe how to render the particles using a basic water effect. Part I uses just one glDrawArrays(GL_POINTS, 0, total); to draw the particles. And although that works to draw “particles”, it is not enough to draw “water”. Drawing “water” requires a more complex rendering algorithm, like the one used in this example. And implementing an algorithm similar that one is what this article describes. The algorithm works more or less like this: Choose a white circle and blur it. You can blur the circle at runtime Or you can blur it off-line. Create an a new frame-buffer (think of a clean off-screen buffer where you can render whatever you want) Render the particles into the newly created frame-buffer using the blurred circle Now render the frame-buffer into the main color-buffer using a threshold. The threshold could be something like this: If pixel.r < 0.1, discard the pixel (the pixel won’t be drawn) If pixel.r < 0.2, draw a blue pixel (for the border, although this is optional) else draw a white pixel (the inner part of the water) How to do it using Cocos2d-x and LiquidFun Let’s take the LFParticleSystemNode from Part I, and “evolve” it: The first thing to do is to add the “off-screen” frame-buffer into the LFParticleSystemNode class. In Cocos2d-x, the “off-screen” buffers are created with the RenderTexture class. Example: [code language=“cpp”] bool LFParticleSystemNode::init(b2ParticleSystem* particleSystem, float ratio) { … // create an off-screen frame-buffer with the size of the screen auto s = Director::getInstance()->getWinSize(); _renderTexture = cocos2d::RenderTexture::create(s.width, s.height, Texture2D::PixelFormat::RGBA8888); this->addChild(_renderTexture); _renderTexture->setAnchorPoint(Point::ANCHOR_MIDDLE); _renderTexture->setPosition(Point(s.width/2, s.height/2)); // Change the default shader. Use a the threshold shader auto program = GLProgram::createWithByteArrays(_renderTextureShaderVert, _renderTextureShaderFrag); auto programState = GLProgramState::getOrCreateWithGLProgram(program); programState->setUniformFloat(“u_threshold_discard”, 0.15); programState->setUniformFloat(“u_threshold_border”, 0.3); … } [/code] And, as mentioned earlier, the RenderTexture (the off-screen frame-buffer) needs a shader with a threshold. The threshold shader should look like the following: [code language=“cpp”] varying vec4 v_fragmentColor; varying vec2 v_texCoord; uniform float u_threshold_discard; uniform float u_threshold_border; void main() { vec4 color = v_fragmentColor * texture2D(CC_Texture0, v_texCoord); if( color.r < u_threshold_discard) // black or discard color = vec4(0,0,0,0); else if( color.r < u_threshold_border) // blue for the border color = vec4(0.2,0.2,0.9,1); else // white for the center color = vec4(1,1,1,1); gl_FragColor = color; } [/code] The values u_threshold_discard, and u_threshold_border are defined at runtime. In the example, they are set at 0.15 and 0.3 respectively. The next thing to do is, to render the particles in the RenderTexture. [code language=“cpp”]void LFParticleSystemNode::draw(Renderer *renderer, const Mat4 &transform, uint32_t transformFlags) { // tell RenderTexture to “capture” the particles _renderTexture->beginWithClear(0,0,0,0); _customCommand.init(_globalZOrder); _customCommand.func = CC_CALLBACK_0(LFParticleSystemNode::onDraw, this, transform, transformFlags); renderer->addCommand(&_customCommand); // tell RenderTexture to stop “capturing” the particles _renderTexture->end(); } [/code] The result is the following