Zipplet's Stuff

The zipNES 0.2.x rewrite is getting somewhere. I now have a functional NES system bus and CPU core attached to it. Different types of memory chunks in the address space have been implemented and this works much better than in zipNES 0.1 which used blocks of IF statements to check the type of memory being accessed. I use a very fast method now involving pointers and jump tables.

I probably wont get much more done until tomorrow as I'm with my girlfriend today, but so far I'm pleased with the progress!

Edit: Heres some proof I have it doing something:


This shows a CPU execution trace from cold reset. You can see 2 bus reads at the beginning when the CPU reads the reset vector. Then, I force the CPU program counter register to $0000 to make it execute uninitialised (garbage) work ram. The 3rd bus read is the first opcode fetch, and from there you can see it running.

The trace format is fairly simple:
r (read) address = byte read
w (write) address = byte written
exe (location) = opcode fetched [register dump before executing opcode]

Edited on Sat, 1st Jan 2011 at 12:43 UTC

Happy new year to you all!

Hope you have a productive and interesting year. I'm currently working on zipNES, maybe this time I will actually get around to releasing something?

Hi all,

When I created this site I never imagined I'd get even 100,000 pageviews - let alone 300K!
I seem to average 300-400 per day, which isn't too bad considering I don't have an awful lot of content on here apart from my electronics projects.

I have been getting a lot of feedback (via email) about my Megadrive modifications from those of you that are attempting the mod or asking for more information. I can say that I will have instructions for the Megadrive 2 soon, and a firmware update for the Megadrive 1 mod.

I will also be putting up some details on adding RCA jacks to the Megadrive (both models) to allow you to use standard easy to obtain cables to hook up to your TV.

Please feel free to email me if you have any questions or just want to tell me about your mods - pictures are welcome! With permission I may put up pictures of other peoples attempts at the mods.

LightX has now been signed off as ready to use. Work on the 'project' can begin

Well, it began a while ago but it can begin properly from now!

A long time ago I wrote a multimedia API for Delphi - LightX. I used it in a couple of game projects that never got off the ground for various reasons.

A month ago I decided to bring LightX up to standard, which means getting it to run in Delphi 2010. After looking at the code I decided it would be better to rewrite LightX in a better way. This rewrite turned out to be quite simple in some places as I could copy across functions that worked well and modify them for Delphi 2010 compatibility, but I did a lot of refactoring and some improvements.

The result? LightX now works very well with Delphi 2010. I also added the ability for full hardware acceleration to be added easily at a later date - that came with the refactoring I did.

The technical bit - only interesting for programmers:
Both the old and new LightX graphics classes had a base class that implemented abstract methods for all of the drawing methods. The difference is that the old LightX software rendering engine was a fully implemented class that used a library called gfxout to display the output and it was impossible to descend the software engine and add hardware acceleration - any acceleration would have to be completely written from scratch and not use any part of the software rendering engine.

The new LightX implements the software rendering engine as a seperate class, allowing hardware acceleration to be easily added at any point by descending from the class, and in steps. Say I wanted to add full Direct3D acceleration. I could start by implementing video RAM surfaces and basic tile drawing in hardware. The LightX software rendering engine would be used for all other drawing calls. This means I can even support functions like Rotozoom on hardware that does not support it, because the software engine takes over when the hardware does not support something. Win-win!

Other benefits of breaking everything up include the ability to - theoretically - have LightX graphics working on the Nintendo DS very easily. I would only need to write a simple output layer and use the software rendering engine - as the 2D core on the DS cannot do all of the things that LightX can especially with large/irregular surface sizes. However, I could make it use the 2D core acceleration where possible. Fun possibilities.

I need to implement the Unified Application Window which will allow game code to compile on any supported platform with *zero* - yes ZERO code changes.

But for now, LightX is almost finished, and ready to use in a game. What game? That would be telling.

I thought I'd let you all know what I've been up to. I took a small break from my hobby stuff last month to play through some DS games and socialise. As of a week ago I have been working on Delphi graphics engine stuff in preparation for LightX and other projects needing it (e.g. zipNES). Direct3D is now supported so my games will run under Windows 7 as and when I have releases.

No, I am not going to even hint towards what I am working on, but it is big. Very big. It will take a huge amount of time and effort. It will be worth the wait and probably surprise people. It has been in the pipeline for about 12 years (is that right Tomatzu?) and it is now finally possible to bring the plan into action.

The only thing I will reveal is I am working on this project with Tomatzu (you may know him as Koretetsu) - and no, he wont tell you what it is either

Recently I switched to Delphi 2010 and noticed the sudden increase in output executable size. I spent a short while researching the problem and have put together an article with tips and tricks you can use to get the smallest possible executable out of Delphi 2010.

Shrinking large Delphi 2010 executables - removing RTTI properly

While it does not matter for most projects it does for some - and I hope the article helps those people for whom it matters.

I've just finished putting together an alarm system for my room with a difference - a set of RF keyfobs using the Keeloq protocol are used to arm/disarm and control 2 extra relays (for room lights or so). It proved to be a nice experiment with RF stuff that's also useful

I'll be putting up the schematic/code soon - it's a mess but I'll do it anyway. When I do, you can be sure I'll post the addition to the site news as usual.

I am currently modding a friends megadrive - and taking step by step pictures as I go. Once I've done that I need to draw up a schematic. At that time I will update the megadrive mod page with all of the information needed for you to mod your own megadrive along with a step by step guide.

Stay tuned.

I have added a project to the electronics section. It is an LED driver I built a few months ago that is designed for use with 12V LED strip lights. See the project here. The design is very simple but very efficient