B-Em

tricky · Post by **tricky** » Sun Oct 15, 2023 3:17 pm

I'm a bit confused as to how the joystick mapping stuff is supposed to work, I should probably go an find a thread to read!
In my head:
First find active joysticks and if they are in the .cfg as mapping to a bbeb stic, map them so, otherwise, just take them in the order that they come.
Then assign logical buttons to the joysticks, assuming four logical buttons (using a tricky adapter, or 12/17 using the analogue sticks with keypads).
The use the mapping selected for each stick to map the logical buttons to physical buttons (haven't thought about keys).
I haven't coded this yet, but that is because I have just realised that it doesn't work how I was expecting it to!

Coeus · Post by **Coeus** » Sun Oct 15, 2023 5:32 pm

There is some info on Joysticks at: https://github.com/stardot/b-em/wiki/Joysticks

tricky · Post by **tricky** » Sun Oct 15, 2023 10:15 pm

Thanks, that isn't working for me because the extra joystick is found first, so I only get joystick 2 with the second fire button.
I'll play a bit more tomorrow.

tricky · Post by **tricky** » Mon Oct 16, 2023 5:51 pm

I've been having a play and rereading the joystick page.
I've added a second joystick support and support for a "Tricky four fire button joystick adapter", but I'm not happy with the way that the mapping works; nor that allegro doesn't know what the joystick is really called!.
It works OK for a single stick as you could have a selection of joymaps for different games as designed

In my old code, if there was a single stick, fire 0 and axis 1 and 2 were assigned to player 1's joystick and the rest to player 2 with buttons 0, 2, 4 etc all assigned to fire 0 and all the odd ones to fire 1. If only a single stick was selected, it got all the controls.

Adding the tricky joystick adapter gives 4 fire buttons, so they are assigned 0, -, 2, -, ... and -, 1, -, 3, ... or all four to the first four for a single stick.

I guess all that this requires is three mappings per joystick, so I may just add "Player 1" and "PLayer 2" to the joymap search search and fall back to no player if only one stick is in use or the Player N can't be found.

Does this sound worth while?
I still haven't found my arcade style stick, so can't confirm that it works with allegro.
From memory, the joystick is a "hat" returning an angle for direction and the buttons don't start at 0!

tricky · Post by **tricky** » Tue Oct 17, 2023 9:18 pm

I think that I have finished hacking for now.

I have added a sub menu for Joysticks with options to toggle "tricky joystick adapter" which uses the light pen strobe as an output to choose a second set of fire buttons when low (iirc). This required some minor changes to the sysvia. If it were a real adapter with real sega megadrive controllers, setting this in the middle of an ADC conversion would probably mess up the conversion, so it is best done from the conversion complete interrupt before the next one is started.

There are also options for Joystick and Joystick 2 which allow you to choose which joystick from a selection to use. The first joystick defaults to Joystick and if there is a second, it defaults to joystick 2.
Each joystick also has a joymap which chooses how the buttons and axis on the joystick are mapped to ADVAL channels and keyboard buttons as before. They will default to the default values (first three in the .cfg) or if there is a joymap with their name, to that.
The joymap sections can also automatically be selected based on the number of joysticks attached:
[joymap name] will be selected if there is only one joystick attached called name.
[joymap name Player 1] will be selected if there are two joysticks attached and this is "Joystick".
[joymap name Player 2] will be selected if there are two joysticks attached and this is "Joystick 2".
The first three joymaps should be:
[joymap default]
[joymap default Player 1]
[joymap default Player 2]
and will be used if there is no section with a name matching the allegro name for the joystick, which is displayed in the Joysticks menu.

If you like the sound of these changes, I have attached the changed files in the src directory (src.zip) also includes the updated b-em.cfg
If any one wants to try this out on windows, I have also attached the .exe (b-em.zip)

If the exe's zip is too big, let me know and I'll put it on the web somewhere!

PS I only do download zip in git, so I won't be doing whatever needs to be done to request this gets merged back in.

Diminished · Post by **Diminished** » Wed Oct 18, 2023 12:12 am

tricky wrote: ↑Tue Oct 17, 2023 9:18 pmI have attached

I'm not seeing any attachments there, buddy.

tricky · Post by **tricky** » Wed Oct 18, 2023 4:19 pm

I guess the exe was too big, now at https://www.dropbox.com/scl/fi/pnw707jy ... mbd2o&dl=0 and src.zip attached with changed files.
VS project has been updated to 2019, but doesn't need to be. 2017 v141 still has XP support and that might be a better bet if Allegro supports that.

Coeus · Post by **Coeus** » Fri Oct 20, 2023 7:44 pm

Diminished wrote: ↑Wed Oct 04, 2023 7:54 pm b-em-tape-overhaul-diminished-2.zip

I have put this on a branch in GitHub at: https://github.com/stardot/b-em/tree/sf/newtape

Is there any automation around the tests? Any hints?

Coeus · Post by **Coeus** » Fri Oct 20, 2023 8:03 pm

tricky wrote: ↑Wed Oct 18, 2023 4:19 pm I guess the exe was too big, now at https://www.dropbox.com/scl/fi/pnw707jy ... mbd2o&dl=0 and src.zip attached with changed files.
VS project has been updated to 2019, but doesn't need to be. 2017 v141 still has XP support and that might be a better bet if Allegro supports that.

Now also in a branch on GitHub: https://github.com/stardot/b-em/tree/sf/trickyjs

tricky · Post by **tricky** » Sat Oct 21, 2023 8:18 am

Coeus wrote: ↑Fri Oct 20, 2023 8:03 pm ...
Now also in a branch on GitHub: https://github.com/stardot/b-em/tree/sf/trickyjs

Thanks, I know I should learn this stuff, but like Python I don't really want to

Diminished · Post by **Diminished** » Sun Oct 22, 2023 10:32 am

Coeus wrote: ↑Fri Oct 20, 2023 7:44 pm I have put this on a branch in GitHub at: https://github.com/stardot/b-em/tree/sf/newtape

Thanks. Things have moved on a bit since then. I have saving-to-tape mostly working for UEF and TIBET now, with CSW also on the way (although I have a number of bugs to root out first -- adding new features seems to have this habit of breaking existing ones).

Is there any automation around the tests? Any hints?

There isn't at the moment, I'm afraid. It's more "these tests are a list of stuff I need to work through before releasing a patch". With the advent of saving-to-tape, this situation is about to get worse.

Automating the tests would be very useful, but I'm not sure precisely how you'd do it, given that many of the tests involve successfully loading a game on tape. There would seem to be three potential outcomes:

i) B-Em outright rejects the input file (UEF etc.)
ii) B-Em accepts the file, but MOS can't load it
iii) Tape loads and runs successfully

