B-Em

[lovebug]

is there an actual debugger (something like beebem) in b-em as I cant find anything except a popup window that seems to display memory access as colored pixels and a break button that I cannot get to do anything

what am i doing wrong

[Coeus]

is there an actual debugger (something like beebem) in b-em as I cant find anything except a popup window that seems to display memory access as colored pixels and a break button that I cannot get to do anything

The debugger is command-line in b-em. On Linux it uses the terminal you started b-em from for input/output so you will need to start it from a terminal window, not by double-clicking in a file manager. On Windows it should open a console window for the debugger.

[Diminished]

Has anyone managed to compile b-em on apple silicon? I'm getting the following message while building

I'm not fortunate enough to be on Apple Silicon, but I checked my configuration script for B-Em on my Intel Mac and it appears that I've encountered this problem before.

It seems you need to set these environment variables to pass to configure:

Code: Select all

export ac_cv_func_malloc_0_nonnull=yes
export ac_cv_func_realloc_0_nonnull=yes

./autogen.sh
./configure

See if that helps

[stevei2791]

thank you, with your help I've manage to build it.

[tricky]

is there an actual debugger (something like beebem) in b-em ...

I started adding one locally but haven't finished it.

[stevei2791]

thank you, with your help I've manage to build it.

After managing to build the executable it would not run because it couldn't find the dynamic library using @rpath, after a lot of searching I've found that there is currently a problem between gcc (home-brew) and Xcode 15.

To fix it you need to change the library paths in the executable post compile/link - note you will get errors about duplicate libraries being ignored when you build.

I created this script to change the old path in the executable to the new path (my allegro5 libs are in /usr/local/lib)

Code: Select all

# using otool -l b-em
# change any dynamic libraries with @rpath to use full path/filename
# workaround for problems between homebrew and Xcode 15

install_name_tool -change @rpath/liballegro_audio.5.2.dylib /usr/local/lib/liballegro_audio.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_acodec.5.2.dylib /usr/local/lib/liballegro_acodec.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_primitives.5.2.dylib /usr/local/lib/liballegro_primitives.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_dialog.5.2.dylib /usr/local/lib/liballegro_dialog.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_image.5.2.dylib /usr/local/lib/liballegro_image.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_font.5.2.dylib /usr/local/lib/liballegro_font.5.2.dylib b-em
install_name_tool -change @rpath/liballegro_main.5.2.dylib /usr/local/lib/liballegro_main.5.2.dylib b-em
install_name_tool -change @rpath/liballegro.5.2.dylib /usr/local/lib/liballegro.5.2.dylib b-em
[]code]

[VectorEyes]

is there an actual debugger (something like beebem) in b-em as I cant find anything except a popup window that seems to display memory access as colored pixels and a break button that I cannot get to do anything

what am i doing wrong

I’m pretty certain there is because I recall using it to debug various problems in my code a few years ago. I think this would have been using a Windows build of B-Em though.

The B-em GitHub page suggests you can select “debug” or “debugger” from one of the menus and you should get a text window into which you can type debug commands.

[TobyLobster]

is there an actual debugger (something like beebem) in b-em as I cant find anything except a popup window that seems to display memory access as colored pixels and a break button that I cannot get to do anything

what am i doing wrong

I’m pretty certain there is because I recall using it to debug various problems in my code a few years ago. I think this would have been using a Windows build of B-Em though.

I'm on Mac: If you start b-em from the terminal, when you click the 'Break' menu option the emulation stops and you get a prompt in the terminal. You have to tick the Debugger menu option first.
'?' gives you options in the debugger.

[lovebug]

The debugger is command-line in b-em. On Linux it uses the terminal you started b-em from for input/output so you will need to start it from a terminal window, not by double-clicking in a file manager. On Windows it should open a console window for the debugger.

Thanks, I knew I was missing something

[Diminished]

I am hoping that all the new tape code is now written, and all that remains is testing and the odd bug fix.

(This may be naïve.)

