joeldipops/transferboy

Gameboy Emulator for N64 using Transfer Pak. Actual emulator logic largely written by https://github.com/koenk/gbc. Runs on https://github.com/DragonMinded/libdragon

transferboy's Issues

Implement less common Cartridge Types

HUC1 in particular.

GBC IR Transfer

I forgot this existed, but should definitely be implemented since multiplayer is a selling point of this project.

Check for available memory the right way.

64 Doom does it like this. 0x80000318 must be a hardware register that contains max available memory

    int available_memory_size = *(int *)(0x80000318);

    if(available_memory_size != 0x800000)

From here: https://github.com/mikeryan/n64dev/blob/master/docs/n64.lyx

To check how much memory is installed, we consult the address 0x80000318.
It corresponds to osMemSize from the SDK, and contains the size of memory
(0x00400000 for 4MB or 0x00800000 for 8MB).
The PIF-ROM code detects the size of memory and sets the value at that
address before jumping to program code.
If we wish to detect the size of memory ourselves instead of using the
value the PIF-ROM gave us, we can use the following algorithm:

Start at address (0xA0400000 - 4) and a memory count of 4MB.

Write a 32-bit word to the address, read it back, and compare it to the
value written.

If it is the same, add 0x100000 to the address and 1MB to the memory count.

Repeat until the memory count is equal to the desired amount of memory.
If we are only verifying the (non)existence of an officially-released memory
expansion pack, stop when the memory count is equal to 8MB.

Note that an attempt to access a non-existent physical memory address will
result in an exception, so in order to prevent a CPU crash when performing
memory detection, an appropriate general exception handler must be installed.

Bring gbC code in to main src folder

It's just kind of messy having it there now.

Remember to update the license to mention which files are MIT License or otherwise.

GBC Sprite priority to be implemented.

LCDC.7 - LCD Display Enable
CAUTION: Stopping LCD operation (Bit 7 from 1 to 0) may be performed during V-Blank ONLY, disabeling the display outside of the V-Blank period may damage the hardware. This appears to be a serious issue, Nintendo is reported to reject any games that do not follow this rule.
V-blank can be confirmed when the value of LY is greater than or equal to 144. When the display is disabled the screen is blank (white), and VRAM and OAM can be accessed freely.

--- LCDC.0 has different Meanings depending on Gameboy Type ---

LCDC.0 - 1) Monochrome Gameboy and SGB: BG Display
When Bit 0 is cleared, the background becomes blank (white). Window and Sprites may still be displayed (if enabled in Bit 1 and/or Bit 5).

LCDC.0 - 2) CGB in CGB Mode: BG and Window Master Priority
When Bit 0 is cleared, the background and window lose their priority - the sprites will be always displayed on top of background and window, independently of the priority flags in OAM and BG Map attributes.

LCDC.0 - 3) CGB in Non CGB Mode: BG and Window Display
When Bit 0 is cleared, both background and window become blank (white), ie. the Window Display Bit (Bit 5) is ignored in that case. Only Sprites may still be displayed (if enabled in Bit 1).
This is a possible compatibility problem - any monochrome games (if any) that disable the background, but still want to display the window wouldn't work properly on CGBs.

Everything's gone horribly wrong in the master branch.

Tetris still works, but a bunch of other things, including blargg's tests just go to a black screen. Suspect it has something to do with the error stuff in gbc_state.c that I changed without really testing properly. Blargh indeed.

MBC2 Accuracy

For performance' sake, this requires restructuring mmu.c again so mmuWriteOperation has different values for each MBC type.

This Doc goes in to the meat of each MBC type https://gekkio.fi/files/gb-docs/gbctr.pdf

Streamline cartridge loading screen

Rejig loading screen so that cart loads automatically unless checksum fails/some other error - Provide ability to retry if error does occur.

Audio

Audio is a big complicated mess. I have written some placeholder code for processing the four audio channels, but the output is just going to be head-ache inducing buzzing noises until I get around to implementing it properly.

Use global rootState instead of passing it around.

"In C globals are more common especially in the era when RAM was limited. So it's not "bad" it's normal.
Modern Object Oriented code would pass variables around from function to function and would feel clean but use more RAM and spend more time copying data from place to place."

Detect what controllers are plugged in so can't 'add game/add player' unless plugged in.

Because a missing controller provides junk data, and this causes the second emulator to freak out.

Flicker in bottom few tile rows of screen.