(ii) and (iii) are the hard ones. I suppose in some cases you could do it by checking that the program counter reaches a certain value. In the case of e.g. Pro Boxing Simulator, though, you need the game to continue to run for a while in order to confirm that it is working correctly; it's possible to mis-emulate tape in such a way that the game freezes after a minute or two.

You'd also need some way of injecting commands into the emulator in order to load the tapes in the first place. Perhaps auto-booting a disc to accompany each test case would be a way to do this?

I think beebjit has some sort of automated testing regimen, but I'm not sure how it works.

CHRISJJ · Post by **CHRISJJ** » Sun Oct 22, 2023 10:41 am

Diminished wrote: ↑Sun Oct 22, 2023 10:32 am You'd also need some way of injecting commands into the emulator

Meaning there's none? Is there automed test of any feature?

Coeus · Post by **Coeus** » Sun Oct 22, 2023 11:57 am

Diminished wrote: ↑Sun Oct 22, 2023 10:32 am You'd also need some way of injecting commands into the emulator in order to load the tapes in the first place. Perhaps auto-booting a disc to accompany each test case would be a way to do this?

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.

There is a command line option '-paste' which causes the text you specify to be read by the MOS as keyboard input as soon as it is ready. It is almost the same as typing it in, except it doesn't actually emulate actual keystrokes because that rather limits the speed and it is the same mechanism as "Edit->Paste via Keyboard" which was aimed at "typing" in programs, for example from forum posts.

