Commit Graph

6 Commits

Author SHA1 Message Date
Tim Allen 2330ed6e8c Update to release v000r04.
byuu says:

[screenshot of the Tetris title screen]

Less than fourty-eight hours after starting on this. I guess you weren't
kidding, Exophase.
2010-12-30 18:18:47 +11:00
Tim Allen 71780949b0 Update to release v000r03.
byuu says:

All 512 instructions implemented. To make debugging flags easier and to
reduce the code size, I made parent routines for all the bit-logic that
sets flags. This bumped up the speed to 3,045fps. So about 51x faster
than a real Game Boy.

I suspect the frame rate to plummet rapidly as I emulate more stuff and
try and get timings more accurate. Wild ballpark, I'd guess 300fps or
so. Not based on anything, just a made up number. I have no idea what it
will end up being.

So I still need:
* decode MMIO reads/writes
* add CPU interrupt support
* add LCD emulation (probably the hardest part)
* add PCM emulation (well, this would likely be the hardest; but it's
  not essential right now)
* debug the holy living shit out of the CPU core. Anyone want to help
  now by looking it over? :D
2010-12-30 18:18:23 +11:00
Tim Allen 1c3c7fe0a7 Update to release v000r02.
byuu says:

314 of 512 opcodes implemented, can execute the first 67,450
instructions of Tetris.

I also added an MMIO bus, ala bsnes, so that I can map and access
individual registers with a single indirection.
2010-12-29 22:03:42 +11:00
Tim Allen e0a9f1cf2c Update to release v000r01.
byuu says:

Hooked up a scheduler to enter/exit the CPU core wherever I want. Added
basic 4*1024*1024hz clock, and about eleven or so opcodes. Creating the
disassembler as I encounter each new opcode, not skipping ahead to do
all 'like other' opcodes, eg if I add 'dec b', I don't then add 'dec c'
until I encounter it.
2010-12-28 17:03:02 +11:00
Tim Allen 246d6aaf08 Add .gitignore files to populate obj/ and out/ 2010-12-28 12:57:58 +11:00
Tim Allen da7d9f2662 Initial commit of bgameboy v000.
The source tarball also included empty obj/ and out/ directories which
git does not support.

byuu says:

Project started, so basically everything is new.

It's basically a rough skeleton that mimics bsnes project structure.
Eventually the src/gameboy folder will be copied into bsnes-official and
used by the chip/supergameboy core.
The middleware layer (supergameboy/interface) will be merged into a new
chip/icd2 folder that will represent direct Super Game Boy emulation in
the future.
At least, if all goes according to plan.

There is a simple GUI that can load ROMs, but do nothing after it. It's
not hooked up to ruby yet.
There is a basic system class and interface to expose the
video/audio/input functions.
There is a basic memory bus that doesn't support any MBCs yet.
There is a CPU skeleton that only handles easy read/write access to the
CPU registers (AF is a really fucked up register.)
The core is not hooked up to libco yet, but I intend for it to be, so
that I can run the CPU + LCD how I like.
If it turns out the LCD+audio is easily enslavable, then I'll probably
drop libco and just run it like a regular emulator, using a thread
wrapper around it in bsnes only. We'll see.

The CPU doesn't actually support any opcodes, and loading a ROM won't
actually execute anything.
2010-12-28 12:53:15 +11:00