b2 port attempt

[zoltanvb]

Hi,

I am trying to get a libretro port of B2 up and running. Currently, it seems that CPU emulation is started, but the emulated machine gets into a loop, always executing BRK on 0001. Reading up on the instruction, it is supposed to read the vector at FFFE-FFFF RAM address, which is indeed 0 in my case.
Should this be filled after creating BBCMicro object and loading OS and language ROMs? I was trying to replicate what test_common.cpp RunStandardTest does for the most simple case:

core = new BBCMicro(&BBC_MICRO_TYPE_B,nullptr,BBCMicroParasiteType_None,{},nullptr,0,nullptr,{0});
core->SetOSROM(LoadROM("OS-1.2"));
core->SetSidewaysROM(15, LoadROM("BASIC2"));

and then calling core->Update. Something is missing obviously, but I can't figure it out. Any pointers appreciated, either here or via some other channel.

[tom-seddon]

Interesting project! The test code is probably the best place to start as it avoids a lot of the extra junk (graphics, sound, threading, etc.) that b2 proper has. That bit of code does look about right.

The files are definitely getting loaded, I assume?

The CPU should start by fetching the reset address from $fffc/$fffd and then jumping to that address ($d9cd in OS 1.20). You can breakpoint the CPU read here:

b2/src/beeb/src/BBCMicro_Update.cpp

Line 308 in a4078ff

m_state.cpu.dbus = m_pc_mem_big_pages[m_state.cpu.opcode_pc.p.p]->r[m_state.cpu.abus.p.p][m_state.cpu.abus.p.o];

- watch m_state.cpu.abus.w to see the address being read. Within the first 7 hits (representing the first 7 CPU cycles) you should see reads for $fffc (reset vector LSB), $fffd (reset vector MSB) and $d9cd (first reset instruction in OS 1.20). m_state.os_buffer is the OS contents, which should be whatever's in OS-1.2, and should match what's getting fetched each time.

The memory isn't super easy to examine in the debugger due to the various arrays used for the paging, but for the BBC B, m_pc_mem_big_pages[0]->r[x] points to the buffer for bytes read from the 4 KB range whose top 4 bits are x. So m_pc_mem_big_pages[0]->r[0xf] when stopped on the CPU read statement should give you the last 4 KB of the OS ROM.

[zoltanvb]

Thank you! It was indeed a problem with ROM loading. Now I can see that the memory clear routine is activated correctly.

[zoltanvb]

Alright, some progress, and probably the time to ask some questions before moving on with the rest of the adaptation. The libretro port can currently hande sound, video, and has keyboard controls mapped. (Still a few steps from a public beta, but not very far.) My added code is ugly at the moment, but that will be cleaned up still.

The existing code could be re-used with minor modifications - which is currently ~30 #ifdef B2_LIBRETRO_CORE 's in ~10 files, mostly used to avoid having to pull in SDL or any other dependency. Probably this count won't increase too much (if any) while rounding up the rest of the functionality.

On the other hand, I made 2 changes that are not so nice:

• using a statically compiled version of 6502_internal.inl , and
• doing the libretro build with a separate Makefile, instead of cmake

Both can be done properly (i.e. moving back to 2-phased compilation and cmake only), but due to the large variety of platforms supported by libretro (several by cross-compilation), they can get complicated.

Generally, when a libretro core is adapted from a standalone emulator, the best longterm scenario is when the core gets built directly from the upstream repo, since that means emulation fixes or relevant functionality updates will be immediately available, and libretro targets are considered when refactoring or large code reorganization is done. Second best is when there is a fork, but upstream changes can be pulled in quickly and easily, and the third option is a hard fork where update requires significant effort.

So, the question is whether you would be interested in including the libretro port specific changes as a whole (at the expense of added code, complexity, and PRs for the libretro part), or willing to allow some minor changes (those #ifdef's) so that second option can be maintained.

In any case, the port still needs time to mature and the decision can be made later, my intention is just to ask if there is any point in spending time cleaning up the build system, which would be a requirement for option 1 I assume, but maybe skippable for option 2.

[tom-seddon]

Sorry for not commenting - I've not had much time for thinking about b2 stuff for the past couple of weeks. But I got an email about your libretro repo which reminded me about this thread! I'll look at this in the next week or two.