Whenever a sprite moves within the bottom few tiles, those rows flicker and get very ugly.

I suspect this is because the RSP hadn't quite finished rendering the last rows before being asked to render the new ones.

I think the fix here is to have some way for the RSP to signal that it is done and not interrupt it with a new render request. Just skip that frame.

There is also scope for optimising the RSP code - take advantage of delay slots where possible and avoid repeating a few calculations.

SGB rendering dodgy after 'only draw changed pixels'

Rewrite MMU to take advantage of an array for faster access

Setting out the memory space in a big struct will probably speed up mmu operations.

Implement Super Game Boy commands

Remove cruft from gbC source

Now that I now for sure that unused code can affect performance, remove all the unreferenced gbC stuff that I don't plan to use for Transfer Boy - UI & supporting code, Save states, etc

Monochrome colour palette too dark

There's not enough contrast between two or three of the colours for og gameboy games. Conversely, GBC games look quite good.

Visual glitches in GBC mode

Watching the intro to Zelda Oracle of Seasons, there are numerous visual glitches such as the wrong tile or colour palette being displayed. Suspect this is due to unimplemented gbc features, such as VRAM banking.

Try building GB screen as a texture and using RDP to scale it

joeldipopsToday at 11:59 AM
So my emulator takes a 160x144 buffer of pixels and line-by-line centres them in to the 320x240 n64 frame buffer. Currently doing this by manipulating the frame buffer in memory. Is there a better RDP based way to do that? Impression I got was that in this situation the RDP wouldn't help, but I could extremely easily be missing any number of things..

CrashOverideToday at 12:09 PM
There may be, I think there is a command
Marshall prolly knows

MNGoldenEagleToday at 1:14 PM
You could just render it as a texture that's stretched across the screen, couldn't you?

joeldipopsToday at 1:16 PM
I'm I naive in thinking that when I'm building up the texture in memory I might as well be updating the frame buffer in memory?

MNGoldenEagleToday at 1:17 PM
If the texture is smaller than your frame buffer, and you're not really rendering anything else, then it still makes sense to do it as a texture. Let me put it this way: the CPU is at a disadvantage modifying a lot of memory, so having it write to the entire framebuffer isn't ideal.

Reinstate 2-player mode