There is also a '-exec' option which causes the debugger to read input from a file, so useful in connection with the -debug option. The debugger also has a paste command which has the same effect as the '-paste' command line option but, going that route, breakpoints can be set first and more than one string can be pasted in.

Really, those features were aimed at debugging a program being developed to run in B-Em when there are external tools involved in the development, so it was a mechanism to get back to the interesting part of the program being debugged without having to set up breakpoints etc. manually.

VDFS includes a client ROM which enables B-Em to receive the service call for unrecognised MOS commands and execute code in the emulator to execute them. One of the commands is to *QUIT which will cause the emulator to exit back to the host OS. That could be enhanced to return an exit code which would enable scripting on the host OS to determine if a test or set of tests was successful or not. Another easy, and probably useful, feature would be to be able to set breakpoints which exit to the host OS with a particular code.

What B-Em does not have is a built-in scripting language that would allow more complicated tests to be written, i.e. "repeat this x times" or "if test x passes then try test y" etc.

CHRISJJ · Post by **CHRISJJ** » Sun Oct 22, 2023 12:24 pm

Coeus wrote: ↑Sun Oct 22, 2023 11:57 am There is a command line option '-paste' which causes the text you specify to be read by the MOS as keyboard input as soon as it is ready. It is almost the same as typing it in

If that's a feed to OSRDCH, this would be worth defining I think.

Is this kind of stuff documented?

alienkidmj12 · Post by **alienkidmj12** » Wed Oct 25, 2023 11:45 am

can anyone throw any light on this

trying to compile on fedora 38

[sivesrutherfordd@vanir b-em]$ ./configure && make
[snip]
CXXLD b-em
/usr/bin/ld: b_em-midi-linux.o: in function `midi_jack_m2000_proc':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:58: undefined reference to `jack_port_get_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:59: undefined reference to `jack_midi_clear_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:61: undefined reference to `jack_midi_event_reserve'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:60: undefined reference to `jack_ringbuffer_read'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:58: undefined reference to `jack_port_get_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:59: undefined reference to `jack_midi_clear_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:61: undefined reference to `jack_midi_event_reserve'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:60: undefined reference to `jack_ringbuffer_read'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:58: undefined reference to `jack_port_get_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:59: undefined reference to `jack_midi_clear_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:61: undefined reference to `jack_midi_event_reserve'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:60: undefined reference to `jack_ringbuffer_read'
/usr/bin/ld: b_em-midi-linux.o: in function `midi_jack_m4000_proc':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:34: undefined reference to `jack_port_get_buffer'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:35: undefined reference to `jack_midi_event_get'
/usr/bin/ld: b_em-midi-linux.o: in function `midi_jack_init':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:111: undefined reference to `jack_client_open'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:113: undefined reference to `jack_set_process_callback'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:119: undefined reference to `jack_activate'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:128: undefined reference to `jack_client_close'
/usr/bin/ld: b_em-midi-linux.o: in function `m2000_jack_init':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:93: undefined reference to `jack_port_register'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:95: undefined reference to `jack_ringbuffer_create'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:97: undefined reference to `jack_port_unregister'
/usr/bin/ld: b_em-midi-linux.o: in function `m4000_jack_init':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:84: undefined reference to `jack_port_register'
/usr/bin/ld: b_em-midi-linux.o: in function `m2000_jack_init':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:93: undefined reference to `jack_port_register'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:95: undefined reference to `jack_ringbuffer_create'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:97: undefined reference to `jack_port_unregister'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:93: undefined reference to `jack_port_register'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:95: undefined reference to `jack_ringbuffer_create'
/usr/bin/ld: /home/sivesrutherfordd/clones/b-em/src/midi-linux.c:97: undefined reference to `jack_port_unregister'
/usr/bin/ld: b_em-midi-linux.o: in function `midi_jack_send_msg':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:155: undefined reference to `jack_ringbuffer_write'
/usr/bin/ld: b_em-midi-linux.o: in function `midi_jack_close':
/home/sivesrutherfordd/clones/b-em/src/midi-linux.c:136: undefined reference to `jack_client_close'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:754: b-em] Error 1
make[1]: Leaving directory '/home/sivesrutherfordd/clones/b-em/src'
make: *** [Makefile:425: all-recursive] Error 1
[sivesrutherfordd@vanir b-em]$

