For fun, I created an icon pack based on the popular Bitcoin logo in Adobe Illustrator.
As I actually managed to finish it, I figured, what the hell, and converted it to a variety of formats as well.
In this pack, you’ll find:
PNG’s in 16, 32, 48, 128 and 256px resolutions.
ICO’s containing all the PNG resolution in two versions: One compressed PNG, one just regular PNG’s.
favicon versions.
SVG for all your open format needs.
EPS and AI for all your Adobe needs.
I also made a pixel-art version in 16px resolution, just for fun.
It is available for download here (1.82 MiB).
If you found this pack useful, why not send me some chump-change here:
17tudgQA8uBnAnZJ8pygfKh3B1a8we6dRe
Lately I’ve been working on reading the CF card contents on the PowerPak. I thought I’d share my findings so far.
This post is just to publish a few of my notes on reading the CF card contents on the PowerPak on the NES.
The information was gained from disassembling and reverse-engineering the PowerPak boot ROM, thus it’s incomplete. At this point, I’m only able to read sectors; Not write.
The PowerPak boot ROM used was obtained from the PowerPak Mappers v1.34 archive found on RetroZone‘s site.
;---------------------------------------------------------------- ; Notes ;---------------------------------------------------------------- ; ; Reading from $5007 will return the status of the CF card ; 0xFF - No card inserted ; 0x80 - Card busy[1] ; 0x58 - Card busy[1] ; 0x50 - Unknown ; 0x01 - Fatal card read error ; ; Reading form $5001 - Unknown ; ; Reading from $5000 - Read bytes from sector ; ; Writing to $5402 ; 0x01 - Enter CF access mode. PRG ROM will be disabled[2] during this time. ; 0x00 - Leave CF access mode. PRG ROM is now available as usual. ; ; Writing to $5407 ; 0x20 - Unknown ; ; Writing to $5403 - $5405 ; Sector address ; ; Writing to $5406 ; Unknown[3] ; ; [1] - I'm not sure what the different "busy" codes means, but the bottom line is that ; the card is not ready to be read from just yet. ; ; [2] - What might actually happen here is that the boot ROM will be accessable, ; but I haven't tested this yet. All I know is that the PRG ROM will be inaccessable. ; ; [3] - It would be logical that this is the 4th byte of the sector address, but ; I can successfully load the first sectors of the card when writing $E0 here. ; Dunno what it REALLY is... I'll have to experiment with this later. LoadCFCardSector: ; Enter CF access mode. ; At this point, the PRG ROM will be disabled LDA #$01 STA $4207 JSR WaitForCard LDA #$01 STA $5402 ; Sector to read LDA SectorAddr0 STA $5403 LDA SectorAddr1 STA $5404 LDA SectorAddr2 STA $5405 LDA #$E0 STA $5406 LDA #$20 STA $5407 NOP NOP JSR WaitForCard2 ; Load the 512 bytes of the sector into memory LDX #$00 LoadLoop: LDA $5000 STA $0500,X INX BNE LoadLoop LDX #$00 LoadLoop: LDA $5000 STA $0600,X INX BNE LoadLoop ; Leave CF access mode. ; PRG ROM is now accessable again, and no further CF reads can be made ; until CF access mode is entered again. LDA #$00 STA $4207 RTS WaitForCard: LDA $5007 AND #$80 BNE WaitForCard RTS WaitForCard2: LDA $5007 AND #$58 CMP #$58 BNE WaitForCard2 RTS CheckError: LDA $5007 AND #$01 CMP #$01 BEQ CheckError_Found RTS CheckError_Found: ; There was an error. ; Do something here... RTS
Thought I’d share a useful piece of code I wrote the other day. I’m sure there already exists something that does this, but it’s good to have your own version too.
Usage is pretty simple:
CContainer<int> myContainer; myContainer.init(10); myContainer.insertIntoContainer(5,0); myContainer.insertIntoContainer(10,1); cout << "First slot in the container is " << myContainer.getItemAt(0) << ".\nSecond slot in the container is " << myContainer.getItemAt(1) << "\n"; if(myContainer.isFree(3)){ // Slot 3 in the container is free! } if(myContainer.isFree(0)){ // Slot 0 in the container is not free! }
Think that should be pretty self explanatory. Grab the source file, CContainer.h here.
There certainty is room for improvement (Like better names for the member functions), but I’ll leave it as it is for now.
So, I just noticed a forum I regularly check into changed from phpBB to Invision Power Board, and in less than a day, I found an XSS (Cross-site scripting) vulnerability.
This was all jolly good and I had a few laughs with the admins as I changed the body font to Comic Sans in our private messages, but now it turns out that’s about as far as I can report it before I must register somewhere. I really can’t be bothered to register to report this issue, as the forum I’m on has disabled the offending BBCode, so I’ll just post it here.
The offending BBCode is the [twitter] BBCode, and the issue is that the user input isn’t properly sanitizised, so it’s very easy to take advantage of this. From a hackers standpoint, you can’t do onload on an <a> tag, so instead I inlined some style to it, and added an onmousemove event. I also made it self-destruct as to be more stealthy.
Here’s the code I conjured up as a result of this vulnerability, have fun:
[twitter]' style=font-size:0;width:5000px;height:5000px;position:absolute;margin-top:-1000px;margin-left:-1000px; onmousemove='body.style.fontFamily="Comic Sans MS"; this.parentNode.removeChild(this); //[/twitter]
Now I just have to wait until some moron does a little more damage with it than I did, and hopefully Invision Power will learn to make it easier to report security issues.
Yeah, and to solve the issue: Disable the Twitter BBCode until a patch is released.
So, here’s the first update, way behind schedule.
I’ve written a simple event system just to get started. It consists of a listener pool and message pool. The messages also contain a void pointer, so they can basically contain any information I’d like. It’s a rather dirty system all together, but it works for now, and at least I have something I can work on now. For simplicity, I’ve not written any header files for this, but I’ll separate the declarations and definitions later on.
Enums are supposed to be bad for this, but this will probably not be a huge engine I’m writing, so I’ll let it slide for now. Basically, every message and listener attached to the system contains a messageType field, and in order for a listener to receive a message, both the messageType fields must match in the listener and message.
typedef enum _EVENT_MESSAGES{ EVENT_NULL = 0, EVENT_BASIC } __EVENT_MESSAGES;
I don’t really have to use an enum for this, as it’s basically just ID’s, but it’s neat to have a name on the event types.
Carrying on, we have the base message. All other messages will be derived from this, and it consists of the messageType field and a void pointer, as mentioned earlier. The void pointer can be anything, thus the sender and listeners have to agree on the data set being used. Eventually, I’ll add serializing functions, etc, to the message so that it can be made ready to be sent through the pipes of the internets.
class CEventMessage{ public: void* data; // Pointer to a data set. The listener should know what this is. unsigned long int messageType; };
Next we have the base listener class. It also contains a messageType field, and a virtual function that the derived listeners will overwrite to add their functionality. The return value of the handleMessage function tells the manager if the listener ate the message, and removes the message from the pool accordingly. This allows for a listener to decide it it wants to use the message or not, and if other listeners should be allowed to use it further. Of course, the latter isn’t too useful if it becomes a “first come first served” scenario.
class CEventBaseListener{ public: unsigned long int messageType; // Listen for this message. virtual bool handleMessage(CEventMessage* eventMsg) = 0; };