I really wish it wasn't necessary to have an actual "Record" checkbox to enable writing to tape. You would think that you could enable recording based on whether the tape system is currently generating leader tone or not. However, certain protected tape loaders do generate leader tone during loading, so this won't work. :(

[lovebug]

one thing I've noticed with b-em is that the screen update seems to be at 25Hz

I've tried all the video settings but cannot get the screen to update at 50Hz

to test this I used this but instead of getting a flashing display I get a solid color

Code: Select all

MODE 0
VDU 19,0,11;0;
*FX 9,1
*FX 10,1

if I change the two FX commands to 2 frames instead of 1 then I see a flashing screen

its annoying because any programs (games) that use 50Hz smooth animation look jerky at 25Hz

is this a b-em issue or my laptop ?

[CHRISJJ]

one thing I've noticed with b-em is that the screen update seems to be at 25Hz

Aha. Can anyone confirm this?

[TobyLobster]

one thing I've noticed with b-em is that the screen update seems to be at 25Hz

Aha. Can anyone confirm this?

Works fine for me, it flashes away like crazy. I have 'B-em v-4a1792f' on Mac, so not the latest.

[KenLowe]

to test this I used this but instead of getting a flashing display I get a solid color

Code: Select all

MODE 0
VDU 19,0,11;0;
*FX 9,1
*FX 10,1

is this a b-em issue or my laptop ?

Typing in the four commands above, I'm seeing a non flashing screen with a fairly recent B-Em v98830d1 running on Windows 10. On BeebEm I get a flashing display when I type in the same commands.

[CHRISJJ]

Thanks. Major fail. And by design, apparently. I cannot imagine why.

[Diminished]

Works fine for me, it flashes away like crazy. I have 'B-em v-4a1792f' on Mac, so not the latest.

Flashes fine on a Mac here also (snapshot from 20th October). May be an Allegro-on-Windows problem.

Thanks. Major fail!

Feel free to teach us lesser mortals a lesson by fixing the problem yourself and submitting a patch.

[CHRISJJ]

I'm sure there are no lesser mortals here

EDIT: PS Apologies if I caused any offence. But I doubt there's any disagreement with the fact.

[tricky]

Some LCDs do that for you, there have been a few posts about a great way to extend the palette!

Wouldn't surprise me if newer windows has added something behind the scenes, possibly as a power saving mode on laptops!

[Coeus]

is this a b-em issue or my laptop ?

It does seem to be b-em. In main.c there is this table:

Code: Select all

const emu_speed_t emu_speeds[NUM_EMU_SPEEDS] = {
    {  "10%", 1.0 / (50.0 * 0.10), 1 },
    {  "25%", 1.0 / (50.0 * 0.25), 1 },
    {  "50%", 1.0 / (50.0 * 0.50), 1 },
    {  "75%", 1.0 / (50.0 * 0.75), 1 },
    { "100%", 1.0 / 50.0,          2 },
    { "150%", 1.0 / (50.0 * 1.50), 2 },
    { "200%", 1.0 / (50.0 * 2.00), 2 },
    { "300%", 1.0 / (50.0 * 3.00), 3 },
    { "400%", 1.0 / (50.0 * 4.00), 4 },
    { "500%", 1.0 / (50.0 * 5.00), 5 }
};

The last number in each entry determines how many frames are displayed. 1 means display every frame, 2 is every second frame etc. I assume these numbers were set by some trial and error but what is realistic would depend on the system b-em is running on. If I change the entry for 100% to 1 then your test cases flashes correctly.

[lovebug]

I compiled B-em v-a55f951 and its running on

Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy
Intel Core i5-4210U Speed (MHz) min/max: 800/2700
Intel Haswell-ULT Integrated Graphics
Screen: 1366x768 s-dpi: 96

Is the issue my laptop ?

--- edit ---

oh right sorry I just read your post after posting, the 100% entry is set to 2 frames
i'll change it to 1 and recompile

maybe auto frame skip would be a better idea ?

[lovebug]

ok that quick fix of changing the 100% entry from 2 frames to 1 has caused some strange side effects that only affect full screen mode

if I switch to mode 0 type something on screen then switch to mode 7 then I see is mode 7 characters on one of the frames (odd?) and mode 0 graphics on the other frame (even?), in windowed mode everything seems to be normal



I might pile another hack on top of the hack to use 2 frames when teletext is enabled and 1 frame when not

But really this is the wrong thing to do

Even in full screen mode the graphics modes only look ok when display type is set to line doubling, all other modes flicker badly when 100% is set to 1 frame

[Sazhen86]

I am hoping that all the new tape code is now written, and all that remains is testing and the odd bug fix.

I really wish it wasn't necessary to have an actual "Record" checkbox to enable writing to tape. You would think that you could enable recording based on whether the tape system is currently generating leader tone or not. However, certain protected tape loaders do generate leader tone during loading, so this won't work.

That's looking good. Look forward to having a play around with it.

[Diminished]

There is almost certainly more that could be done to make automated tests easier. B-Em cannot, at the moment at least, be scripted to say "load tape file xxx" in the middle of a session. It can take the name of a tape file on the command line. There are some pieces that could prove useful, though.

... snip ...

I've thought about this a bit.

For the tape reading tests, I think automation can be achieved with a couple of simple patches:

• a) adding a command-line switch (or debugger command) which will cause B-Em to shut down with a non-zero error code when a breakpoint (or watchpoint, etc.) is hit in the debugger. I would suggest that taking the breakpoint number, ORing it with (say) 0x40000000, and using that as the return code would be good enough here.
  
  It appears that main() always returns 0 currently (although maybe there are some exit() calls dotted around as well) ...
  

  Code: Select all

  int main(int argc, char **argv)
  {
      main_init(argc, argv);
      main_run();
      main_close();
      return 0;
  }
  

  ... so a general mechanism will be needed for quitting with an error code. I don't know if you have any preference for how this should be done. A global variable would be simplest (although I have a pathological aversion to these).
  
  This mechanism (setting up some breakpoints/watchpoints in the debugger and exiting with per-breakpoint error codes if they are hit) could most likely be used for an extremely wide variety of automated tests.