tnash · Post by **tnash** » Wed Oct 25, 2023 11:59 am

Looks like it can't find JACK as those are all references to JACK functions https://jackaudio.org/api/index.html ?

alienkidmj12 · Post by **alienkidmj12** » Wed Oct 25, 2023 12:07 pm

yeah i tried installing that also, but appears theres another with pipewire.

[root@vanir ~]# dnf install jack-audio-connection-kit-dbus
Last metadata expiration check: 0:38:58 ago on Wed 25 Oct 2023 11:25:57 BST.
Error:
Problem: problem with installed package pipewire-jack-audio-connection-kit-0.3.83-1.fc38.x86_64
- package pipewire-jack-audio-connection-kit-0.3.83-1.fc38.x86_64 from @System conflicts with jack-audio-connection-kit-dbus provided by jack-audio-connection-kit-dbus-1.9.22-1.fc38.x86_64 from fedora
- package pipewire-jack-audio-connection-kit-0.3.67-1.fc38.x86_64 from fedora conflicts with jack-audio-connection-kit-dbus provided by jack-audio-connection-kit-dbus-1.9.22-1.fc38.x86_64 from fedora
- package pipewire-jack-audio-connection-kit-0.3.83-1.fc38.x86_64 from updates conflicts with jack-audio-connection-kit-dbus provided by jack-audio-connection-kit-dbus-1.9.22-1.fc38.x86_64 from fedora
- conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
[root@vanir ~]#

Diminished · Post by **Diminished** » Wed Oct 25, 2023 6:05 pm

Looks like configure is messing up and somehow detecting JACK when it isn't completely installed?

You could try editing src/midi-linux.c and adding

Code: Select all

#undef HAVE_JACK_JACK_H