Currently the RSP renderer is only written to handle one player (that is, one input buffer at a time, no support for different scaling, we're relying on the hope that a frame will be rendered before the next one is ready to start. As a result of finally getting this to work, I just hid the options to add a second player. The performance was too atrocious to bear thinking about anyway.

However, we should be able to rewrite the RSP code to handle two players. My plan is to call it once at the end of each logic step, and the input will include addresses for both buffers.

We will also need to implement a signal that doesn't interrupt the RSP until it's finished a frame. Probably will skip the next frame, rather than queue it and let them back up.

Animation and Sound in Menus

Always thought of having an animated hand icon as you move around the menus. Some audio cues would also be appropriate.

This goes hand-in-hand with general improvement of look & feel including comissioning some art work for background & sprites.

Use int32s whereever possible

When writing new code for N64 the most overlooked optimization is using (u)int32 for every variable/parameter possible. The compiler will usually add several additional instructions to ensure that the value is only the promised "byte" or "short".
Also more parameters cause more work on the stack, think of the first 4 as "free", additional parameters have a cost.

GBC double speed mode handling

When double speed mode is enabled, ensure the pending and active flags are implemented and the LY, STAT and IF registers act accordingly.

Anything with an MBC seems to be broken.

Somewhere along the line. It's in the master branch and the mmu_restructure branch. I suspect it only broke a few commits ago.

DO NOT MERGE mmu_restructure until fixing this so I don't have to wade through as many commits.

Performance

Unless I can get performance under control, the whole project is bunk

Two player mode not rendering properly

I think it's getting confused between which buffers have rendered or not. I think the best approach is just to have two buffers, Last and Next, instead of the four in there now.

DKL2 Now crashes the entire system. Oh dear..........

Haven't had this happen since I first managed to run GB games at all :(

Implement obscure gb cartridge features eg. camera, IR ports, accelerometers?

Yes you can take out the transfer pak and plug in the rumble pak if you really wanted. Just need to be smart about SRAM.

Anyway, there may be other features that don't need special hardware and this issue is to remind me that they exist.

Any release soon?

I tried to compile it, but installing libdragon and a toolchain was too hard for me. I would love to try this though, so I was wondering if binaries are planed to be released anytime soon.

Blargg cpu_instrs test reports "Timer Doesn't Work"

Get rid of linker hack and write proper makefile

Write to Cartridge RAM less frequently

Occurring in Donkey Kong Land 2. Once you're in a level, every few seconds the display will freeze for 500 - 1000ms.

I thought this might have been the flush to cartridge, but I commented that out and had the same behaviour (unless the flash cart is doing weird stuff and running the wrong file again.)

At any rate, the flush to cartridge probably can be less often than once a frame, I imagine it will cause slow-down somewhere.

Tried again with an obviously different file and the jankiness cleared up, so I think writing to the cartridge is probably the culprit after all

Rumble Support

Implement support for cartridges with a rumble motor.

Progress Bar while loading ROMs

When loading ROM from Cartridge, provide some sort of updating indicator of how much of the ROM has been loaded.

Can use timer_callbacks to acheive this in parallel with the actual loading.

Implement MBC3 Real Time Clock in TPakio and gb mmu

Here's the relevant section from http://gbdev.gg8.se/wiki/articles/Memory_Bank_Controllers

4000-5FFF - RAM Bank Number - or - RTC Register Select (Write Only)
As for the MBC1s RAM Banking Mode, writing a value in range for 00h-07h maps the corresponding external RAM Bank (if any) into memory at A000-BFFF. When writing a value of 08h-0Ch, this will map the corresponding RTC register into memory at A000-BFFF. That register could then be read/written by accessing any address in that area, typically that is done by using address A000.

6000-7FFF - Latch Clock Data (Write Only)
When writing 00h, and then 01h to this register, the current time becomes latched into the RTC registers. The latched data will not change until it becomes latched again, by repeating the write 00h->01h procedure. This is supposed for from the RTC registers. This can be proven by reading the latched (frozen) time from the RTC registers, and then unlatch the registers to show the clock itself continues to tick in background.

The Clock Counter Registers
08h RTC S Seconds 0-59 (0-3Bh)
09h RTC M Minutes 0-59 (0-3Bh)
0Ah RTC H Hours 0-23 (0-17h)
0Bh RTC DL Lower 8 bits of Day Counter (0-FFh)
0Ch RTC DH Upper 1 bit of Day Counter, Carry Bit, Halt Flag
Bit 0 Most significant bit of Day Counter (Bit 8)
Bit 6 Halt (0=Active, 1=Stop Timer)
Bit 7 Day Counter Carry Bit (1=Counter Overflow)
The Halt Flag is supposed to be set before to the RTC Registers.

The Day Counter
The total 9 bits of the Day Counter allow to count days in range from 0-511 (0-1FFh). The Day Counter Carry Bit becomes set when this value overflows. In that case the Carry Bit remains set until the program does reset it. Note that you can store an offset to the Day Counter in battery RAM. For example, every time you read a non-zero Day Counter, add this Counter to the offset in RAM, and reset the Counter to zero. This method allows to count any number of days, making your program Year-10000-Proof, provided that the cartridge gets used at least every 511 days.

Support for Larger Cartridges

Should be something like

1 Read in ~4mb on start up and index the banks
2 When mbc registers invoked, keep track of most recently used banks.
3 If needing a bank that isn't loaded, cull the least recently used bank before replacing it.
4 For simplicity, never cull bank 0

If possible, offload render loop to RSP

Some RDP doco https://dragonminded.com/n64dev/Reality%20Coprocessor.pdf

RSP doco
https://ultra64.ca/files/documentation/silicon-graphics/SGI_Nintendo_64_RSP_Programmers_Guide.pdf

RSP interface
https://github.com/DragonMinded/libdragon/blob/master/include/rsp.h

void load_ucode(void * start, unsigned long size);
void read_ucode(void* start, unsigned long size);
void run_ucode();

Gameboy Input broken

For some reason, the A and Right buttons aren't working. Pretty sure this used to work when I first started testing. Thinking something to do with when I was messing around with Super Gameboy comms.

Roll own code to read & write from GB cartridge

libgbpak doesn't have a license attached to it, so if I ever wanted to sell TransferBoy I can't use that code. So need to implement that functionality myself.

Optimise via code alignment

Using particular compilier flags and directives should help speed up critical code by a frame or two.
Need to do a bit of research on this, but can play around with the various flags and see what changes to start with.

Switch and Reset menu options seem to be broken

Update ROM memory space on mbc write time, rather than at each romx read

Do the same for other banked memory obvious.