• b) adding a new breakpoint type which will break into the debugger when the loaded tape ends. This is likely to be needed so that the emulator can be made to shut down reliably if the end of a test tape is reached without any other breakpoint being hit.

I'm happy to add these capabilities, but I wonder if you have any input or other ideas.

[Rich Talbot-Watkins]

It does seem to be b-em. In main.c there is this table:

Code: Select all

const emu_speed_t emu_speeds[NUM_EMU_SPEEDS] = {
    {  "10%", 1.0 / (50.0 * 0.10), 1 },
    {  "25%", 1.0 / (50.0 * 0.25), 1 },
    {  "50%", 1.0 / (50.0 * 0.50), 1 },
    {  "75%", 1.0 / (50.0 * 0.75), 1 },
    { "100%", 1.0 / 50.0,          2 },
    { "150%", 1.0 / (50.0 * 1.50), 2 },
    { "200%", 1.0 / (50.0 * 2.00), 2 },
    { "300%", 1.0 / (50.0 * 3.00), 3 },
    { "400%", 1.0 / (50.0 * 4.00), 4 },
    { "500%", 1.0 / (50.0 * 5.00), 5 }
};

The last number in each entry determines how many frames are displayed. 1 means display every frame, 2 is every second frame etc. I assume these numbers were set by some trial and error but what is realistic would depend on the system b-em is running on. If I change the entry for 100% to 1 then your test cases flashes correctly.

This seems to have been introduced by commit cc93741, I assume by mistake.

[lovebug]

sorry I was wrong, it is my toshiba laptop causing display issues

I just made the same modification on my imac changing the 100% entry to 1 frame and it works fine

system details:

Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy
Desktop System: Apple product: iMac14,3
Intel Core i5-4570S (MHz) min/max: 800/3600
NVIDIA GK107M [GeForce GT 750M Mac Edition]
Screen-1: 0 s-res: 1920x1080 s-dpi: 96

working fine

Code: Select all

const emu_speed_t emu_speeds[NUM_EMU_SPEEDS] = {
    {  "10%", 1.0 / (50.0 * 0.10), 1 },
    {  "25%", 1.0 / (50.0 * 0.25), 1 },
    {  "50%", 1.0 / (50.0 * 0.50), 1 },
    {  "75%", 1.0 / (50.0 * 0.75), 1 },
    { "100%", 1.0 / (50.0 * 1.00), 1 },
    { "150%", 1.0 / (50.0 * 1.50), 2 },
    { "200%", 1.0 / (50.0 * 2.00), 2 },
    { "300%", 1.0 / (50.0 * 3.00), 3 },
    { "400%", 1.0 / (50.0 * 4.00), 4 },
    { "500%", 1.0 / (50.0 * 5.00), 5 }
};

[Sazhen86]

This seems to have been introduced by commit cc93741, I assume by mistake.

That looks a merge of my pull request for the ARM7 co-pro. I can confirm that changing that was a mistake and should be put back to 1. My apologies.

[Coeus]

That looks a merge of my pull request for the ARM7 co-pro. I can confirm that changing that was a mistake and should be put back to 1. My apologies.

That does seem completely unrelated with the rest of that merge request. I have push a commit to revert that one line to 1.

[Stainy]

Hi all.
I got no issues with joysticks ( if the game supports joysticks ) But what I want to do is map keys to the joystick.
I have a GPD Win2 and I`d love to get a BBC emulator working. I can`t seem to find one that allows this.

Thanks

[tricky]

The limits versions of beebem and b-em often last behind windows and I don't know if the others have that facility, maybe try b2.

[Coeus]

The limits versions of beebem and b-em often last behind windows and I don't know if the others have that facility, maybe try b2.

Was that meant to be "The Linux versions of beebem and b-em often lag behind the Windows versions..."? If, so, I agree with BeebEm because the latest version is a Windows-only application and the Linux version is a separate fork but b-em is multi-platform.

But then the Win2 can run either Windows or Linux and, by default, runs Windows anyway.

To answer the original question, I did add some support to b-em for keyboard joystick emulation but it may been on a branch that didn't go anywhere and, I think, since then there has been some revision to the joystick support - Tricky I think that was you?