directly above this existing line (line #20):

Code: Select all

#ifdef HAVE_JACK_JACK_H

derek · Post by **derek** » Thu Oct 26, 2023 9:08 am

Hi,

You need to install Package: libjack-dev

Quote from Debian Package details:
JACK Audio Connection Kit (development files)
JACK is a low-latency sound server, allowing multiple applications to connect to one audio device, and to share audio between themselves.
This package contains files needed for the development of JACK applications and an API reference.
https://packages.debian.org/buster/libjack-dev

Diminished · Post by **Diminished** » Thu Oct 26, 2023 10:49 am

alienkidmj12 wrote: ↑Wed Oct 25, 2023 11:45 amfedora 38

derek wrote: ↑Thu Oct 26, 2023 9:08 amDebian

Furthermore, it shouldn't be necessary to install JACK. The problem is that for some reason configure thinks JACK is installed when it isn't.

alienkidmj12 · Post by **alienkidmj12** » Thu Oct 26, 2023 2:17 pm

Diminished wrote: ↑Wed Oct 25, 2023 6:05 pm Looks like configure is messing up and somehow detecting JACK when it isn't completely installed?

You could try editing src/midi-linux.c and adding
Code: Select all
#undef HAVE_JACK_JACK_H
directly above this existing line (line #20):
Code: Select all
#ifdef HAVE_JACK_JACK_H

that worked, thank you, this is great.

Sazhen86 · Post by **Sazhen86** » Fri Nov 10, 2023 1:12 am

Coeus wrote: ↑Fri Oct 20, 2023 7:44 pm
Diminished wrote: ↑Wed Oct 04, 2023 7:54 pm b-em-tape-overhaul-diminished-2.zip
I have put this on a branch in GitHub at: https://github.com/stardot/b-em/tree/sf/newtape

Is there any automation around the tests? Any hints?

Would it be possible to add tibet.h to that branch as it currently fails to compile.

Code: Select all

In file included from 6502.c:24:
./tape.h:6:10: fatal error: 'tibet.h' file not found

Diminished · Post by **Diminished** » Fri Nov 10, 2023 1:28 am

Sazhen86 wrote: ↑Fri Nov 10, 2023 1:12 am Would it be possible to add tibet.h to that branch as it currently fails to compile.

This should be the right version I think (my local copy has moved on quite a bit since then).

tibet.h: (2.49 KiB) Downloaded 101 times

Sazhen86 · Post by **Sazhen86** » Fri Nov 10, 2023 1:39 am

Diminished wrote: ↑Fri Nov 10, 2023 1:28 am
Sazhen86 wrote: ↑Fri Nov 10, 2023 1:12 am Would it be possible to add tibet.h to that branch as it currently fails to compile.
This should be the right version I think (my local copy has moved on quite a bit since then).

tibet.h

Thanks! It can't find tape2.h or tibet.c either so I copied that from your latest patch and it builds OK now. I guess these need adding to the branch in GitHub.

I'm looking forward to playing with all of this when you've finished it.

Diminished · Post by **Diminished** » Fri Nov 10, 2023 1:45 am

I might as well upload those too, then.

Forum was being weird with tibet.c, so I had to rename it to .c.txt.

Sazhen86 · Post by **Sazhen86** » Fri Nov 10, 2023 1:53 am

Diminished wrote: ↑Fri Nov 10, 2023 1:45 am I might as well upload those too, then.

Forum was being weird with tibet.c, so I had to rename it to .c.txt.

Thanks again.

When do we get to play with the version from your YouTube demo?

Diminished · Post by **Diminished** » Fri Nov 10, 2023 4:13 pm

Sazhen86 wrote: ↑Fri Nov 10, 2023 1:53 am
Diminished wrote: ↑Fri Nov 10, 2023 1:45 am I might as well upload those too, then.

Forum was being weird with tibet.c, so I had to rename it to .c.txt.
Thanks again.

When do we get to play with the version from your YouTube demo?

I'll try to make some more progress on it. Writing-to-tape is not without its problems. I still need to code up CSW output, and then there will be a pile of issues to sort out and a lot of testing to do. :/

Sazhen86 · Post by **Sazhen86** » Sat Nov 11, 2023 8:40 am

Diminished wrote: ↑Fri Nov 10, 2023 4:13 pm I'll try to make some more progress on it. Writing-to-tape is not without its problems. I still need to code up CSW output, and then there will be a pile of issues to sort out and a lot of testing to do. :/

I'll look forward to playing with the results. I guess I spent so much time in the 80s with just a tape for my Beeb that I have a certain nostalgia for the waiting and listening to the tones.

KenLowe · Post by **KenLowe** » Sun Nov 12, 2023 1:46 pm

Does anyone have a working Windows x64 build of the B-Em Econet branch they would be willing to share?

https://github.com/stardot/b-em/tree/sf/econet2

I'm keen to do some debugging when loading code from Econet, but BeebEm keeps crashing on me when I use its built in debugger

.

stevei2791 · Post by **stevei2791** » Wed Nov 22, 2023 8:01 am

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

ld: Undefined symbols:
_rpl_malloc, referenced from:
_common_init in b_em-6502tube.o
_w65816_init in b_em-65816.o
_tube_6809_init in b_em-6809tube.o
_z80_init in b_em-z80.o
_arm_init in b_em-arm.o
_tube_pdp11_init in b_em-copro-pdp11.o
_csw_load in b_em-csw.o
_csw_load in b_em-csw.o
...
clang: error: linker command failed with exit code 1 (use -v to see invocation)

stardot.org.uk

B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

install issues

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em

Re: B-Em